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

141–150 of 215 posts

Re: How To Safely Store A Password

#141

Post by pixeloution »

chops wrote: post #14
nonane wrote: post #12

The article claims it takes bcrypt 0.3 seconds to hash a 4 char password on a laptop. How does a server authenticate users in high volume with bcrypt? ~0.25 secs per auth request might warrant having a separate server just for authentication.

It depends on the work factor. On my dev server (a pretty old machine), with a work factor of 7, it's about 300 time slower than md5 (about 10ms per bcrypt hash). That's still plenty fast, and much more secure. Bump it to a work factor of 9, and I'm looking at about 1000 times slower (or getting close to 40 ms per hash). Part of its beauty is you can adjust the work factor to match your hardware speed requirements. I…

bcrypt at 10ms only being 300 times slower would indicate you can only try 30,000 MD5 hashes per second -- which is incorrect. Using a GPU based cracker on a current generation top-end video card you can calculate over 300 million per second.

Bcrypt at 10ms is 3 million times slower, not 300 times.

Re: How To Safely Store A Password

#143

Post by eneveu »

Someone wrote: post #130
Fargren wrote: post #125

Earlier quoted context omitted.

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?

If the client sends hash(password) to the server, hash(password), for all intents and purposes, _is_ the password. After all, an attacker does not need to recover the password from the hash, all he has to do is capture the hash and replay it.

This.

Also, tptacek made a few interesting comments about client-side cryptography:

http://news.ycombinator.com/item?id=1755713

http://news.ycombinator.com/item?id=1756394

http://news.ycombinator.com/item?id=1001007

http://news.ycombinator.com/item?id=1411621

Re: How To Safely Store A Password

#144

Post by Jach »

vog wrote: post #82
ihodes wrote: post #62

Earlier quoted context omitted.

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…

I fully agree, but I'd focus more on the length than on the character set. It is not a problem if the password contains only alphanum characters, as long as those are random. For instance, a plain alphanum password of length 9 is stronger than a password of length 8 that allows for special characters. (because 62^9 > 94^8) In other words, adding one character to your password is as good as choosing from a bigger char…

C^x grows a lot faster than x^C, except for specific x's and C's you're almost always much better off adding to the length. And 20's nuttin'. At the risk of publishing more hastily written code for critiquing, here's a shell script password generator I use sometimes. https://gist.github.com/1058565

Re: How To Safely Store A Password

#145

Post by antihero »

chops wrote: post #10
Khao wrote: post #5

I have read this article and read the Wikipedia entry on bcrypt and I still cannot understand something. In this article it states that : "As computers get faster you can increase the work factor and the hash will get slower.". How can you make the algorithm slower over time and still be able to validate user passwords that were stored before you changed the speed? Could anyone enlighten me on this?

The easy way is to support the previous work factors and increase it next time the user logs in (since you'll have the password in plaintext in memory). Either way, bcrypt with a paltry work factor of 7 or 8 is orders of magnitude slower than md5 and sha. Jack that up to 12 or 13 and you're pretty much good to go for years, the only problem is the near 1-second processing time on semi-current hardware.

If you know the previous work factor of a hash, you could of course re-hash it New-Old factor times.

Re: How To Safely Store A Password

#146

Post by podperson »

roel_v wrote: post #119
podperson wrote: post #17

Earlier quoted context omitted.

It's a hash function and, at least over an insecure connection, you should not be transferring the plaintext password from client to server so it's not guaranteed that you will have the plaintext password. Assuming you're using a secure connection and you're willing to send plaintext passwords over it then yes, you could re-hash the password when a user logs in.

It's rather obvious that we're talking about a system in which the client submits the clear-text password to the server, and of course that should be done over SSL.

The vast majority of site authentications (including many very large sites) use http, so their authentication code should be hashing and salting the password on the client-side and sending the result to the server for authentication. In this model, the site never actually has a plaintext copy of the password.

In this model, the server would receive the (unsalted) hash of the password when the password is set, and a salted hash for each login. At no point will the server ever have the plaintext password.

I describe the implementation details here:

http://loewald.com/blog/?p=1374

Re: How To Safely Store A Password

#147

Post by nokcha »

rgarcia wrote: post #128
Fargren wrote: post #125

Earlier quoted context omitted.

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?

I'm no security expert either, but I'm guessing the real solution is SSL. If you hash passwords in javascript, a middleman could easily just look up the source of your application and decrypt the hashed password coming over the wire.

>If you hash passwords in javascript, a middleman could easily just look up the source of your application and decrypt the hashed password coming over the wire.

Hashing ≠ Encryption.

Unlike encryption, where an encrypted message is intended to be decrypted by a trusted party, a hashed password is never intended to be 'unhashed'. Rather, the hash of the password supplied by the user is compared against the hash value stored in the database. Given a sufficiently strong password P, it should be computationally infeasible for anyone to compute the value of P from hash(P).

Re: How To Safely Store A Password

#148

Post by nlco »

barefoot wrote: post #138
Fargren wrote: post #125

Earlier quoted context omitted.

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…

Salts are suppose to be considered public. For the most part, they are defenses against rainbow tables and to make an attacker have crack each password individually.

Re: How To Safely Store A Password

#149

Post by jpeterson »

Tichy wrote: post #117
brown9-2 wrote: post #103

Earlier quoted context omitted.

If you were to re-authenticate the user on every request, how do you have the client send the password to the server on every request without making the user enter it every time?

By storing it in a cookie - oh :-) I suppose you could come up with some scheme where you create a new cookie with every request, a kind of one-time cookie to prevent session hijacking. Probably not worth it and not 100% reliable, though. I guess just trusting in cookies is the only real option. Or HTTP BasicAuth, it sends the password with every request I think (unencrypted, I know). In either case in theory you nee…

Oh man, please tell me I'm misreading you, and you don't actually store your users' usernames and passwords in a cookie.

Re: How To Safely Store A Password

#150

Post by SamReidHughes »

JoachimSchipper wrote: post #80
SamReidHughes wrote: post #74

Earlier quoted context omitted.

Timing attacks are not a problem if you're using it to hash passwords. Also, Javascript implementations don't use doubles for pure integer arithmetic.

If I can observe your (SSL-encrypted) login session, I can time how long the server takes to process your (presumably real) password. What makes you think password hashes don't need to worry about this?

Doh! To answer your question, probably the fact that it was late, or that I'm an idiot.
Post reply on HN