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

101–110 of 215 posts

Re: How To Safely Store A Password

#101

Post by ay »

JoachimSchipper wrote: post #63
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.)

I ponder the quality of the GUI is a testament to the frequency of the mechanism's use.

But the worse GUI is arguably better than no GUI at all:

http://code.google.com/p/android/issues/detail?id=8196 and http://stackoverflow.com/questions/357491/iphone-client-cert...

So, for the purposes of the growing mobile browser market (where having this would be the biggest benefit IMO), this is not applicable.

Which is a bit unfortunate.

Re: How To Safely Store A Password

#103

Post by brown9-2 »

Tichy wrote: post #81

So I assume if you use bcrypt, you only verify the password once upon login, and then store a cookie that verifies the user is logged in? That brings other security risks. But the alternative seems to be to make every request very slow, because it would require bcrypting the password with every request.

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?

Re: How To Safely Store A Password

#104

Post by brown9-2 »

praptak wrote: post #89
Xk wrote: post #31

Earlier quoted context omitted.

No. Not at all. If someone managed to break in to your website and get the password hashes, chances are they also have your "secret" salt. There is no reason to separate the salt from the hash, and, in fact, there are no implementations which do that. However, if I can't convince you of that, then if you ever make a website that takes passwords, please use bcrypt. You can do your super-special-salt-separation-scheme,…

"If someone managed to break in to your website and get the password hashes, chances are they also have your "secret" salt." I believe the GP was referring to the scheme where you don't store the salts at all (or only store some bits of each salt.) The verification needs to brute-force the salt (or the missing bits) each time it verifies the password. The missing bits are quite similar to the bcrypt workfactor - the…

Then how in the world does your code know what salt to use when the user presents his or her password?

If it is derived in code from some other piece of user data then it is still "known" if your DB leaks - you have to assume someone who stole your database also stole your code.

Re: How To Safely Store A Password

#105

Post by icebraining »

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.

I'd prefer they'd use OpenID. It would be easier for them to implement, and it'd let you use PKI with providers like https://certifi.ca/

Re: How To Safely Store A Password

#106

Post by icebraining »

rubinelli wrote: post #98
swombat wrote: post #87

Earlier quoted context omitted.

Passports and social security cards are physical items. Because of this, they have the inherent property of not being capable of ubiquity. If someone steals your passport, you'll know: you won't be able to find it. Digital keys have no such properties. If someone steals your private key, you will have no idea until you see them steal all your money and accounts. Physical items also need to be carried to a destination…

The Brazilian government has been trying to popularize digital certificates stored in smart cards and tamper-proof USB tokens that seem to be a solution to the problems you pointed at. The main barrier to adoption right now is cost, mainly because certificate issuers have little competition and a good chunk of money between infrastructure and concession fees to recoup.

Here in Portugal our new national ID cards all have a public/private key pair and the card itself can sign stuff without copying the private key to the machine, making the process very safe even when using it on a public machine.

In a couple of years everyone will have on of those cards, the problem is that nobody has readers.

Re: How To Safely Store A Password

#107

Post by j_s »

swombat wrote: post #87
ihodes wrote: post #57

Earlier quoted context omitted.

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.

Passports and social security cards are physical items. Because of this, they have the inherent property of not being capable of ubiquity. If someone steals your passport, you'll know: you won't be able to find it. Digital keys have no such properties. If someone steals your private key, you will have no idea until you see them steal all your money and accounts. Physical items also need to be carried to a destination…

The US military uses smart cards with X.509 certificates for authentication: http://en.wikipedia.org/wiki/Common_Access_Card

Re: How To Safely Store A Password

#108

Post by caf »

sunchild wrote: post #72
caf wrote: post #32

Earlier quoted context omitted.

That's already possible with SSL sites - sign up for an account at www.startssl.com if you want to see a real-life example.

Oops! StartSSL was compromised this month, although they say the issue is remediated now. http://news.netcraft.com/archives/2011/06/22/startssl-suspen...

Yes, using client certificates for authentication does not make your service immune from security problems.

Re: How To Safely Store A Password

#109

Post by icebraining »

praptak wrote: post #90

You can add the configurable slowness factor to any secure hash. Just use salts but leave out k bits from each when storing them. The more bits you leave out, the more work it takes to verify a password as the verification procedure needs to brute-force the missing k bits.

If you leave out bits, any password whose hash matches the rest will work, even if it doesn't match the 'lost bits' (since your login server won't be able to verify that, obviously). The only thing you've accomplished is to make the cracker's life easier.

Re: How To Safely Store A Password

#110

Post by eneveu »

Many developers need to read and understand this. It is far from mainstream knowledge...

The other day, I saw the following post about password hashing in my RSS feed: http://isc.sans.org/diary.html?storyid=11110

- No mention of bcrypt (though the posts mentions key stretching using SHA1)

- "When selecting an algorithm to hash passwords, it is important to select carefully as it is difficult to change the algorithm later. You will have to ask users to change their password if you do as you no longer know what password they picked." --> seriously? you can update the password the next time they log in...

- "You could also add a secret, in addition to the salt. If the secret is not stored in the database, it would not be easily reachable via a SQL injection exploit (yes, you can use them to read files, but it requires sufficient privileges)." --> security through obscurity, nice

- "For the paranoid, you may want to do the hashing on the client side (javascript) . This way, the server never receives the plain text password. We do this here for the ISC website on our login form [2]." --> oh noes...

Note that the blog has ~15k subscribers according to Google Reader...

---------

I also launched a debate on StackOverflow the other day. A self-proclaimed "security expert" (he later edited his post to remove this part) was advising against using bcrypt, arguing that it would facilitate DOS attacks against the login page... He prefers security through obscurity, using a secret salt:

http://security.stackexchange.com/questions/4781/do-any-secu...

I thought it was a bad idea to leave this answer unchallenged, so I tried arguing with him. I was met with arguments of authority such as "Wow you are out of your element and could not be more misguided on this topic" or "you disagree because you don't understand. Show me an exploit you have written, then I'll pay attention to you.". Happily, some (more experienced) people got in on the debate. I hope this will help developers make an informed choice, if they stumble upon his answer...

(edit: list formatting)

Post reply on HN