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

31–40 of 110 posts

Re: How To Safely Store A Password

#31

Post by kelnos »

sordidarray wrote: post #20

I disagree wholeheartedly. The article is based around the fallacy we've seen time and time again, of throwing more cryptography at a problem that cryptography alone cannot solve. In the end, a crappy password is a crappy password. Successfully discouraging your users from using a crappy password has much better repercussions (for the user, for you, and for the web in general) than switching from a hash-based authent…

You're talking about a completely different problem.

Yes, many users pick crappy passwords. That's a social problem, one that is difficult to address with technology[1].

Storing passwords on the server is unrelated to whether or not the user picked a good password. If an attacker gets ahold of a copy of your database, they will have a much easier time of turning SHA1 hashes of passwords into actual passwords than of turning bcrypt-encrypted passwords into actual passwords (the latter being orders of magnitude more difficult, maybe to the point of being impractical as a target vector).

[1] You can always do things like require certain types of password complexity: minimum length, choice of characters from different character classes and cases, etc. But then you end up just moving the problem elsewhere: instead of using the crappy password they remember, the user has to write down their complex password, or maybe even store it in a text file on their hard drive.

Re: How To Safely Store A Password

#32

Post by ErrantX »

skjlnSAjd wrote: post #8

The problem with using a scheme designed to be computationally intensive is that it doesn't scale. How can I justify 0.3 seconds of computation time if I'm dealing with tens of thousands of connections per second?

If those tens of thousands of connections per second are tens of thousands on logins, per second, then the computational value of your hash function seems likely to be the least of your problems :)

Re: How To Safely Store A Password

#33

Post by sordidarray »

tptacek wrote: post #24
sordidarray wrote: post #20

I disagree wholeheartedly. The article is based around the fallacy we've seen time and time again, of throwing more cryptography at a problem that cryptography alone cannot solve. In the end, a crappy password is a crappy password. Successfully discouraging your users from using a crappy password has much better repercussions (for the user, for you, and for the web in general) than switching from a hash-based authent…

The mistake you're making is thinking of bcrypt as a protection for end-users and their passwords. It isn't. Bcrypt exists to protect application developers. A user with a crappy password is getting his account busted one way or another. You're right to point that out. Cryptography won't solve that problem. The problem crypto solves is this: a crappy web app that loses its user table is royally screwed if its devs se…

A poorly-written web app whose SQL database is compromised has bigger problems than protecting the integrity of poorly chosen passwords (especially if they store financial information).

Losing such a collection of salted hashes does not render one "royally screwed." Those hashes (or HMACs) are still cryptographically secure, which means it's computationally infeasible to find a first preimage provided the password doesn't suck. You seem to think (or are at least implying) that bcrypt is impervious to standard iterative bruteforce attacks, but that's just not the case. Much like PBKDF2, and other iterative hashing techniques, bcrypt is more resistant, but still "vulnerable" to such an "attack." bcrypt's main advantage over other iterative techniques, in my opinion, is the 4KiB of s-boxes used by Blowfish.

Re: How To Safely Store A Password

#34

Post by ErrantX »

kelnos wrote: post #29
runn1ng wrote: post #27

What is the difference, then, between using bcrypt and iterating MD5 10^6 times?

Presumably, bcrypt is something that has been vetted by crypto experts, whereas your idea is just some random thing you thought up. Maybe you personally are a crypto expert and know for a fact that your plan will work, but the vast majority of people aren't. A packaged solution like bcrypt that doesn't give the developer enough rope to hang themselves (and their users) is a much better idea. The idea is a developer w…

whereas your idea is just some random thing you thought up

He might also have got the idea from one of tptacek's suggestions not long ago.

The difference between doing the iterations and bcrypt is.. well.. not massive in a practical sense. You could do either (if your already MD5'ing passwords once [hmmmm], for example, then it is a quicker solution)

Re: How To Safely Store A Password

#35

Post by dfranke »

runn1ng wrote: post #27

What is the difference, then, between using bcrypt and iterating MD5 10^6 times?

Nothing enormous; that's basically what PBKDF1 does. cperciva might correct me on this, but IIRC there are some minor concerns, addressed by PBKDF2, which is a slightly more complicated construction, about the iterated hash function degenerating into cycles. I don't think there have ever been any practical results exploiting this. PBKDF2 is just as good a choice as bcrypt, and a better-supported one.

Re: How To Safely Store A Password

#36

Post by steveplace »

codahale wrote: post #28
sordidarray wrote: post #20

I disagree wholeheartedly. The article is based around the fallacy we've seen time and time again, of throwing more cryptography at a problem that cryptography alone cannot solve. In the end, a crappy password is a crappy password. Successfully discouraging your users from using a crappy password has much better repercussions (for the user, for you, and for the web in general) than switching from a hash-based authent…

Also, you point out that "successfully discouraging your users from using a crappy password has much better repercussions." This is true, and I'm curious to know how you personally achieve this with your users, given that the vast majority[1] of users choose spectacularly crap passwords. [1] http://www.imperva.com/docs/WP_Consumer_Password_Worst_Pract...

https://twitter.com/signup

Start typing in the pw box, if it's not strong enough, they'll let you know.

Also, try "123456" or "password"

Re: How To Safely Store A Password

#37

Post by cperciva »

dfranke wrote: post #35
runn1ng wrote: post #27

What is the difference, then, between using bcrypt and iterating MD5 10^6 times?

Nothing enormous; that's basically what PBKDF1 does. cperciva might correct me on this, but IIRC there are some minor concerns, addressed by PBKDF2, which is a slightly more complicated construction, about the iterated hash function degenerating into cycles. I don't think there have ever been any practical results exploiting this. PBKDF2 is just as good a choice as bcrypt, and a better-supported one.

100% correct until the last sentence. :-)

PBKDF2 is just as good a choice as bcrypt

bcrypt has a slight advantage over PBKDF2 in that it requires a larger ASIC area. It's only a constant factor better than PBKDF2, but making an attack 5x more expensive is still somewhat useful.

Re: How To Safely Store A Password

#39

Post by sordidarray »

kelnos wrote: post #31
sordidarray wrote: post #20

I disagree wholeheartedly. The article is based around the fallacy we've seen time and time again, of throwing more cryptography at a problem that cryptography alone cannot solve. In the end, a crappy password is a crappy password. Successfully discouraging your users from using a crappy password has much better repercussions (for the user, for you, and for the web in general) than switching from a hash-based authent…

You're talking about a completely different problem. Yes, many users pick crappy passwords. That's a social problem, one that is difficult to address with technology[1]. Storing passwords on the server is unrelated to whether or not the user picked a good password. If an attacker gets ahold of a copy of your database, they will have a much easier time of turning SHA1 hashes of passwords into actual passwords than of…

I'm not talking about a different problem.

The bruteforce attack described in the article primarily affects short and dictionary-based passwords. If the password is of sufficient length and complexity (the keyspace is large enough), then bruteforcing becomes computationally infeasible. What the article proposes is, essentially, to use a more computationally expensive algorithm for the benefit of protecting shorter, weaker, passwords. I disagree, and think that increasing the computational cost of the algorithm itself should be used to enhance the security of passwords, rather than having their security depend entirely on that increased cost.

Good passwords stored as a salted hash, or preferably, as an HMAC, are in no way insecure. I feel that implying otherwise is a disservice.

Re: How To Safely Store A Password

#40

Post by tptacek »

sordidarray wrote: post #33
tptacek wrote: post #24

Earlier quoted context omitted.

The mistake you're making is thinking of bcrypt as a protection for end-users and their passwords. It isn't. Bcrypt exists to protect application developers. A user with a crappy password is getting his account busted one way or another. You're right to point that out. Cryptography won't solve that problem. The problem crypto solves is this: a crappy web app that loses its user table is royally screwed if its devs se…

A poorly-written web app whose SQL database is compromised has bigger problems than protecting the integrity of poorly chosen passwords (especially if they store financial information). Losing such a collection of salted hashes does not render one "royally screwed." Those hashes (or HMACs) are still cryptographically secure, which means it's computationally infeasible to find a first preimage provided the password do…

Losing a Unix password file in the 1990s would have been newsworthy. Password files were "secured" using Unix crypt(3), an algorithm that at least made a nod towards resisting brute force attacks --- so much so that when PHK wrote FreeBSD's md5 scheme, he iterated it PBKDF-style, because even then it was clear that using cryptographic hashes "straight" was a bad idea.

The biggest differences between Mindvox losing it's password file in 1995 and a webapp losing its user table in 2010 are:

* Web apps are getting fielded with straight SHA1 hashes, which is inferior even to FreeBSD's original MD5 hash scheme.

* Brute force attacks have gotten much faster.

The main advantage to bcrypt over, say, AES, is that the key setup is really slow. Mazieres spotted a weakness in Blowfish and turned it into a benefit.

Is there some real argument you have with me? I agree: if you lose your user table, you have real problems apart from losing password hashes --- though we could bicker about which of those problems is worse. Where are you disagreeing with me?

Post reply on HN