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

How To Safely Store A Password

codahale.com

Post reply on HN
Print view View original

131–140 of 215 posts

Re: How To Safely Store A Password

#131

Post by cperciva »

ihodes wrote: post #62
Jach wrote: post #44

Earlier quoted context omitted.

Reuse is a problem, but weak passwords are the biggest problem. If you have a strong password that never gets cracked/leaked/intercepted but you use it everywhere you're still fine, but that's not recommended. Generating server-side passwords is horrible as well since you're counting on the user to write it down and/or let the browser's password manager save it. What if the user wants to log in with a different machi…

Eight characters for a password seems plenty long to me, if you're truly using a random password. You have [A-Za-z] = 52 chars, [0-9] = 10, [!@#$%^& ()_-+=;':",. /?\|[]{}] = 30, for a total of 92 possibilities. Then you have an 8 character password. Even if the attacker knows you're using 8 characters, you've got ((92^8) 0.3)/60/60/60/24/365/100 = 271 centuries if it takes 0.01 seconds a try. And we're really talking…

With $10k of GPUs, you can compute an MD5 hash for every 8-character ASCII printable password (yes, all 95^8 of them) in under a day.

This is why MD5 is not a good password-based key derivation function. :-)

Re: How To Safely Store A Password

#132

Post by TwistedWave »

roel_v wrote: post #120
TwistedWave wrote: post #96

Earlier quoted context omitted.

The goal of hashing the passwords is to not store them in plaintext in the database, in case the server is compromised. In your case, an attacker doesn't need the password, the hash is enough to login.

I suppose you mean "goal is to not store them in plaintext"? I was confused there for a second.

Indeed, thanks. I fixed it.

Re: How To Safely Store A Password

#133

Post by roel_v »

andrewcooke wrote: post #99
pbreit wrote: post #45

Can someone help me understand what a password cracker does with a list of salted/hashed passwords? How do they know they've figured out the right plain text passwords without bouncing them against the authentication logic?

i suspect you don't know that the salt is stored with the password [edit: when using standard libraries like crypt and bcrypt - please don't invent your own scheme]. so when someone steals the password list they get the salt too. the salt is not "secret" - it is stored in plain text for each password. it does not need to be secret to do its job (defend against rainbow tables).

Sometimes the salt is stored with the password. I sometimes see having a hardcoded salt referred to as 'security by obscurity', but considering that many attacks result in just a database dump, not giving attackers access to (at least part of) the hash is a useful security layer.

Re: How To Safely Store A Password

#134

Post by cperciva »

tptacek wrote: post #36
tzs wrote: post #26

Why not PBKDF2?

PBKDF2 is fine. bcrypt has better library support. I'd rather you used a bcrypt library than try to roll your own PBKDF2.

bcrypt is also slightly stronger than PBKDF2, since it requires a larger circuit to compute.

The only reason you would want to use PBKDF2 is if (a) you already have a hash and don't want to add blowfish to your code/circuit, or (b) you want to be standards-compliant.

Re: How To Safely Store A Password

#135

Post by roel_v »

brown9-2 wrote: post #104
praptak wrote: post #89

Earlier quoted context omitted.

"If someone managed to break in to your website and get the password hashes, chances are they also have your "secret" salt." I believe the GP was referring to the scheme where you don't store the salts at all (or only store some bits of each salt.) The verification needs to brute-force the salt (or the missing bits) each time it verifies the password. The missing bits are quite similar to the bcrypt workfactor - the…

Then how in the world does your code know what salt to use when the user presents his or her password? If it is derived in code from some other piece of user data then it is still "known" if your DB leaks - you have to assume someone who stole your database also stole your code.

"you have to assume someone who stole your database also stole your code."

Maybe, but that doesn't mean that a separate salt, not in the database, will prevent certain attacks, and as such is a viable option. Security is about layering, not about 'xyz isn't 100% secure in 100% of the cases, forget about it'.

Re: How To Safely Store A Password

#136

Post by praptak »

brown9-2 wrote: post #104
praptak wrote: post #89

Earlier quoted context omitted.

"If someone managed to break in to your website and get the password hashes, chances are they also have your "secret" salt." I believe the GP was referring to the scheme where you don't store the salts at all (or only store some bits of each salt.) The verification needs to brute-force the salt (or the missing bits) each time it verifies the password. The missing bits are quite similar to the bcrypt workfactor - the…

Then how in the world does your code know what salt to use when the user presents his or her password? If it is derived in code from some other piece of user data then it is still "known" if your DB leaks - you have to assume someone who stole your database also stole your code.

"Then how in the world does your code know what salt to use when the user presents his or her password?"

It brute forces the missing part. Obviously you may only leave out a number of bits that keeps it feasible.

Re: How To Safely Store A Password

#137

Post by cperciva »

llambda wrote: post #93
praptak wrote: post #90

You can add the configurable slowness factor to any secure hash. Just use salts but leave out k bits from each when storing them. The more bits you leave out, the more work it takes to verify a password as the verification procedure needs to brute-force the missing k bits.

Even so this doesn't account for another advantage of bcrypt: its "de-optimized" key scheduler, which adds to the difficulty of cracking the hash.

The key scheduler in bcrypt is a red herring. I don't know what was going through their minds when they wrote that. They could have used a larger number of iterations and gotten the same result.

The only reason why bcrypt is better than PBKDF2 is that blowfish needs a large circuit to compute.

Re: How To Safely Store A Password

#138

Post by barefoot »

Fargren wrote: post #125
eneveu wrote: post #110

Many developers need to read and understand this. It is far from mainstream knowledge... The other day, I saw the following post about password hashing in my RSS feed: http://isc.sans.org/diary.html?storyid=11110 - No mention of bcrypt (though the posts mentions key stretching using SHA1) - "When selecting an algorithm to hash passwords, it is important to select carefully as it is difficult to change the algorithm l…

I know very little about security, but is there something wrong with using a hash in the client side and then using bcrypt on the server so that you never receive the plain text password?

Hashing passwords on the client indicates that the salt is available to the client. In the event of a database compromise it's guaranteed then that the attacker will have the salt and be able to crack your passwords.

If the salt is stored on the server, in a login.php script for example, and there is (just) a database compromise then an attacker will be at a disadvantage because they will need to figure out the salt first before cracking any of the passwords.

In fact, this is something being ignored here quite a bit. A number of potential attacks only lead to the database - or part of it - being exposed. If you have a large enough salt stored in your unaffected code base then an attacker is going to have a hard time.

Re: How To Safely Store A Password

#139

Post by dmd »

icebraining wrote: post #105
tzs wrote: post #28

I'd like to see sites offer the option of not using password-based authentication. Instead I'd like to see public key based authentication as an option. Basically, the site would have a copy of my public key (say my GPG key or an ssh key), and to authenticate I prove that I have access to the corresponding private key.

I'd prefer they'd use OpenID. It would be easier for them to implement, and it'd let you use PKI with providers like https://certifi.ca/

certifi.ca's very own cert is expired. That doesn't make me trust them much.
Post reply on HN