Increasing Password Hash security

[pavemen]

not many people use SSL because they either

1) need to buy a certificate (many complain about a $5 plugin, now you want them to buy a $150 cert?)
2) use a self-signed certificate and have your users prompted about invalid certificates at every login.
3) use a shared hosting certificated from the server, but then you need alter core files and templates and not a lot of servers have a properly signed cert, they often use self-signed as well

[ekerazha]

Adding a second salt would make bruteforcing more difficult, but both salts would still be stored in the database, so both salts would be available to the hacker

That's not a big issue, the main purpose of a salt is to defeat the use of rainbow tables. Just use a long password (at least 8 chars?) with a salt and a good and slow hashing algorithm (slow algorithm = slow brute force) and you're done.

However, here I suggested to use phpass: http://community.mybb.com/thread-121163.html

P.S.

Did I already say that the current hashing method is ugly?

md5(md5($password).$salt);

1) md5 is cryptographically broken
2) double md5 hashing is useless: it reduces the $password uniqueness (theoretically you can have hash collisions, so you could have 2 different passwords with the same hash) and it only makes sense to slow down a brute force attack (because you have to compute 2 hashes) but md5 is pretty fast on modern hardware.

[seeker]

<off-topc continued...>

not many people use SSL because they either

1) need to buy a certificate (many complain about a $5 plugin, now you want them to buy a $150 cert?)
2) use a self-signed certificate and have your users prompted about invalid certificates at every login.
3) use a shared hosting certificated from the server, but then you need alter core files and templates and not a lot of servers have a properly signed cert, they often use self-signed as well

Hi pavemen,
#2 and #3 == Agreed
#1 Free SSL certs accepted by all major browsers, and they do actually work well.*

*Obviously a "bank" would invest in a "big-name" cert, but these work fine for forum logins.

[TacticalCode]

...How about bcrypt?

Blowfish is an easy solution to prevent brute-forcing, as the password can be hashed, for example, 4096 times.
The current password storage technique includes 3 hashings (plaintext pass, salt, passhash+salthash).
brute-forcing a bcrypted hash (cost 12) would take more than 1000 times longer.

I really hope bcrypt will be implemented in the future, as fast as possible.
For now, I'm working on my own solution, "MyBBcrypt".
https://github.com/TacticalCode/MyBBcrypt

I'm using a mod in /inc/functions_user.php to use bcrypt for salting, so in the DB, there's the plain salt and a bcrypt hash made from the password's md5 and the salt.

(On a side-note: I use the password's md5 because the salting function accepts this. But it could also be used to hash the pass before transferring it to the server. This would at least not show the password in plaintext to network sniffers. So they can't try the password on other sites.)

Any info when more secure hashes will be part of MyBB?
PS: I know, it also takes more time for the server to hash all passwords, but these are milliseconds (depending on the hardware).

[Nathan Malcolm]

Any info when more secure hashes will be part of MyBB?

Not until the 2.0 series at least.

[Euan T]

So you're first of all md5ing the password then bcrypt hashing both it and the salt. That's kind of pointless IMO. Plus you're still storing the salt in the DB which still isn't a good idea.

[TacticalCode]

Yes, it isn't a good idea, but at least it's not bad.
The salt is also stored in the DB in current versions, that's because a cracker can't do anything with the hash + salt except brute-forcing.
As bcrypt hashes many times, brute-forcing is nearly pointless.
Wordlists may be faster, but with bcrypt, it's still a lot more secure than a salted md5.

I'm hashing the md5's because of compatibility. I first thought of the mod as plain solution for new installs, so they're good to go with the new hashing. Existing DBs should also have been supported through a plugin which prompts the users to change their password.

But now I've thought of a very much easier solution:
hashing the normal hash with one private key. (bcrypt(md5(md5($pass).md5($salt))).)
This way, every existing DB can be converted to the new bcrypt hashes, without users having to change (or re-type) their passwords. Also, the Database-structure doesn't have to me modified.
But I haven't figured out the best solution to store the salt. The best solution would be to store it in functions_user.php itself, then admins would have to generate their own keys. But as long, as an attacker doesn't have access to the server's files, the salt is secure. Plus, this would have a higher performance than always doing an additional file operation or DB-Request.

Storing the salt in the Database would be the simplest solution, yet quite insecure, as once someone has DB-Access, they can also gather the salt.

once generating a file for the salt seems to be the best approach, since admins don't have to mess with their files, but it's rather secure. The only negative side-effect is performance: for every login or password change, the salt-file would have to be accessed.

What do you think?

[Euan T]

I still think that mixing md5 and bcrypt is a really bad idea. If you're making core file edits, you may as well go all the way. Don't store your salts at all either. Maybe it would be a good idea to look at this http://michaelwright.me/php-password-storage

[TacticalCode]

The goal is to provide better security for as many people as possible. It doesn't matter if you crypt an 8 character password or a 16 character long hash-string.
I would also prefer just use bcrypt - but in a forum with 10k users, it would just take ages for everyone to switch to a new bcrypt hash.
For upgrading and migrating, just crypting the current hash seems to be the best option. Why is this bad?
Yes, it's not so beautyful and pure in from a technical point of view. But it isn't in any way weaker than just hashing the plain password with bcrypt.

BTW: The MyBB Docs page seem to be messed up... http://docs.mybb.com/Database_Tables.html (click any table, returns github 404 to me on Win7/Firefox + Ubuntu12.04/Chromium)

[Euan T]

The way I would do it is just use pure bcrypt for future registrations and each time existing users login, hijack the login before the password is encrypted so you can do it with bcrypt, store it then check it against the original md5 (if that makes sense?).

Regarding the docs, there are a lot of incorrect links. I've been meaning to sort that particular page for a while now, I'll do it this afternoon.