Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Storing Passwords Securely

throwingfire.com

Post reply on HN
Print view View original

71–80 of 144 posts

Re: Storing Passwords Securely

#71

Post by stickfigure »

dekz wrote: post #67
stickfigure wrote: post #44

How about this: Don't store passwords at all. There are a multitude of sophisticated third-party solutions to authentication. Facebook, Twitter, and Google all offer competent solutions. Don't like those? Use BrowserID. Integrating any of these is actually quite a bit easier than rolling your own solution. It reduces hack risk, provides a better experience for your customers (what was my password again?), and almost…

This naively assumes that your entire userbase uses those services and would like to attribute their Google (et al) account with your service. This may not always be the case. Someone has to store the passwords, it would be good if there was a way you could be assured your data at rest was safe.

If you believe your userbase will object to Google/Twitter/FB, use BrowserID.

Personally, I never feel particularly secure when typing passwords into text boxes on random PHP forms. On the other hand, I feel fairly confident that the folks at FB, Google, Twitter, and Mozilla know how to store a password and secure their infrastructure.

Re: Storing Passwords Securely

#72

Post by tptacek »

dekz wrote: post #68
indygreg2 wrote: post #35

Earlier quoted context omitted.

Assuming all the steps in the article are followed, yes, you are correct. I still think any article talking about verifying credentials is obligated to mention that string comparison could be an attack vector. Like I said, it plants a seed. And, I've seen way too many naive implementations where it is needed (like simple token-based auth systems) to know that this seed needs to be spread a lot more.

I believe what tptacek is trying to say that an attack on the == operator is not a timing attack but a brute force attack. Sure the function may return quicker but it doesn't reveal any more information and will be a brute force attack of data returned from a hash function. For other readers, the == operator is comparing a password hash , as opposed to a password itself. One of the properties of a secure hash functio…

Changing operator== to secure_compare or some analog doesn't change this construction's resilience against attacks. This is very much unlike the situation with, for example, an HMAC verification.

Re: Storing Passwords Securely

#73

Post by emmett »

rorrr wrote: post #65

> MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all means use them for message authentication and integrity checking, but not for password authentication. Bullshit. MD5 is just fine, as long as you use the salt. Here, hack this: MD5(password + salt) = "b520542710812f347432232b2a1fba83" salt = "MD5 rules"

MD5 is not fine. MD5 is very very fast[1] and as such it's possible to simply brute force password given relatively modest computing resources. The space of passwords just isn't that big.

Use bcrypt or scrypt. Don't make up your own crypto.

[1] Crypto benchmarks: http://www.cryptopp.com/benchmarks.html

Re: Storing Passwords Securely

#74

Post by ghshephard »

rorrr wrote: post #65

> MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all means use them for message authentication and integrity checking, but not for password authentication. Bullshit. MD5 is just fine, as long as you use the salt. Here, hack this: MD5(password + salt) = "b520542710812f347432232b2a1fba83" salt = "MD5 rules"

I mean this in the most polite and professional manner possible, please take five minutes and read http://codahale.com/how-to-safely-store-a-password/ .

It will explain why "salts are useless for preventing dictionary attacks or brute force attacks."

The entire article is excellent - and every colleague who I've ever pointed at it, has come away nodding their head and seeing the light.

The key-takeway (but please, read the entire article) is: "It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database."

Salts only help you from precomputed dictionary attacks ("Rainbow Tables") - but, if someone is brute forcing you, the value of a salt just disappeared.

Re: Storing Passwords Securely

#75

Post by stickfigure »

Dylan16807 wrote: post #70
pud wrote: post #69

The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…

Salts are not secret. They make you run unique calculations per attacked password and do absolutely nothing else. You might feel like adding a hidden component but it won't noticeably help security and it's not a salt.

Furthermore, it's important that the salt be unique per password. If you had a single common salt in your code, then two users with the same password would produce the same hash.

Re: Storing Passwords Securely

#76

Post by SCdF »

pud wrote: post #69

The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…

You are. The salt is just to stop the use of rainbow tables, which are pre-generated maps between plaintext passwords and their hashes.

Anyway, you want to store a new salt (not just a system-wide 'this is my salt' salt) for each stored password anyway, so you will need to store that data somewhere. You could obfuscate a little by storing the salts elsewhere, but it seems a little extreme.

Re: Storing Passwords Securely

#77

Post by ashconnor »

pud wrote: post #69

The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…

No it's not a bad idea and essentially it's what BCrypt does.

Think about it. If you use the same salt for all passwords then I can easily create a rainbow table consisting of "keyword" + salt hashes and doing so I can crack multiple passwords.

However if there is a different salt for each password then this type of attack becomes more difficult as I have to essentially do the same amount of work for only a single password.

Finally, we need to store the salt in the database because it's needed in order to recreate the hash using the user's password for authentication.

Re: Storing Passwords Securely

#78

Post by scoot »

pud wrote: post #69

The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…

Yup. The main purpose of salt (aside from increasing entropy by increasing the length and complexity of the hashed value) is that it prevents rainbow table attacks where an attacker pre-computes (or downloads precomputed) hashes for common passwords, dictionary words, and brute-force style variations of same.

A hash unique to the site would require the attacker to create a site-specific rainbow table, but once created it can be used for all passwords. Having a unique hash per password means that the attacker would have to generate unique password tables per user, which for a suitable salt & algo is impractical, even if (as they normally are) the salts are stored with the passwords.

Re: Storing Passwords Securely

#79

Post by Dylan16807 »

rorrr wrote: post #65

> MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all means use them for message authentication and integrity checking, but not for password authentication. Bullshit. MD5 is just fine, as long as you use the salt. Here, hack this: MD5(password + salt) = "b520542710812f347432232b2a1fba83" salt = "MD5 rules"

MD5 is 'fine' for very long passwords. How many of your users have very long passwords? MD5 does nothing to make it hard to blaze through billions of possibilities.

Re: Storing Passwords Securely

#80

Post by ashconnor »

stickfigure wrote: post #75
Dylan16807 wrote: post #70

Earlier quoted context omitted.

Salts are not secret. They make you run unique calculations per attacked password and do absolutely nothing else. You might feel like adding a hidden component but it won't noticeably help security and it's not a salt.

Furthermore, it's important that the salt be unique per password . If you had a single common salt in your code, then two users with the same password would produce the same hash.

This is only a problem in the sense that once one hash has been cracked the so is the other, however most authentication is done using some user/email attribute also.

Usually we fetch user/email, hash password, compare to hash in database - authenticate if match or deny if not.

Post reply on HN