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

51–60 of 144 posts

Re: Storing Passwords Securely

#51

Post by mparlane »

pmylund wrote: post #43
mparlane wrote: post #28

An even better way of securely storing your passwords would be to mix them around on entry to your bcrypt hash function in a unique way that makes it impossible to brute force your leaked password hashes without having access to the code that did them.

So something like a HMAC digest generated using a pepper stored in the source code/binary or on disk before passing it to bcrypt/scrypt? :) This only really protects against SQL injection attacks, though/when there is actually a separation between where you store the bcrypt digests and where you store the pepper. (Granted, there are a lot of SQL injection attacks.)

Exactly, most commonly with these things is that the db was dumped which does not imply that the source code was accessed. If the source code was accessed they normally don't need a db dump. (unless it was read-only)

The first section of the article IMHO was not needed in regards to a simple hash. Forums have been hashing their passwords with salts for how long now ?

Re: Storing Passwords Securely

#52

Post by technomancy »

jharding wrote: post #11

If you're storing passwords as MD5/SHA hashes, how difficult is it be to switch over to bcrypt? I've never had to do this, but I would imagine it would be somewhat trivial. With all of the password leaks that have happened over the past few years, I'd imagine a good amount of developers are aware that storing passwords as MD5/SHA hashes is somewhat risky, so I can't understand why big websites (LinkedIn) are still do…

We did it on Clojars, the Clojure library source, without much trouble:

https://github.com/ato/clojars-web/compare/68872652fc427cc1....

We had a month or two grace period in which anyone logging in would have their password upgraded to bcrypt automatically, then wiped the SHA1s.

https://groups.google.com/forum/#!msg/clojure/Xg1I0rgt85s/Vf...

Re: Storing Passwords Securely

#54

Post by tedunangst »

sillysaurus wrote: post #7

I know I won't be able to easily convince anyone of this, but I thought I'd mention... Colin Percival's "scrypt" password hash is: 1) production-ready (and has been for a long time) 2) superior to bcrypt, as it is designed to be expensive in both CPU and memory (hence, scrypt is "memory-hard", whereas bcrypt is not) I don't have time to go into further detail. I encourage you to check it out. It's quite simply "the f…

One thing to be careful is that you don't open yourself to a trival DOS. The default scrypt command line program will churn CPU for a full second when encrypting a file. If you use similar settings, it will not take an attacker many connections to reduce even a large cluster to tears.

Re: Storing Passwords Securely

#55

Post by njs12345 »

jharding wrote: post #11

If you're storing passwords as MD5/SHA hashes, how difficult is it be to switch over to bcrypt? I've never had to do this, but I would imagine it would be somewhat trivial. With all of the password leaks that have happened over the past few years, I'd imagine a good amount of developers are aware that storing passwords as MD5/SHA hashes is somewhat risky, so I can't understand why big websites (LinkedIn) are still do…

Could you use e.g. bcrypt(SHA1(x))? I think that should be OK, and avoids the issues with switching over current users (just take the bcrypt of the currently stored passwords).

Re: Storing Passwords Securely

#56

Post by tedunangst »

AgentConundrum wrote: post #49
sillysaurus wrote: post #7

I know I won't be able to easily convince anyone of this, but I thought I'd mention... Colin Percival's "scrypt" password hash is: 1) production-ready (and has been for a long time) 2) superior to bcrypt, as it is designed to be expensive in both CPU and memory (hence, scrypt is "memory-hard", whereas bcrypt is not) I don't have time to go into further detail. I encourage you to check it out. It's quite simply "the f…

I think I answered my own question, but I'll ask anyway - why does memory intensiveness matter?

GPUs (and similar hardware) have a very limited amount of memory per core. If computing a hash requires 100MB of memory, then even a 1GB graphics card can only execute 10 cracks in parallel, not hundreds or thousands.

Re: Storing Passwords Securely

#57

Post by pmylund »

mparlane wrote: post #51
pmylund wrote: post #43

Earlier quoted context omitted.

So something like a HMAC digest generated using a pepper stored in the source code/binary or on disk before passing it to bcrypt/scrypt? :) This only really protects against SQL injection attacks, though/when there is actually a separation between where you store the bcrypt digests and where you store the pepper. (Granted, there are a lot of SQL injection attacks.)

Exactly, most commonly with these things is that the db was dumped which does not imply that the source code was accessed. If the source code was accessed they normally don't need a db dump. (unless it was read-only) The first section of the article IMHO was not needed in regards to a simple hash. Forums have been hashing their passwords with salts for how long now ?

Sure, but I try to not make any assumptions without being boring. I think the goto-link at the beginning works fairly well.

Re: Storing Passwords Securely

#58

Post by tptacek »

indygreg2 wrote: post #35
tptacek wrote: post #27

Earlier quoted context omitted.

The == operator is a proper string comparison function in this setting.

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.

No, not assuming that. It has nothing to do with the specific steps. To see why, try to imagine a scenario where there could be an operator== timing attack on a password hash.

It feels sometimes like people hear about the idea of timing attacks and then want to see them everywhere.

Re: Storing Passwords Securely

#59

Post by tptacek »

shabble wrote: post #48
tptacek wrote: post #14

Earlier quoted context omitted.

SRP also has tunable work-factor knobs, although they aren't as explicit as the ones in bcrypt, scrypt, or PBKDF2. But I'd strongly recommend against re-implementing SRP, since it's treacherous to get right.

Of the implementations listed in the WP article, which, if any, are suitable for general purpose use? And what manner of implementation screwups are most likely|hazardous? [With the obvious caveat: Advice not for production use, If you have to ask...]

If you're going to use an SRP library, there's an open-source Stanford SRP library (most commercial systems derive from it) which deals with the obvious attacks.

Re: Storing Passwords Securely

#60

Post by pmylund »

stickfigure wrote: post #50
pmylund wrote: post #46

Earlier quoted context omitted.

OpenID and OAuth really did a lot, but there's just nothing called "don't use passwords." Fingerprint readers suck. Anything biometric that doesn't suck costs too much, and 99% of people don't have them. A good KDF is not bad in comparison to a centralized authentication server considering other factors. Someone, somewhere will be storing user passwords/digests for the foreseeable future. And they will do it incorrec…

Sure, but the number of those people should become vanishingly small over time. HN is full of web developers rolling unnecessary username/password solutions. The fact that this is such a hot issue - as opposed to esoterica like TCP frame size - shows that far too many developers are homebrewing solutions rather than outsourcing.

I agree, but "outsourcing" includes using libraries written by people who know what they're doing. (And not using libraries written by people who know what they're doing, but which are the wrong tools for the job.)
Post reply on HN