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

61–70 of 215 posts

Re: How To Safely Store A Password

#61

Post by JoachimSchipper »

yogsototh wrote: post #60

I am surprised nobody had already talked about scrypt yet. Here is an old hackernews entry about it. http://news.ycombinator.com/item?id=601408 I would have loved to use scrypt, but there is only a C implementation. I would had loved to have at least a javascript one.

Javascript? Have fun securing that one against timing attacks. Also, it's so much slower than the C implementation (remember that crypto algorithms are very carefully designed for 32- or 64-bit words or arbitrary-length integers; Javascript's doubles are a very poor match.)

Re: How To Safely Store A Password

#62

Post by ihodes »

Jach wrote: post #44
tomjen3 wrote: post #41

What always annoys me with the discussion of passwords is that everybody here focus on a technical solution that allows the user to continue to use insecure passwords. That isn't the problem. Reuse is. And the best way around that is to not let the user select the password, just generate it server side. Technically this is easier to get right than some complex password generation scheme and the end result is properly…

Reuse is a problem, but weak passwords are the biggest problem. If you have a strong password that never gets cracked/leaked/intercepted but you use it everywhere you're still fine, but that's not recommended. Generating server-side passwords is horrible as well since you're counting on the user to write it down and/or let the browser's password manager save it. What if the user wants to log in with a different machi…

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 over 8 thousand centuries if we're having bcrypt take 0.3 seconds.

So the problem is that passwords tend not to be random. This greatly decreases the problem-space. But b/scrypt solves the problem of length, within reason.

Re: How To Safely Store A Password

#63

Post by JoachimSchipper »

tzs wrote: post #28

I'd like to see sites offer the option of not using password-based authentication. Instead I'd like to see public key based authentication as an option. Basically, the site would have a copy of my public key (say my GPG key or an ssh key), and to authenticate I prove that I have access to the corresponding private key.

You've just described SSL with client certificates. Works perfectly well, is extremely secure, and has an extremely bad GUI in pretty much every browser ever. (It's somewhat difficult to use "on the road", but that's arguably a security feature.)

Re: How To Safely Store A Password

#64

Post by WA »

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.

An idea would be to use a JavaScript implementation of bcrypt to let clients do the math themselves and just send the encrypted password via HTTPS. This has several advantages. One being that the server-side performance is reduced heavily. Another one is that a password never shows up on the server in plaintext ever.

Disadvantage: Clients need to have JavaScript enabled.

Re: How To Safely Store A Password

#65

Post by JoachimSchipper »

Jach wrote: post #44
tomjen3 wrote: post #41

What always annoys me with the discussion of passwords is that everybody here focus on a technical solution that allows the user to continue to use insecure passwords. That isn't the problem. Reuse is. And the best way around that is to not let the user select the password, just generate it server side. Technically this is easier to get right than some complex password generation scheme and the end result is properly…

Reuse is a problem, but weak passwords are the biggest problem. If you have a strong password that never gets cracked/leaked/intercepted but you use it everywhere you're still fine, but that's not recommended. Generating server-side passwords is horrible as well since you're counting on the user to write it down and/or let the browser's password manager save it. What if the user wants to log in with a different machi…

That's a bit too simple - it won't catch password1 or iloveyou, both of which will definitely be tried by any decent cracker. Try http://www.openwall.com/passwdqc/, by Solar Designer (who has, among many other things, written the John the Ripper password cracker.)

Re: How To Safely Store A Password

#66

Post by JoachimSchipper »

WA wrote: post #64
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.

An idea would be to use a JavaScript implementation of bcrypt to let clients do the math themselves and just send the encrypted password via HTTPS. This has several advantages. One being that the server-side performance is reduced heavily. Another one is that a password never shows up on the server in plaintext ever. Disadvantage: Clients need to have JavaScript enabled.

That doesn't work. Among other issues, Javascript is so much slower than C or CUDA at such tasks (no native integers!) that the client is going to take forever to calculate a sufficiently-hard hash.

Re: How To Safely Store A Password

#67

Post by beaumartinez »

tomjen3 wrote: post #41

What always annoys me with the discussion of passwords is that everybody here focus on a technical solution that allows the user to continue to use insecure passwords. That isn't the problem. Reuse is. And the best way around that is to not let the user select the password, just generate it server side. Technically this is easier to get right than some complex password generation scheme and the end result is properly…

There are a lot of misconceptions on what makes a "secure" password—fluffy is puffy takes longer to crack than J4fS.

http://www.baekdal.com/tips/password-security-usability

Re: How To Safely Store A Password

#68

Post by espo »

WA wrote: post #64
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.

An idea would be to use a JavaScript implementation of bcrypt to let clients do the math themselves and just send the encrypted password via HTTPS. This has several advantages. One being that the server-side performance is reduced heavily. Another one is that a password never shows up on the server in plaintext ever. Disadvantage: Clients need to have JavaScript enabled.

If you are doing this, then the hash IS the password. That means if someone steals your database, the could log in as all of your users just by tweaking the client-side JavaScript with grease-monkey or similar.

Re: How To Safely Store A Password

#69

Post by WA »

JoachimSchipper wrote: post #66
WA wrote: post #64

Earlier quoted context omitted.

An idea would be to use a JavaScript implementation of bcrypt to let clients do the math themselves and just send the encrypted password via HTTPS. This has several advantages. One being that the server-side performance is reduced heavily. Another one is that a password never shows up on the server in plaintext ever. Disadvantage: Clients need to have JavaScript enabled.

That doesn't work. Among other issues, Javascript is so much slower than C or CUDA at such tasks (no native integers!) that the client is going to take forever to calculate a sufficiently-hard hash.

That might be a valid point. I just checked this: http://javascript-bcrypt.googlecode.com/hg/test.html The initialization phase takes very long.

Re: How To Safely Store A Password

#70

Post by WA »

espo wrote: post #68
WA wrote: post #64

Earlier quoted context omitted.

An idea would be to use a JavaScript implementation of bcrypt to let clients do the math themselves and just send the encrypted password via HTTPS. This has several advantages. One being that the server-side performance is reduced heavily. Another one is that a password never shows up on the server in plaintext ever. Disadvantage: Clients need to have JavaScript enabled.

If you are doing this, then the hash IS the password. That means if someone steals your database, the could log in as all of your users just by tweaking the client-side JavaScript with grease-monkey or similar.

Right. I just realize my approach is flawed ;)
Post reply on HN