Hacker News Reader

Comment by IgorPartola | Hacker News Reader

I have been thinking about switching everything to bcrypt, but there is definitely way too much confusion about bcrypt vs scrypt, how many rounds to set for bcrypt, etc. What is the definitive source for figuring out what the new standard should be? Does anyone have any links to something that's peer-reviewed and approved for use by someone with enough authority to do so?

View on HN

No there isn't. You only think that because when geeks discuss anything that involves one or more knobs, a huge debate must necessarily ensue about the proper values of those knobs.

Just use the bcrypt defaults. You will be fine. You will in particular be so much better off than salted SHA-1 that this topic will be mooted. Later on, maybe in 5-10 years, you can re-engage with the debate about what a good cost factor for bcrypt will be in 2020.

In the defense of geeks, this probably follows from the mantra that you should never ever run any command on your system ever without completely and fully understanding what it does and all of its options and etc. etc.

So now people are twitchy about "just use the defaults", especially when it comes to something they don't really understand, like cryptography.

As a geek let me just say that it is all love with me and the geeks. Just: in this case, you can just take the defaults and be better off.

OK. By the way, in case you haven't heard it lately, thanks for hanging around and demystifying this stuff for so many people. It's a huge help.

as is your comment.

What's a ready to go bcrypt library for C/C++? I mean include headers, link lib / so, and call a function.

I've been looking into this over the past few days, and I've decided to just extract the relevant files from py-bcrypt, and get rid of the compatibility layer.

The C reference implementation is here:

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/

Its from OpenBSD and implemented by the developers of the algorithm. It is what the Python/Ruby/Lisp/PHP etc. versions are derived from or wrap

Thanks!

Thanks. I am just trying to navigate the sea of misinformation that spews forth everywhere about salted hashes vs bcrypt vs scrypt. I can see that lots of people claim that bcrypt is better, but I am not aware of anything about it other than the original paper. Basically, I want to know what the chances are that two months after I implement bcrypt a huge issue with it will be discovered and I'll have to move everything to some new scheme.

There is virtually no chance that, after selecting bcrypt, you will be forced to scramble to replace it in 2 months.

There is no chance that, after selecting bcrypt, you will be forced to scramble to replace it with salted SHA-1 hashes. bcrypt is strictly better than what you're doing now.

Fantastic. One more question: does increasing the work factor automagically upgrade existing passwords in some way? As in, will bcrypt passwords created today be strong enough in 2020?

The Ruby on Rails auth system I use, Devise [1], will automatically update a user's password to use your new work factor on their next login.

You could do something similar.

[1] https://github.com/plataformatec/devise

No; you'd upgrade them incrementally.

getsat and tptacek have already answered your question, so I won't rehash that (pun wholly intended), but I should point out that one interesting property of PBKDF2 is that you can increment the work factor (number of iterations).

PBKDF2(password, iterations=10) == PBKDF2(PBKDF2(password, iterations=5), iterations=5)

Thus you could, say, increase the number of iterations every month. All that said, you should still use bcrypt; this is just an interesting property IMO.

That does introduce a security concern though. While it might be hard in practise, if you have a copy of a hashed password iterated 200 times, then a copy of the same hashed password iterated 300 times and have cracked the 200 iteration hash, you could verify the other hash is the same by applying 100 iterations to the hash. To solve this you would want to change the salt whenever you change the password, which involves doing all the iterations again. Then you are no better off then using a non-incrementing solution like bcrypt. The only situation where you wouldn't be able to make a new salt, however, is if the user hasn't logged in for a while (which is quite possible for single-use accounts on websites).

I got into a debate on StackOverflow over bcrypt vs salted SHA1:

http://stackoverflow.com/questions/3722780/do-any-security-e...

I think I'm right in choosing bcrypt, but one interesting argument against it was that, being slower, it would facilitate DoS attacks. You want the password hashing to be slow to prevent brute-forcing, but, if it's too slow, attackers could supposedly DoS your login system by trying tons of passwords.

I'm not a security expert, and I didn't know what to respond to that. How would one mitigate this problem? Is it even really a problem?

Just like you don't want over 60 requests per second from a client, you don't want them to be able to allow that much log in attempts. Look at Gmail failed login process. A captcha is required after 3 failed attempts is preferable to a "you can't login after this many attempts" that I remember getting on a forum.

One of the fundamental ideas of cryptology is using the right algorithm for the type of data and the length of its required security. If the cost required to break an algorithm is greater than the value of of the encrypted data, you're probably safe.

You can always store the password of the users again and update the crypto used, (more iterations, different digest algorithm). It's never a question of if it will be broken, but when.

Choosing iterations for a PBKDF takes a bit of common sense, yes if you're going to roflscale and think 100000000 iterations is a good idea currently, then you may run into performance issues.

The correct balance is performance vs security and you can only choose one. You want to authenticate the user as fast as possible while also making it unfeasible to recover the data. As with everything, a little common sense and knowledge goes a long way.

scrypt slides: http://www.tarsnap.com/scrypt/scrypt-slides.pdf

Takeaway: Cost to crack one MD5 password: $1. Cost to crack one scrypt password: $50M to $200B.

You want your login to be slow compared to the rest of your application. It's okay to take half a second to verify a login.

scrypt is better than bcrypt, but not by the same margin that bcrypt is better than salted hashes. Salted hashes are a straight-up vulnerability. bcrypt is a best practice.

Note that almost nobody uses scrypt. We don't recommend it, not because it's insecure, but because it's painful to implement for most companies.

But use either. Or just use PBKDF2. All of the adaptive hashes are fine.

    > All of the adaptive hashes are fine.

I am so glad you say this.

I can't count the arguments I've heard centered around what is The One True Way to store passwords... this topic turns every programmer on the planet into an instant Crypto Expert (TM).

STFU and use one. Hell, glib's crypt() lets you pick any of three computationally expensive schemes, so use one of those.

> Salted hashes are a straight-up vulnerability.

I find this a bit of a misnomer. I understand what you mean in context, of course, but, strictly speaking, bcrypt is a "hash", and "salted" is always good.

What was your goal with this comment?

Clarification. Right now we have

> Salted hashes are a straight-up vulnerability. -- tptacek

"Salted or unsalted versions of common hash functions (MD5, SHA-1, SHA-2, SHA-3) are not to be used to store passwords."

Reply on news.ycombinator.com