Friday, June 8, 2012

Dealing with the Problem of Passwords

Passwords are a problem, as we've seen this week with the leaking of LinkedIn passwords.


The best way to not allow passwords to be compromised is to not store the password at all.  Unfortunately, I've seen far too many apps that have databases with a "password" column that contains the actual password!  And I'm sure you've seen web sites that, when you click the "forgot password" link, sends you an email with your actual password!  This is not good.  The only one who should know a password is the person who created the password.


So the first thing to do is to not store the password.  Instead store a one-way hash of a password.  A hash is a function that given a value, returns a new value of a fixed length that is always the same for the original value.  A one-way hash is a hash that can convert text to a hash value but cannot convert the hash value back to the original text.


It just so happens that Real Studio has a one-way hash function built-in: MD5.


Given a password "frenchfries", MD5 generates this hash value (converted to hex): 8d32a4b407de20d2465467ee38def24c


Instead of storing the password, you store this hash value.  To validate a password, you calculate the hash for the entered password and compare the results.  If they are the same then you know the password is correct even though you do not know the actual password.


This strategy is a great start, but it has a flaw: it is susceptible to a "brute-force" attack.  This is where a nefarious hacker pre-calculates hash values for large amounts of common words.  This is referred to as a rainbow table.  Since most people choose relatively simple passwords, they will more than likely be found in a rainbow table.  If a hacker gets access to your hash value, they can then look it up in the rainbow table to see what the plain text password is.


One way to help mitigate this is to use a "salt" along with the password to create the hash.  The salt is an extra value that you add to the password to generate hashes that make rainbow tables useless. You can use the same salt value for all the passwords (usually not recommended) or you can use something more specific for each password.


Creating an MD5 hash on the combination of the hash for "frenchfries" and the text "frenchfries" generates this hash: 5074614ea4d980208040c55267e81ec0


Such a value is not likely to show up in a rainbow table anywhere because it's specific to you thus limiting its general usefulness.  Not to mention a hacker would actually need to figure out how you are creating your salt value before they can generate a rainbow table.


Unfortunately for LinkedIn, they were not using a salt on their stored passwords.


Using a hash with a salt works well, but you have to use a secure hashing function. It has been known for some time that MD5 is no longer a secure hashing function and is not recommended for use.  Its primary problem is that it is possible for two completely different values to generate the same hash.  This flaw has been used to fake security certificates among other things. You may think it does not matter much for your purposes, but there are other hashing functions that are safer to use such as SHA-1 and SHA-2.


Alas, Real Studio does not include any versions of those two hash functions, although there is a feature request for this: 7269.  You do have some 3rd party options, however:
You can use any of these hash functions in place of MD5.

5 comments:

Chris Musty said...

This is pretty good advice but there is one important step missing for supreme security.

Every time a user logs in, a random salt should be generated and appended (prefixed, jumbled whatever) to the password before being hashed. Storing the password AND the salt seperately in the database (or even a readable text file) makes it easy to validate the user but extremely hard to crack.

I dont know the figures but I have heard that SHA512 would take longer than the age of the universe to crack. If this was implemented, every time someone simply logged in it would thwart any current attempt to crack it completely.

Chris Musty said...

Storing the password AND the salt seperately - should have read...

Storing the Hash AND the salt seperately

Unknown said...

I'd say that MD5 collisions do exist BUT in a theoretically space only. For average, everyday usage I would recommend MD5.

Furthermore, one cannot 'crack' an MD5 or SHA512 digest. There is no way to reverse the digest back to the original string, but I think 'cracking' in this context means 'guessing'.

Chris Musty said...

It is not theory...

http://www.golubev.com/hashgpu.htm
http://3.14.by/en/md5
http://thehackernews.com/2012/04/extreme-gpu-bruteforcer-crack-passwords.html

Thats just 3 crackers! They run in your GPU and are super fast.

NIST are advertising it as hacked and dont recomend its use. They are working on SHA-3 because SHA-1 is also officially hacked and SHA-2 is good until 2020 (not sure really but not too far away).

Paul Lefebvre said...

There has been a great companion thread on the mailing list about this as well:

http://support.realsoftware.com/listarchives/realbasic-nug/2012-06/msg00595.html