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

171–180 of 215 posts

Re: How To Safely Store A Password

#171

Post by dpark »

nokcha wrote: post #147
rgarcia wrote: post #128

Earlier quoted context omitted.

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…

Of course, if you're doing the hashing on the client, there's no need to reverse the hash anyway. An attacker can just replay the hash they sniffed. You can do some additional things to avoid this (like using a nonce as part of the hash), but the best solution is still to just use SSL.

Re: How To Safely Store A Password

#172

Post by dpark »

falcolas wrote: post #161

Honest question. Why would someone who handles more than a couple-dozen login attempts per second choose to use bcrypt? It would seem that the computational overhead of supporting bcrypt at scale would not make a lot of financial sense.

You can change the work factor to scale the amount of time it takes to do the processing. Beyond that, there's a cost to security. If you actually need security, you may need to pay for it. How much is it going to cost you to buy an extra server vs the loss of business due to a serious security breach?

Re: How To Safely Store A Password

#173

Post by elektronaut »

falcolas wrote: post #161

Honest question. Why would someone who handles more than a couple-dozen login attempts per second choose to use bcrypt? It would seem that the computational overhead of supporting bcrypt at scale would not make a lot of financial sense.

Depends. Assuming you're only hashing the password once per session, I doubt bcrypt would make a huge dent in your overall CPU time.

With a work factor of 7, hashing might take around 10ms. Which is not a whole lot, but much, much more secure than MD5 and SHA1.

Re: How To Safely Store A Password

#174

Post by Tichy »

jpeterson wrote: post #149
Tichy wrote: post #117

Earlier quoted context omitted.

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.

No of course not. I mean yes, you misread me.

Re: How To Safely Store A Password

#175

Post by icebraining »

dmd wrote: post #139
icebraining wrote: post #105

Earlier quoted context omitted.

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/

certifi.ca's very own cert is expired. That doesn't make me trust them much.

I don't use them either (since they don't support CNAMEing your own domain to them like MyOpenID), but it was just an example, there are more, and you can even install your own.

Re: How To Safely Store A Password

#176

Post by icebraining »

roel_v wrote: post #118
icebraining wrote: post #106

Earlier quoted context omitted.

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.

Here in Belgium we have the same cards, and the readers are cheap. The reason they will be wide-spread is because you can use them to file your taxes online, which many people are starting to prefer over the paper version. I think it's a good incentive for people to start buying these things. I just hope they will become standard on computers soon, but I fear not because the dominant markets (US, really) don't have s…

Yeah, if they start requiring the cards for delivering the taxes online I think we'll have millions of PCs with readers in a year or two.

Re: How To Safely Store A Password

#177

Post by dpark »

podperson wrote: post #146
roel_v wrote: post #119

Earlier quoted context omitted.

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 s…

This is not a secure system. It is completely broken. The hash simply becomes the password when you do this. All an attacker needs to do is replay the hash and they're in. The "plaintext" is irrelevant, because an attacker doesn't need it.

Also, if you're storing the unsalted hash in your DB, your security is doubly broken. Someone who accesses your DB can more easily brute force the passwords (it looks like you're using a single salt rather than a per-user salt), and your scheme is vulnerable to rainbow attacks as well.

Re: How To Safely Store A Password

#178

Post by mynegation »

cookingrobot wrote: post #59
chops wrote: post #14

Earlier quoted context omitted.

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.

No, you couldn't. Nothing prevents malicious client from "letting itself in", no matter whether password was correct or not.

Re: How To Safely Store A Password

#179

Post by pixeloution »

falcolas wrote: post #163
pixeloution wrote: post #141

Earlier quoted context omitted.

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.

Your comparison is flawed - you're comparing GPU evaluation times for MD5 against CPU evaluation of bcrypt.

There is no such thing as a GPU based bcrypt hasher because it woudln't be - from my understanding - any faster then a CPU based one. Not all calculations are able to be sped up through the use of a GPU.

So I'm comparing the fastest you can do bcrypt hashes (100 a sec at that work factor) vs the fastest you can do MD5 hashes (250 million per second)

Re: How To Safely Store A Password

#180

Post by eneveu »

zobzu wrote: post #170
eneveu wrote: post #110

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 l…

not storing the password in sql has nothing to do with obscurity. In fact, it's smart. You do not understand what "security through obscurity" means. Following your train of though, we should display the salt and the hash publicly. That is extremely dumb. Put your passwords in your post, otherwise you'll be doing security through obscurity! oh snap?

That's not what I said. Some amount of secrecy might better than none. But, you should not depend on it.

If you use a "clever" scheme to store / generate your salt, you make your system more complex in an attempt to hide something that does not really need to be hidden. You might also end up introducing implementation flaws.

That's why bcrypt uses nonces for its salts, and simply appends them to the encrypted passwords.

Also see http://en.wikipedia.org/wiki/Kerckhoffs%27s_Principle

Post reply on HN