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

91–100 of 110 posts

Re: How To Safely Store A Password

#91

Post by aschobel »

tptacek wrote: post #66
peterwwillis wrote: post #64

Earlier quoted context omitted.

Folk wisdom of PHP developers? I think the creators of crypt() are probably smarter than this. Password hashes are part of a way to mitigate a particular situation: deciphering a login credential when the password database has been exposed. Shadow files are locked down to root-only because you should never trust people with your password hashes. If somebody has the hash, it's just a matter of time. I don't assume tim…

If you controlled the passwords your users chose, you might be in a position to talk about "strong passwords" combining with "salted hashes" to make a reasonable solution. Here's a bcrypt hash. Crack it, and I'll donate $200 to the charity of your choice. It's not random, and the cost factor on the hash is not high. $2a$14$Dk9dLUH6khBEU3tIHGkNX.6rm6kccRwDUq.bopQ68INbDumal3BiG

a cost factor of 14 isn't that high?

that's just mean

Re: How To Safely Store A Password

#92

Post by oozcitak »

rimantas wrote: post #83
oozcitak wrote: post #82

How? Basically, it’s slow as hell. Is that it? bcrypt is good only because it is slow? In that case, why don't we use whatever we like (MD5, SHA1, SHA256, SHA512, SHA-3, etc) and add a sleep(500); just before the call? It is guaranteed to keep up with Moore's law as well!

Did you read the article? The problem is that someone trying to bruteforce your MD5 hash won't add that sleep(500). Bcrypt is slow by design.

I thought the attack was against the application. The article talks about the security of the raw data in the database. I missed that on my first read. Sorry for that.

Re: How To Safely Store A Password

#94

Post by moe »

bmj wrote: post #59
steveplace wrote: post #36

Earlier quoted context omitted.

https://twitter.com/signup Start typing in the pw box, if it's not strong enough, they'll let you know. Also, try "123456" or "password"

Ah, but "1password" is good.

Rule of thumb: If you're going to look for a good implementation of X (anything) then scratch twitter.com from your list before you start.

Re: How To Safely Store A Password

#95

Post by khafra »

jmillikin wrote: post #26
necubi wrote: post #11

Earlier quoted context omitted.

The article is talking about the problem of storing passwords in a database in order to authenticate logins. This is for people writing web-apps, not users looking to secure their own passwords.

The passwords aren't being stored, though; a value derived from them is. In a properly designed system, it is computationally infeasible for an attacker to obtain the original password given the derived value.

> In a properly designed system

Proper design of such a system is the subject of the post. If you're a developer who doesn't want to think about the design of such systems, that's fantastic! Just use bcrypt.

Re: How To Safely Store A Password

#96

Post by geocar »

TallGuyShort wrote: post #10
tptacek wrote: post #3

But wait. What if I use a 64 bit salt and then AES-encrypt the password with a key I store half on my server and half in a cookie I send to the user and then they'd have to break AES to get my passwords? How about that , Coda Hale?

http://xkcd.com/538/

http://www.schneier.com/blog/archives/2008/10/rubber_hose_cr...

Re: How To Safely Store A Password

#97

Post by assemble »

codahale wrote: post #72
peterwwillis wrote: post #64

Earlier quoted context omitted.

Folk wisdom of PHP developers? I think the creators of crypt() are probably smarter than this. Password hashes are part of a way to mitigate a particular situation: deciphering a login credential when the password database has been exposed. Shadow files are locked down to root-only because you should never trust people with your password hashes. If somebody has the hash, it's just a matter of time. I don't assume tim…

You're asking about the relative merit of two hash functions, one of which allows your attacker to test a candidate password in 1 millisecond , the other of which allows the same in less than 1 nanosecond . Using the latter provides your attacker with a 1,000,000x productivity boost. Personally, I'm not that generous. As far as CPU exhaustion, there are some huge sites which use bcrypt (like, in the top 10)[1]. It is…

Where did you get a list of how the top 15 sites on the internet hash/bcrypt/whatever their passwords? That sounds like some interesting information.

Re: How To Safely Store A Password

#99

Post by tptacek »

boundlessdreamz wrote: post #74
tptacek wrote: post #71

Earlier quoted context omitted.

No. Bcrypted passwords have nonces in them, just like "salted" hashes. You don't have to think about it. You just use bcrypt.

Complete noob. Can you explain this more. if you bcrypt(12345) isn't the result always same ? If the hash varies then what does the inbuilt nonce depend on ?

   >> BCrypt::Password.create("hi,mom", :cost => 10)
   => "$2a$10$L/c.1uoZSh3oaU1fLrnYK.yyU4PiJXsIAzN22qnbU41liyLn5/of  2"
   >> BCrypt::Password.create("hi,mom", :cost => 10)
   => "$2a$10$3F0BVk5t8/aoS.3ddaB3l.fxg5qvafQ9NybxcpXLzMeAt.nVWn.NO"
   >> BCrypt::Password.create("hi,mom", :cost => 10)
   => "$2a$10$VEVmGHy4F4XQMJ3eOZJAUeb.MedU0W10pTPCuf53eHdKJPiSE8sMK"
Despite the pages and pages and pages and pages of conversation about how to select and format "salts", adding random nonces to hashes is not one of the world's great CS problems.

Re: How To Safely Store A Password

#100

Post by jrockway »

codahale wrote: post #18
jrockway wrote: post #16

Earlier quoted context omitted.

Only experts should be allowed to innovate in the security domain. Passwords on lolcats are serious business! We certainly don't want people in the software engineering industry to come up with new ideas, implement them, and see how they work in real life. That could lead to advancement in the field, and that would be bad, because I might have to learn something new. Shudder.

I'm curious to know why you think innovation in the security domain will come from web developers working on lolcat apps and not, say, cryptographers.

I'm curious to know why you think cryptographers don't write lolcat apps.
Post reply on HN