This month we have had another example of compromised passwords, this time it was LinkedIn a widely used business networking site.
Thirty years ago, yes I only need to go back that far, user names and passwords were the norm for access control to some computing resource and PINs were all the rage for accessing ones bank account. But in the joining years the world has changed so much in terms of networking and the attached cybercrime that user names and passwords no longer offer the right protection. The world at large doesn't seem to have realised this, perhaps it will take a breach in PayPal's security or Amazon but you can be assured it will happen, it's just a matter of time!
The logic of the problem is no different to that which made public key cryptography the base of eCommerce back in the 80's and is still the core security mechanism used today. The fundamental problem with symmetric cryptography is that the participants in a transaction both need to share the same secret key. In terms of confidentiality this in general can be made to work because the core business need is to share secret information whether it is information or keys. However when you are talking about authentication and integrity this is no longer true, the participants in a transaction may well have different and even conflicting business needs.
If the correspondent partner in a message relationship shares the same secret (key, PIN or password, it doesn't really matter) then they can do whatever the first person can do. So if we are talking about enciphering confidential data then both parties can equally encrypt or decrypt the data. When you are talking about confidential data that all makes sense. Now let's take a different scenario,
When you ask your bank to carry out some financial operation on your behalf you are not primarily concerned about confidentiality but the bank needs to authenticate your requirement both in terms of your authorization and the correctness of the data.
Now you can start to see the problem, what happens if the customer denies some aspect of the instruction, what happens if the bank denies some other aspect of the instruction? You can imagine the situation, the customer buys some shares which dump in value, and he may have a memory loss about the amount or even doing the transaction. The trouble is that legally it would be very hard to prove the customer initiated the transaction particularly in today's open network world because the security controls are shared by both parties.
This is why digital signatures only really work if you use asymmetric cryptography because this is the only case where the sender and receiver don't share the secret value. In a court of law unless you've found some quick way of breaking RSA or Elliptic Curve Cryptography there can be no doubt about the evidential value of the digitally signed message.
So back to the ubiquitous user name and password, values both shared by the sender and receiver and dare I say it probably anybody else that can get in the middle. The use of classical TLS or SSL will protect the channel from eavesdroppers but not those that interpose themselves when the secure session is established. The classical Man in The Middle (MITM) works all too well unless you use a client certificate which is rarely done. Why not? It's so easy to do and it makes all the difference to the security of the connection.
Let's pretend a little more, imagine that there is no breakdown of security at the client end, no malware, no PINs written down, no phishing, and a secure session is established without any interlopers. Wishful thinking really but let's pretend for a little longer. Now when the host end comes to authenticate the user he can check the credentials, user name and password against what is stored in his database.
Now we are getting a little closer to the LinkedIn problem, some hacker got to the database. Well that shouldn't matter you are probably thinking to yourself, it must be encrypted or something. That something of course is where the devil is in the detail.Stand back for a moment and put yourself in the place of the designer, he can't store plain text passwords because that would be obviously wrong. So how about a hash function, some one way function so you can easily check a password but given access to the hashed file in the database you can't go back and recreate the password. You could even make this hash function public information, why not, people would probably work it out anyway? SHA-1 has been around for a long time and although it has a few collision weaknesses it's not really a problem here.
The trouble is people tend to use fairly short passwords, 4 characters, six maybe and if forced 8 characters. Well you can see the problem, you may not know the password but given the hash file it's not going to take you very long to try the total password space to find the matching hashed version, you don't need to find all of them, just enough for your mischievous purpose.
A number of observers have jumped up and down about the obvious protection of adding uncertainty to the hash values by adding some random salt to make the input to the hash function longer. All very well and good but what makes you think the hacker wouldn't get this value? You need to apply it every time you check the password.
The amusing thing about the whole event is that people have been downloading the compromised hash file to see if their password is in the file because of course anybody can go this way through the one way function.
The lesson here is that the concept of user name and passwords really isn't the way to go. There are vulnerabilities all the way down the chain. Do you really think that other well-known sites such as PayPal, eBay , Google and Amazon are immune? Proper authentication is all about challenges and responses and for me that means using asymmetric cryptography.
Dr David Everett, (Smartcard & Identity News)