Replace SHA password hashes with bcrypt

[poswald]

I just ran across your project and it looks quite interesting. One recommendation I have is to swap out the password hashing algorithm to bcrypt. It should be trivial using a similar technique as what was done with the library you currently use. For example: This application monkey-patches the auth system the same way.

The reason a general-purpose algorithm like SHA is not the optimal choice for passwords is because it is designed to be fast and easy to compute. Since hashing is only run once in normal operation but run many millions of times in a break attempt, it is preferable to be slow. BCrypt allows you to specify the amount of time the encryption should take via the number of rounds it goes through. This also means it can be made more complex over time as computers get faster. A bcrypt cost of 12 might take only 1 second to encrypt but it is many thousands of times slower than computing SHA hashes. This means a compromised table of hashed password will take thousands of times longer for a dictionary attack.

SHA-256 or 512 or whatever is better than the default but if you're going to recommend something, you should choose bcrypt.

http://pypi.python.org/pypi/py-bcrypt/

[clouserw]

We talked about key stretching like this a few weeks ago - it's a good idea.

[erikrose]

scrypt is also worth a look, as it's a lot more expensive to implement in hardware.

[fwenzel]

Has either of them be peer reviewed as indeed solving the problem in question? Otherwise, it might be sufficient to just re-hash the hash as Wikipedia's article on the issue, with a sane default amount of loops.

[poswald]

If you are asking if the underlying crypto has been peer reviewed then yes. Both bcrypt and scrypt are considered secure for this use by the cryptography community and SHA2 is considered inappropriate for this use. py-bcrypt is a python wrapper on the OpenBSD hashing algorithm. I believe scrypt is a newer algorithm from Colin Percival who is a cryptographer who knows his craft. He presented it at a BSD conference in 2009. Re-hashing SHA2 is an option, but that is effectively what something like bcrypt is doing anyway.

http://www.tarsnap.com/scrypt.html http://pypi.python.org/pypi/scrypt/0.1.0

As for the django application that is simply passing the code along into the python libraries, you can look at those pretty quickly once one is chosen and make sure it is sane as it is only a few lines of code.

I suggested bcrypt because it had a django application already implemented but scrypt is also a perfectly acceptable (perhaps preferable) option.

[fwenzel]

Thanks for the explanation, that was indeed what I was looking for. I pinged our infrastructure security team to ask if they have any preference on what to use here. I'll also go ahead and read the code for the project mentioned here. Thanks!

[fwenzel]

Sorry for keeping piling onto this, but another concern I have is that the other libraries are both C libraries that need to be compiled separately, thus we cannot ship them with playdoh's vendor library. Instead, admins need to install the package for playdoh to work, which on web clusters is potentially a pain. Just something to keep in mind.

[davedash]

We already give enough "must compile" requirements that this shouldn't be a huge problem. MySQL, Jinja are almost required for all our apps. Is it a lot more overhead to add another lib?

[fwenzel]

Here's the bug about it on Mozilla's tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=639692

[fwenzel]

Done: https://github.com/mozilla/playdoh/commit/3dce04d

Please read the readme on github.com/fwenzel/django-sha2 for more information.