Secure password storage – a myth?
blog.mostof.it
Secure password storage – a myth?
1–10 of 12 posts
Re: Secure password storage – a myth?
#2Even better than this is to not generate a hash, but an HMAC with the hmac "secret" being some kind of site-key and salting the input. It can't be hit by continuation attacks, to which prepending an unchanging salt is completely vulnerable.
Re: Secure password storage – a myth?
#3I was under the impression that even these are vulnerable, because both MD5 and SHA1 are computationally efficient, meaning you really should be iterating the hashing process many times over, or using something like blowfish. Also, I think MD5 has collision problems?
Which really just brings us to our final solution, which is use a system that is designed by others and has been thoroughly tested and trusted.
Re: Secure password storage – a myth?
#4Repeat after me: "use bcrypt".
http://codahale.com/how-to-safely-store-a-password/
Or just use bcrypt, please.
Re: Secure password storage – a myth?
#5Guy doesn't know what he is talking about.
See http://chargen.matasano.com/chargen/2007/9/7/enough-with-the... and http://codahale.com/how-to-safely-store-a-password/
Re: Secure password storage – a myth?
#6I'm going to try to save tptacek the trouble of typing it out again:
1. Salt must be per user unique. Do not reuse salt.
2. Do not use md5 or sha* as they are, because they are too fast to compute and thus too easy to brutforce. Instead use a slow hash function, as slow as you can possibly tolerate in your app. E.g. Bcrypt, scrypt, or pbkdf2. These algorithms allow you to tune their slowness.
3. As computers become faster, you will need to make your hash functions slower. Have a plan in place that will allow you to recompute bashes to increase their slowness.
Re: Secure password storage – a myth?
#7Argh. Not this shit again. bcrypt, scrypt, or maybe (some clients explicitly require it because it's a Well-Known Name) PB-KDF2.
Re: Secure password storage – a myth?
#8I see many recommendations here, and in prior discussions, to use bcrypt. Having finally actually looked up how bcrypt works, I have two concerns.
1. It uses Blowfish, but it modifies how the key schedule and S-boxes are set up. Doesn't that essentially make it no longer Blowfish, but rather Blowfish inspired? Blowfish has a long history and has been well studied. By fiddling with it, don't they throw that out?
2. Suppose you are storing passwords encrypted using bcrypt with a cost factor of n. You decide to increase that to m. How do you compute the new hashes for existing passwords? From the description of the algorithm in their paper, it looks to me like you can only do this by having the original, plaintext password. Thus you can only strengthen a stored password when the user logs in, so you can compute the new stored password.
Both of the above issues could be addressed by doing something like the following. What advantages does bcrypt have over something like this?
hash_password(start, cost, salt, pass)
h = pass
for i = start to cost
h = sha256(i . ":" . salt . ":" . h)
return h
To later update this to a higher cost, c2, compute h2=hash_password(c1+1,c2,s1,h1), and store (c2,s1,h2).
Re: Secure password storage – a myth?
#9I'm a bit tired of those "just never ever store passwords in plain text" statements applied way too much universally. Sure, for websites, most of time, bcrypt+HTTPS is one of the best choices. But the article in subject never mentioned that it's about the websites.
One fact. Unless your ISP uses some sort of digital certificates, or authenticates you based on physical connectivity (like port number on switch, DSLAM or whatever), your ISP stores your password in plain text. And that - controversially - is a Good Thing.
It's because your ISP had decided that connection-level security is way weaker than password storage security. The cables may run all over the city and they're harder to protect. The encryption takes place every time when you authenticate your connection, so nobody with a network sniffer would obtain your password easily (active attacks are still possible, but they're harder).
The real rules are much more complex, based on the environment your system's working in — the connection medium, geographical diversity, supported authentication schemes and so on. The only absolutely universally true rule is "secure the whole system as much as you can, starting from the weakest link in the chain (but don't invent your own schemes)".
(Sure, there are public-key crypto, zero-knowledge password proof schemes and so on - and they should be used if possible - but, for example, one the best security options a typical home router could offer for PPPoE is a CHAP with MD5 hashing as defined in ancient RFC1994.)
Re: Secure password storage – a myth?
#10Guy doesn't know what he is talking about. See http://chargen.matasano.com/chargen/2007/9/7/enough-with-the... and http://codahale.com/how-to-safely-store-a-password/
I get so tired of this. Almost ALL of you are thinking with blinkers on. The password field of your website is not the only vulnerability! Most, of the time, an even bigger vulnerability is PEOPLE. People at your company, for example, who have access to the database.
Listen up: rainbow tables CAN BE and ARE of a concern if you run a website, because unless you use a salt, anybody who has access to your database can (speaking figuratively) rainbow-table it straight into their bank account.
Stop thinking about JUST web pages and password fields. That is a mistake some banks and other corporations made, and their databases are now -- remember? -- available for download online.