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

51–60 of 215 posts

Re: How To Safely Store A Password

#51

Post by Fjolle »

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…

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

That unfortunately puts a lot of confidence in the security of the sites that you give your password to. Your super safe password is not that safe if a site stores it as plaintext or MD5 and it gets hacked.

Otherwise I agree with your comment.

Re: How To Safely Store A Password

#52

Post by peteretep »

I recently put together a commentary + code on how to upgrade passwords hashed insecurely in your DB without user intervention. This was in response to MtGox talking about "slowly migrating users", which presumably means upgrading passwords at the point of login:

https://gist.github.com/1051238

Re: How To Safely Store A Password

#53

Post by peteretep »

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?

Here is an example:

https://gist.github.com/1051238

Re: How To Safely Store A Password

#54

Post by tjogin »

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…

A middle ground would be to generate password suggestions, but give the user the option to change his/her own password.

I used a method a few years ago to generate passwords for users on an intranet. They were free to replace them, but a poll showed that most users went with the suggested password. I focused on generating passwords that users could pronounce (and therefore remember), like gekava86, lofesu75, 23wopeni, etc.

At the time, I didn't use BCrypt so they were a bit weak (though certainly stronger than whatever the users' regular password was). If you use BCrypt, you don't have to worry as much about the password being "strong", the focus comes back to it being unique.

Re: How To Safely Store A Password

#55

Post by alanfalcon »

kriardol wrote: post #42
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…

I personally hate it when sites do this. That's probably the best way to make sure I don't come back, as I'm not likely to remember the generated password. Worse, how do you give them the password? Email?

Also you have to trust the website: They shouldn't know your password, but if they just gave it to you then how do you know they're not keeping a copy themselves somewhere?

Re: How To Safely Store A Password

#56

Post by mahyarm »

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.

What do you do when you loose the keys? And the default behavior or enabling keys whenever your computer is open? One click bank account access?

Re: How To Safely Store A Password

#57

Post by ihodes »

mahyarm wrote: post #56
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.

What do you do when you loose the keys? And the default behavior or enabling keys whenever your computer is open? One click bank account access?

    What do you do when you loose the keys?
You don't. And ideally you have a single key. If you can be trusted to keep a social security card and a passport, you can just as easily keep a key safe. Print it out. Store it in a safe place. We've been doing that for centuries.

    And the default behavior or enabling keys whenever your computer is open?
You can password protect your keys.

Re: How To Safely Store A Password

#58

Post by bsiemon »

alanfalcon wrote: post #55
kriardol wrote: post #42

Earlier quoted context omitted.

I personally hate it when sites do this. That's probably the best way to make sure I don't come back, as I'm not likely to remember the generated password. Worse, how do you give them the password? Email?

Also you have to trust the website: They shouldn't know your password, but if they just gave it to you then how do you know they're not keeping a copy themselves somewhere?

Can you stop a website that wants to save your password?

Re: How To Safely Store A Password

#59

Post by cookingrobot »

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…

Could you design a system where the hard work happens on the client side? For ex, the server sends the client a secret encrypted with the bcrypt hash.. and then the client machine spends a couple seconds working on it and sends back the response. It might allow for a huge work factor without impacting the server.
Post reply on HN