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

21–30 of 144 posts

Re: Storing Passwords Securely

#21

Post by tptacek »

peeters wrote: post #15

I used to hear some controversy with regards to "stretching." The argument back in the day was, "it's partially security through obscurity, but the danger is that there isn't research to prove that a hash of a hash is cryptographically strong." So is there research that proves that hashing a hash of a hash of a hash (x100000) doesn't result in a smaller range of values than a single hash for SHA algorithms? Is there…

Stretching isn't "security through obscurity". It's "security through increasing the attacker's cost by a huge amount while increasing your own cost by a minimal amount".

But don't use stretched SHA1. Use bcrypt or scrypt or PBKDF2, all of which explicitly address this particular concern.

Re: Storing Passwords Securely

#22

Post by rmc »

trjordan wrote: post #5

OK, so I get the message. Use bcrypt. Don't worry, that's what I'll do in production. On the other hand, if it's so hard to roll your own, can somebody point out the security flaws in the given Python function? Seems pretty straightforward to my untrained eye.

The check of hash to input uses == which will shortcircuit and return quicker as you guess the leading digits allowing you to figure out what the hash is. (i.e. a timing attack)

Re: Storing Passwords Securely

#24

Post by tptacek »

rmc wrote: post #22
trjordan wrote: post #5

OK, so I get the message. Use bcrypt. Don't worry, that's what I'll do in production. On the other hand, if it's so hard to roll your own, can somebody point out the security flaws in the given Python function? Seems pretty straightforward to my untrained eye.

The check of hash to input uses == which will shortcircuit and return quicker as you guess the leading digits allowing you to figure out what the hash is. (i.e. a timing attack)

Try to explain how you would actually conduct that timing attack to see why it isn't one.

Re: Storing Passwords Securely

#26

Post by indygreg2 »

tptacek wrote: post #24
rmc wrote: post #22

Earlier quoted context omitted.

The check of hash to input uses == which will shortcircuit and return quicker as you guess the leading digits allowing you to figure out what the hash is. (i.e. a timing attack)

Try to explain how you would actually conduct that timing attack to see why it isn't one.

If you are going to go through all the effort to do it properly, you might as well use a proper comparison function. If nothing else, it reinforces the knowledge that string comparisons can be part of security (which goes overlooked by many).

Re: Storing Passwords Securely

#27

Post by tptacek »

indygreg2 wrote: post #26
tptacek wrote: post #24

Earlier quoted context omitted.

Try to explain how you would actually conduct that timing attack to see why it isn't one.

If you are going to go through all the effort to do it properly, you might as well use a proper comparison function. If nothing else, it reinforces the knowledge that string comparisons can be part of security (which goes overlooked by many).

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

Re: Storing Passwords Securely

#28

Post by mparlane »

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.
Post reply on HN