This is another unpublished blog from March 31st, 2009. I’m publishing these not quite done blogs prior to my refresh.
—-
Today alone, I’ve read two different pages related to password word security for websites. One asked why some websites limit passwords up to 10 characters, and the other discussing some wacky scheme to come up with an easy to remember but hard to guess passwords.
Okay, let’s talk about passwords. They suck. Specifically, they suck at what they are tasked to do: protect your data. Why? Simply, it’s too damn hard to protect your password(s).
Passwords are vulnerable to many common attacks, and I’ll enumerate some of them.
Password’s can be attacked based on strength. A password strength is determined by mainly: it’s hard to guess. By guess, I don’t mean, pull out of thin air like a human does, but guess as a computer guesses, by trial-and-error over a known set of values.
The least most sophisticated, but still effective attack against password strength is a brute-force attack. That is, the computer (or groups of computers) try every combination of characters until it finds a match. This site has a pretty good table of password complexity to cracking time by brute force guessing.
There are a number of safeguards for this attack, that a surprising number of systems don’t employ:
1) Only allow a few failed attempts before locking an account
2) Require complex passwords
Another common attack is a dictionary attack. Again this is a brute force attack, a bunch of values are tried until success, using predetermined values. There are a number of websites that list the most common passwords, and for good reason, so many people still use them.
Again, limiting the number of attempts will prevent compromise, as well as enforcing a password complexity that does not allow dictionary words. You would be surprised to see the size of these dictionaries, including most foreign words, as well as common translations such as: score -> $c0r3 etc.
A simple way of storing passwords is to not store them at all (since passwords are as valuable as the data they protect it makes sense to avoid exposing them). Instead it’s to take them, convert them into something else (hopefully deterministically), then store that. As example: “god123″ -(x)-> 38ef28scF. Then during login, we can convert the value, and compare the result with what we stored, and if it matches then we have success. If an attacker is able to access our database that stores our hashes (again protect by a password!) they can use a rainbow table–basically a bunch of precomputed hashes, to reverse lookup our passwords.
To protect against this attack, it’s common to “salt” the hash. That is, add some extra known values to the end of the password, prior to hashing it to obtain a (hopefully) unique value. Example: “god123″ + “!#12#&” -(x)-> e4fced8021. Of course now this means the salt is now valuable must also be guarded.
Then there is the case of hashing. Not all hashing functions are made equal. For there to be an effective hash, it should have high collision resistance. Said another way: it should be rare (like astronomical odds) that two inputs produce the same output. If they do, that’s a collision, and if the hashing algorithm produces a lot of collisions, then my job to find matching passwords is reduced by that amount.
Yet another attack is the man in the middle attack:
I can put up a webpage that fools you into giving me your password, and then use that to login as you. Web browsers have protections in place to verify the authenticity of a website, but how many users are savvy enough to understand those little certificate errors?
Then there is the case of the people whom you give our password out to. I’ve worked on a number of systems that submit your password over the internet in plaintext (ie without encrypting it). How many people use the same passwords for multiple websites? It’s bad practice for sure, but I know I’m guilty of it!
Unfortunately, despite they’re many vulnerabilities (and I’ve only scratched the surface), passwords are still here to stay.