As most people will be aware, several high profile websites have suffered security breaches, resulting in millions of user account passwords being compromised. These sites have included business social networking site LinkedIn, online dating agency eHarmony and the music streaming site Last.fm.
All three of these sites have been on the internet for at least 10 years (eHarmony  is the oldest, having launched in 2000, the others were in 2002), which makes them truly ancient in internet terms.
Additionally, all three are very high profile, with huge user bases (LinkedIn claims over 33 million unique visitors per month, eHarmony claims over 10,000 people take its questionnaire each day and in April 2011, Last.fm claimed more than 50 billion user playlists) so you would expect that they were well versed in the threats of internet based attackers – which makes the recent user password compromises so shocking.
Using LinkedIn as the highest profile example, it seems that a malicious internet based attacker was able to extract 6.5 million user account password hashes, which were then posted on a hacker forum for people to try and “crack” them back to the original password. The fact that this has happened, points to some major problems in how LinkedIn protected  customer data (effectively it’s most important asset…) but, at the end of the day, no network is immune to attackers.
Unfortunately, LinkedIn had another major failing in that it appears it has ignored the last ten years worth of IT Security “good practice” advice and the passwords it stored were simply hashed using an old algorithm (MD5), which has been treated as “broken” since before the service went live.
(Sidebar: Hashing is the process whereby a password is altered from the plaintext version the user types in, to something totally different using a variety of cryptographic techniques to make it hard for an attacker to reverse engineer the original password. The idea is that the hash should be impossible to reverse engineer but this has proven to be an elusive goal)
Compounding on this error, LinkedIn failed to “salt” the password hashes, although this technique was understood and implemented in the 1970s. A password salt, is the process of adding some additional data to the password before hashing which can significantly increase the length and complexity of the password and done properly, renders most brute force attacks so time consuming as to be almost useless.
So, based on the available information, it seems that the LinkedIn password compromise was the result of some very old fashioned approaches which probably resulted from a misguided drive to reduce expenditure (something we have talked about several times in the past, most recently here) ignoring the possible consequences of a major data breach.
However, one thing which doesn’t make a huge amount of sense is that these password compromises have (again) led to calls across the industry for passwords to be considered a “dead” technology and how we should all replace it with (insert technology of choice – often the one the person is involved with selling).
An example of this – although this is far from the worst and, I suspect, it is just a title to attract attention rather than being a serious suggestion – came in SC Magazine’s online edition for 15 June.
In an article titled “The death of the password?,” Mark Knight (director of product management at Thales e-Security) gave a very interesting example of how passwords can be attacked and how compromises can take place.
Overall, there is very little which explains why passwords should be considered dead as a result of these breaches – which were actually the result of broader security failures rather than a failure or weakness in the concept of passwords (or even the passwords themselves). However Mark does give some very good advice on how users can improve their password handling (which is where the real weakness lies, not in the length or existence of passwords) but the overall approach falls down with this:
As we move towards smartphones and tablets where apps are able to store credentials on behalf of users, we are finding that we all use our passwords less: perhaps only to authorise higher-value transactions or to enroll new devices.
From an end user point of view, this may well be true. We authorise an app on our phone and everything seems to work.
However, every weakness he describes in the article still exists with the added problem of us being less aware of the risks as we no longer interact with the security controls ourselves.
Earlier in the article, Mark talks about how attackers can sniff passwords in transit:
Attackers often merely need to compromise an edge-of-network web server with some malware to steal every password as it is provided or to steal password hashes.
Which is all very true but it is not the fault of passwords as an authentication mechanism, it is down to poor security design. Using a smartphone app (or even multifactor authentication such as biometrics) would not protect against this because at the most fundamental level the client (the user) has to send something to the server as their identification.
In the case of authentication apps, this is often a cryptographically hashed version of whatever credentials the user presented (fingerprint, retina scan, code, pin etc), which is just as vulnerable to poor implementation as the cryptographically hashed version of their password.
Passwords are not the weak link. The problem, the security risk, the vulnerability is almost always the result of poor design decisions and incorrect implementations.
Dont waste money on additional methods of authentication, or shiny new software and hardware solutions, when the problem is simply one of implementation. It is likely to cost less to change your passwords to SHA-1 and add some good salt to the process.
I’d love it if passwords were dead because I can never remember them! They should be fewer in number, that’s for sure.
Hi Beverly,
Thanks for the comment.
Remembering passwords is always hard work and I am not sure there is an easy way to cut down on the number of passwords we have to deal with on a day to day basis (other than simply not using web services…).
However, it is worth keeping in mind that there is nothing wrong with writing some passwords down. All security controls should be threat based, but with passwords we fall into the trap of demanding every threat is deemed to be equally valid at all times. This is never, ever, true.