Implemented Implement bcrypt and PBKDF2 for password storage

[Kent]

XenForo currently uses sha256, or sha1 if that isn't available. Basically this:

hash('sha256', hash('sha256', $password) . $salt);
sha1(sha1($password) . $salt);

These hashes aren't ideal for password storage because they are fast and can be cracked fast. I think XenForo should add support for bcrypt and PBKDF2.

Most to least preference, depending on availability:
scrypt*, bcrypt, PBKDF2, sha256, sha1

*PHP does not currently have an official scrypt implementation.

 

[digitalpoint]

Doesn't matter what algorithm you are using, your bottleneck is going to be a new HTTP request for every "try". The web server would crap out and you wouldn't have enough network bandwidth to do it very fast anyway. Even if you had a dedicated gigabit connection to the server, you are limited to 3 million network packets per second... which doesn't even mean 3 million tries per second (because you need far more than 1 network packet per try). But let's say you could do 3 million tries per second for sake of argument. Both the web server and DB server would seize up instantly trying to handle 3 million requests/second.

Now let's say a hacker has the actual database somehow. You have much bigger problems than the hacker spending 24 hours to reverse engineer 1 password... after all, they already have your database... do they really even need to log in to the site anymore?

But yeah... either way... 1 HTTP request per attempt (on any hashing algorithm) is more or less going to DDoS the web server and make it not possible to do it that way.

 

[Deebs]

Doesn't matter what algorithm you are using, your bottleneck is going to be a new HTTP request for every "try". The web server would crap out and you wouldn't have enough network bandwidth to do it very fast anyway. Even if you had a dedicated gigabit connection to the server, you are limited to 3 million network packets per second... which doesn't even mean 3 million tries per second (because you need far more than 1 network packet per try). But let's say you could do 3 million tries per second for sake of argument. Both the web server and DB server would seize up instantly trying to handle 3 million requests/second.

Now let's say a hacker has the actual database somehow. You have much bigger problems than the hacker spending 24 hours to reverse engineer 1 password... after all, they already have your database... do they really even need to log in to the site anymore?

But yeah... either way... 1 HTTP request per attempt (on any hashing algorithm) is more or less going to DDoS the web server and make it not possible to do it that way.

Gigabit ethernet can support at most 1,488,096 frames per second at 84 bytes per frame, the minimum. At the other end of the spectrum (assume no jumbo frames support) the maximum becomes 81,274 frames per second at 1538 bytes per frame.

I understand your point about a possibly DDOS but Scrypt, Bcrypt and PBKDF2 are password storage algorithms and not simple hash algorithms and you need to strike a balance in the number of rounds. Even using a less number of round and therefore preventing a DDOS is better as Scrypt and BCrypt are just resistant to running on GPUs and bruteforce. It is about being responsible and if your database is stolen and that 1 password that is stolen and "cracked" makes the news you are in trouble. Look at the recent leaks and the damage it can do. I currently convert all passwords to Bcrypt and will continue to do so until Scrypt is ratified as a standard.

 

[Mike]

Bcrypt is already used for 1.2. People will be converted to it on their next login.

 

[Deebs]

Bcrypt is already used for 1.2. People will be converted to it on their next login.

Mike,

Is the number of rounds configurable?

 

[Mike]

Currently, I don't think so, but I'll probably make some adjustments available before the beta testing. (It's using the stupidly named PHPass library, which is already in 1.1 for phpBB imports.)

 

[Robbo]

Use php_compat... https://github.com/ircmaxell/password_compat

It's designed for forward compatibility, by the guy who got the new password_* functions added to PHP. Any other library is a waste of time, you will just have to change to this one eventually.

 

[Deebs]

Please make it configurable so that we can increase the number of rounds over the course of CPUs getting quicker. I looked at the PHPass library and didn't like what I read about it on the web so went looking and found this: https://gist.github.com/1053158/

It does require the OpenSSL PHP extension. Also, nearer the time can you tell me or provide a sample of how you are storing it in the blob so I can get a converter done for mine to migrate to your implementation.

Thanks.

 

[Deebs]

Use php_compat... https://github.com/ircmaxell/password_compat

It's designed for forward compatibility, by the guy who got the new password_* functions added to PHP. Any other library is a waste of time, you will just have to change to this one eventually.

Just reading up on that actually.

 

[Mike]

I should point out that we still only require PHP 5.2...

 

[Robbo]

Oh my bad, I expected the one I linked to allow for 5.2 as well. Not sure why it doesn't.