Live data from Hacker News

How To Safely Store A Password

codahale.com

1–10 of 215 posts

Re: How To Safely Store A Password

#4
post #2

and/or stop using a single word and use sentences (phrase) eight characters is easy - try cracking 50

> and/or stop using a single word and use sentences (phrase)

True.

This isn't meant for the user, though. This is meant for the developers. No matter how hard the developers try, users will always pick bad passwords. If you use salted SHA-1, then if the database gets compromised there goes 50% of the passwords. If, on the other hand, you use bcrypt, maybe only 5% of the passwords get cracked.

Bcrypt turns a massive news event (database leaked; thousands of passwords lost!) in to something much less newsworthy (database leaked; twenty passwords lost).

Re: How To Safely Store A Password

#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?

Re: How To Safely Store A Password

#6
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?

I believe that the work factor is encoded with the hash, so bcrypt can identify which work factor to use.

Re: How To Safely Store A Password

#7
post #2

and/or stop using a single word and use sentences (phrase) eight characters is easy - try cracking 50

Not too difficult if it's composed of dictionary words. Why not automatically generate random strings to use? No pattern at all.

with cuda and the cloud it's quicker to try all possible passwords (starting with aaaaaaa...) than to search a rainbow table of dictionary words so ":Hy6&z@z" is now no more secure than "password"

Re: How To Safely Store A Password

#8
post #6
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?

I believe that the work factor is encoded with the hash, so bcrypt can identify which work factor to use.

Thanks for your answer. At first I though it didn't make sense because the hash should be one-way and bcrypt should not decrypt the hash or mess around with it other than comparing it with what the user entered but I have searched a bit more and found this post on stackoverflow that explains in detail : http://stackoverflow.com/questions/4443476/optimal-bcrypt-wo...

Your answer was right, it stores the work factor, the salt and the hash so that at any given time you can change the work factor and it will adjust in the database!

Re: How To Safely Store A Password

#9
post #2

and/or stop using a single word and use sentences (phrase) eight characters is easy - try cracking 50

Not too difficult if it's composed of dictionary words. Why not automatically generate random strings to use? No pattern at all.

Assuming 5 words selected from a dictionary of 234979, there are 716382975036689591261090899 possibilities. If you have 1000 computers each cracking 10 billion attempts per second, you're looking at about 1135817 years. I'm going to call that difficult.

Re: How To Safely Store A Password

#10
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?

The easy way is to support the previous work factors and increase it next time the user logs in (since you'll have the password in plaintext in memory). Either way, bcrypt with a paltry work factor of 7 or 8 is orders of magnitude slower than md5 and sha. Jack that up to 12 or 13 and you're pretty much good to go for years, the only problem is the near 1-second processing time on semi-current hardware.
Post reply on HN