Are You Sure SHA-1+Salt Is Enough For Passwords? 409
Melchett writes "It's all too common that Web (and other) applications use MD5, SHA1, or SHA-256 to hash user passwords, and more enlightened developers even salt the password. And over the years I've seen heated discussions on just how salt values should be generated and on how long they should be.
Unfortunately in most cases people overlook the fact that MD and SHA hash families are designed for computational speed, and the quality of your salt values doesn't really matter when an attacker has gained full control, as happened with rootkit.com. When an attacker has root access, they will get your passwords, salt, and the code that you use to verify the passwords."
Wait, what? (Score:4, Informative)
Why is this even a question? Use bcrypt [codahale.com], always. (Preferably using the $5$ or $6$ extensions.)
Re:Security cookbook? (Score:4, Informative)
Re:Wait, what? (Score:4, Informative)
Why is this even a question? Use bcrypt [codahale.com], always. (Preferably using the $5$ or $6$ extensions.)
mysql only offers AES, DES, MD5, and SHA... So... for at least a certain subset of developers, thats what they're going to use.
I'm not saying they're correct to do so, I'm just explaining why they will not even consider your suggestion, because they have architectural problems, for them its not as simple as search and replace all calls to md5() with bcrypt().
Re:Wait, what? (Score:5, Informative)
While most people know enough about security to avoid a plain password hash, very few people know how vulnerable common key derivation functions truly are. Things like PBKDF2, bcrypt and MD5-crypt widely used for example in Linux shadow file or in TrueCrypt give only a linear advantage over a salted plain hash. 5000 MD5 repetitions might sound like great security from a brute force perspective, but the asymptotic hardware cost of brute-forcing such a password is fairly small. The cost to break your 8 letter bcrypt password is in the hundreds of dollars, assuming enough passwords are cracked to justify a hardware cracker. I can almost bet NSA has a multi-million dollar hardware cracker that can brute-force your Linux or TrueCrypt password, assuming it has less than about 50 bits of entropy. Very few people are capable or willing to use truly safe passwords with 100bit+ entropy.
I know of only one strong key derivation algorithm that forces the attacker to scale it's hardware cost at the same rate as the software slowdown: scrypt [tarsnap.com]. So by all means, don't use bcrypt, use scrypt.
The issue is completely different in a webserver, that probably can't spend 1 second of CPU time whenever a user logs in. Is such cases a hash + salt is all that you can realistically expect if a dedicated authentication machine does not exist. At least try to combine them safely using a HMAC, not some home-grown SHA1(salt+password) scheme.
Re:First Post! (Score:4, Informative)
Salts are a necessity: without salt, you would be able to identify very fast two users having the same password. Without salts, you would be able to find a password faster when you have more users. As a result, the size of the salt shall be related to the number of encrypted passwords you are trying to protect from cracking.
If you are trying to crack a single account, salt does not change anything. The purpose of salt is not to increase the security of a single account, but to avoid the reduction of security that would occur when you have many accounts.
Re:News at 11 (Score:5, Informative)
This isn't about passwords, it's about using hash values to protect passwords even from people with the root password. Basically, not even root should be able to figure out any users password.
Normally this is done by never storing the users password, only a hash of the users password, it's MD5 value say. Now the user enters their password, this is hashed, and that value compared to the stored hash. We could talk about collisions etc, but lets assume this works for now. User can get in with the right password, but not even root knows what this is just by looking at the hash database.
Unless of course rootâ"or the attacker that has gained rootâ"has a precomputed table of hash values. Then they need only look up the hash and obtain the password directly. To prevent this, systems use "salts", random integers/strings, appended/XORed to the password before the hash is computed. In theory then, an attacker would need to generate a different hashtable for each individual system compromised. Infeasible, or so we think.
He's where TFA comes in. MD5 and SHA1 are optimised to some extend for speed. Now, suppose the attacker has gained root and now knows the salt. How long will it take to generate a hashtable which can be looked up to find user passwords. TFA argues that this will now take only 33 days on a single machine using GPU computation. That's ~24 hours with less than 50 GPUs. Salt or not, these hashes are crackable in hours, not years.
So basically, the speed of MD5 and SHA1 hashes is actively working against computer security by making computing hashtables easier. TFA argues that a more computationally difficult hash scheme is needed, subject to certain criteria, and offers the PBKDF2, Bcrypt, and HMAC algorithms as potential alternatives. You could also throw, say, the three body problem with initial conditions at the computer instead.
Basically, hashing will protect against people with root access, but only if the hashing algorithm is computational difficult.
Re:Security cookbook? (Score:5, Informative)
Be sure to mention it to Melchett and CmdrTaco. They sure have completely missed the point of salting password hashes. When you have root, you can obviously verify that a given password matches the information stored on the compromised system. As root you have access to all information that the computer can use and since the computer must be able to tell if the given password is correct, root can too. The point of salt isn't to make that impossible. That would be stupid.
The point of salt is to make it impossible to use a precomputed table of password hashes and find a valid matching password just by comparing the precomputed hashes to the ones on the system. If you don't use salt, then one rainbow table suffices and the reversed passwords can be used on any other system that uses the same hash algorithm without salt and where the user has the same password (happens much too often.) With salt, you can not reverse the password except by brute-forcing each and every password hash individually. No time-memory trade-off with rainbow tables.
SHA1 is still considered a cryptographically secure hash function, which means so far no faster way to reverse it is known than trying all possible inputs in the forward direction until the result matches the given hash value. Salt makes the hash function an individual function per system (or even per password), which means you have to repeat this process for every system/password without being able to use precomputed tables and even if you can reverse a password hash by brute force, it is unlikely that you can use the resulting password somewhere else, because many passwords match the same hash, but only the right one will match for any salt.
Password stretching etc (Score:5, Informative)
The solution to this is simple: just iterate the hash function many times so that the time to hash the password is (say) 300ms - unnoticeable to an interactive user, but significant for a brute force attacker. This is called password stretching, and is as important as salt.
See http://www.openwall.com/articles/PHP-Users-Passwords [openwall.com] for a review of this and other password hashing issues - not just for PHP, this article gives the thinking behind phpass which is now used in Drupal, and has been reimplemented in other languages. phpass includes bcrypt() as an option but can work even with really old PHP versions that only have MD5. Just because MD5 and SHA1 have been cracked to some degree doesn't invalidate them for password hashing with salt and stretching.
Key derivation functions perform essentially the same operation as password stretching, see http://en.wikipedia.org/wiki/Key_derivation_function [wikipedia.org] - there is an IETF RFC for this.
Digression: Windows 7 still doesn't use salted passwords, which is why it's so easy to crack Win7 passwords given the hashed password, using Rainbow Tables - see http://en.wikipedia.org/wiki/Ophcrack [wikipedia.org] - try the vendor's scarily good online password hash cracker for yourself...)
Most importantly: don't even think of implementing your own crypto code unless the above is very old news to you, because you WILL get it wrong - the examples of unsalted and unstretched passwords are only the beginning. Instead, search for a credible crypto library in your chosen language, and if necessary write a C wrapper so that your preferred scripting language can access a good C/C++ library such as Crypto++ - http://www.cryptopp.com/ [cryptopp.com]