99 Passwords and I Remember None

Photo credit Marc Falardeau
8,213,000,000 password guesses a second – that’s what a single, affordable, off the shelf piece of hardware could do in 2012. That means the vast majority of six character passwords could be guessed in under a minute. Without proper protection, passwords stored by websites are horribly vulnerable.
How long are passwords going to last? The analogy often used for passwords is they are a key to unlock some kind of electronic door. The analogy breaks down when you think of the practicality of a burglar trying millions of different keys a second on your home door. But that’s what happens every time a new list of hashed passwords gets stolen. Programs like hashcat and readily available graphics cards churn though guesses at a dizzying rate and can uncover thousands of passwords in under an hour.
The manta is to choose complicated passwords and not use the same one on different sites. But going back to the key analogy, how realistic would it be then to carry around a keychain with over a hundred keys on it? Humans are lazy or like to take the shortcut – whatever you prefer. It’s no wonder then that we’re all probably guilty of using the same password on multiple sites. Recently Adobe announced the loss of millions of passwords. Vbulletin had a vulnerability exploited which lead to compromises on MacRumors.com and vBulletin.com. It’s an almost weekly occurrence that a large scale loss of password details occurs.
Any service provider worth their salt should not be storing passwords as plain text – that’s been known for a long time. The vast majority won’t even be storing them as something that can (simply) be reversed. Using a one way hash you can take some input, like a users password and generate a unique output. However due to the wonders of maths it’s extremely difficult to reverse the process. Given the same input the output will always be the same. This is the process that backs the majority of login systems. You create an account and choose a password. The website will generate a unique hash from your password and store that. When you want to login again you provide your password, which is then run through the same hashing procedure, if the output matches the stored value – you’re in.
So this all seems good enough, no passwords being stored. The trouble is, not all hashing procedures are created equal. Or rather they are created with different intentions. Hashing methods aren’t generally designed for storing login details. They are used for providing a unique and predictable output given an input. Say for example you need to see if any files in a directory have changed. You can take the contents of each file, hash it and compare it against a list of known values. If you’ve a huge list of files to get through you want your hash function to be as quick as possible. Which is the exact opposite of what you want from a password hash. You want that to be dirt slow.
The way hashes are compromised to reveal your password is generally; someone will obtain the list of hashes that are stored for a website and the attacker will use brute force and dictionary based methods to try vast numbers of combinations to see if it matches the value they’re trying to guess. Not so long ago – even just a few years this wasn’t such a big problem. It still took a reasonable amount of time to play the guessing game. However powerful graphics cards have become faster and cheaper and their huge parallel processing abilities is perfect for hash generation. As more hash lists are exposed developers of the software to crack passwords are building more sophisticated rules for guessing passwords. Rather than just a random guess they can take into account the name of the site or the account name, if they know that a lot of people incorporate that into their password. This all adds up to being able to try millions of guesses a second and being able to be more targeted in your attack.
But there are ways to make this harder for attackers. One way is for website owners to use one of the slow hash methods like bcrypt. The idea behind it, is built into the process is a guarantee that an element of work has been carried out. The more work the longer the time it takes to run. By forcing this work element it means that those trying to crack the password also have to put more time into each guess. This forced work could take the average cracking time for a password from minutes to years. You can also help yourself by choosing long passwords that use a variety of characters and aren’t based on common phrases. You know those tricks they used to shortcut guessing time? One is to compile very detailed lists of previous passwords and patterns that can be used in future attacks.
But all this leads us back to the beginning. We’re still trying to carry around a massive set of keys and the keys are getting heavier by the day. What makes matters worse is that we still have no way of verifying that the website in question is handling our password data securely. There’s no standard or code of practice about handling login data. I doubt whether any enforced regulation would be effective to bring password handling up to a decent level. The PCI certification for handling credit card details is meant to ensure credit card details are handled correctly. From my experience, at least in the smaller volume sites, it’s just a mess and a license to print money for third parties.
Something that is becoming more popular is offering the option to login via another site – commonly Facebook or Twitter. This has the advantage that you can join different sites without creating a new password and Facebook should be primed in keeping your details secure. OpenId was pushing this idea a while ago. But from the looks of it has largely failed. The implementations were clunky and gaining traction was hard because the question for new users was always – what’s this openid thing?
The thing that troubles me with relying on Facebook or Twitter for the authentication stage is they are social networks not authentication services. It does them good to know which other sites you log into but they have no responsibility to continue providing the service if they don’t want to. Of course central authentication services could be set up in a similar way to banks providing a system for you to verify card details and transfer money. There are currently password managers that will store your passwords and make managing a large hoard of random numbers and letters easier on your brain. But there’s still the problem of keeping it secure – granted most will have a robust encryption scheme. But with the amount of malware about, is it really that feasible to expect password safes to go unnoticed once a large number of people start using them?
I don’t think there’s a single solution to the problem with passwords. Security needs to be built in layers and everyone needs to buy into it. The web has grown immeasurably and we’re still using the same security mechanisms we did in it’s early days. I think the days of having a separate account/password for each site are limited. The risk, both to the visitors and site owners is growing. Simply storing a hashed string in a database isn’t going to cut it any more.