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

21–30 of 110 posts

Re: How To Safely Store A Password

#21

Post by codahale »

huhtenberg wrote: post #19

I really don't want to use this word, but this is retarded . Something like RFC 2898 would be a good starting point for explaining why. http://www.ietf.org/rfc/rfc2898.txt

I'm guessing you haven't read Provos and Mazières' USENIX paper. In the design considerations, they say:

In general, a password algorithm, whatever its cost, should execute with near optimal efficiency in any setting in which it sees legitimate use, while offering little opportunity for speedup in other contexts.

PBKDF1 and PBKDF2 both rely upon general-purpose hash functions, which are much faster in dedicated computing environments such as FPGA or GPU clusters. The Eksblowfish algorithm at the heart of bcrypt is extremely resistent to optimization.

This is crucial for password storage, since if a CUDA implementation is 3-4 orders of magnitude faster than the implementation your application uses, you've just chipped off a huge chunk of the advantage offered by your hash function.

Re: How To Safely Store A Password

#22

Post by codahale »

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…

I'm familiar with cperciva's scrypt, and I think it's a great solution. That said, I've only seen C and Ruby bindings for it.

I'd love to recommend its use over bcrypt, as memory constraints are much more expensive than computational constraints, but recommending something most developers don't have access to would result in more weak hashing schemes in production.

Re: How To Safely Store A Password

#23

Post by prodigal_erik »

jrockway wrote: post #16
tptacek wrote: post #3

But wait. What if I use a 64 bit salt and then AES-encrypt the password with a key I store half on my server and half in a cookie I send to the user and then they'd have to break AES to get my passwords? How about that , Coda Hale?

Only experts should be allowed to innovate in the security domain. Passwords on lolcats are serious business! We certainly don't want people in the software engineering industry to come up with new ideas, implement them, and see how they work in real life. That could lead to advancement in the field, and that would be bad, because I might have to learn something new. Shudder.

Unlike most areas of software design, security is adversarial. If you innovate, you are betting your users' privacy on you personally being able to stay ahead of every attackers' ability to find flaws. This becomes unethical if you aren't even familiar with the current state of the art, because some attackers surely are.

Re: How To Safely Store A Password

#24

Post by tptacek »

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 settled for "salted hashes". At the whim of their attackers, hundreds or thousands of their user's passwords are going to hit Rapidshare. That's what the devs will be famous for.

Bcrypt keeps that from happening. You'll get famous behind losing 1000 passwords. You won't get famous behind losing 20.

Re: How To Safely Store A Password

#25

Post by tptacek »

huhtenberg wrote: post #19

I really don't want to use this word, but this is retarded . Something like RFC 2898 would be a good starting point for explaining why. http://www.ietf.org/rfc/rfc2898.txt

What a bizarre comment. PBKDFn and bcrypt are two very similar approaches to the same problem. If you're married to PKCS/IETF standards, go ahead and use PBKDF2. You're still essentially following the advice of this blog post.

Re: How To Safely Store A Password

#26

Post by jmillikin »

necubi wrote: post #11
jmillikin wrote: post #2

The article is using a definition of "store" of which I was previously unaware. If you'd like to store passwords (eg, in a keyring or password manager), use GPG.

The article is talking about the problem of storing passwords in a database in order to authenticate logins. This is for people writing web-apps, not users looking to secure their own passwords.

The passwords aren't being stored, though; a value derived from them is. In a properly designed system, it is computationally infeasible for an attacker to obtain the original password given the derived value.

Re: How To Safely Store A Password

#28

Post by codahale »

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...

Re: How To Safely Store A Password

#29

Post by kelnos »

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 will just do:

  passwd_str = bcrypt_string_from_password(passwd);
  db_store_password(userid, passwd_str);
and just be done with it, rather than having to decide between ROT13 (kidding), hashing, salted hashing, HMAC, etc. A couple years ago I thought applying SHA1 to a password before storing it in the DB was perfectly fine. Later I discovered that it was better to use a salt. More recently I've discovered that both of those approaches are flawed. Fortunately I've never written a large-scale application that deals with storing passwords, but I'm sure there are many application developers like me who would write much safer password storage routines if they didn't have to be the one to select an algorithm.

Now, I'm not saying bcrypt is the answer (I know nothing about it beyond what I've read on HN), but that's the general problem with your hypothetical proposal.

Re: How To Safely Store A Password

#30

Post by ErrantX »

derefr wrote: post #9
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?

Make the client's computer do the work.

That defeats the point of the hashing :)
Post reply on HN