[RFC] More secure hashing

[MichaelC]

I think SHA-1 is completely supported in 4.3 and higher. I do see what you mean about 5.3 though since SHA-2 should be fully available for use.

Sure, changing the hashing to use something else would be trivial. However, since we need to keep compatibility with existing hashes, it's not as trivial as you may think. As soon as we add a wide range of possible algorithms, things can get quite messy.

Wasn't this done in 2.0 to 3.0, but the user had to login or else the hash would not be updated?

[brunoais]

Once we require PHP 5.3 (honestly I don't mind doing this for 3.1, PHP 5.2 just does not make sense at this point), we can use blowfish.

honestly, I agree. Still, believe it or not, there's a significant amount of server running php5.2.
I say: Keep phpbb's version 3.1 php5.2 compatible. Next subversion make it only compatible with php5.3.*.

[bantu]

Also see viewtopic.php?f=108&t=33231

Once we require PHP 5.3 (honestly I don't mind doing this for 3.1, PHP 5.2 just does not make sense at this point), we can use blowfish.

honestly, I agree. Still, believe it or not, there's a significant amount of server running php5.2.
I say: Keep phpbb's version 3.1 php5.2 compatible. Next subversion make it only compatible with php5.3.*.

Please keep this discussion in the relevant topic.

Once we require PHP 5.3 [...], we can use blowfish.

Please do not confuse people even more. Blowfish is a symmetric block cipher used for encryption (a processes that is supposed to be reversible). Passwords are not encrypted, they are hashed (a process that is supposed to be irreversible). What you're referring to is called bcrypt, a cryptographic hash function for passwords that relies on blowfish. The fact that PHP calls a hash function crypt() and the relevant constant CRYPT_BLOWFISH does not help either.

It's time to get phpBB off of using md5 and using stronger encryption standards. What I am proposing is this: When phpBB is installed (or upgraded) it takes a look to see if mcrypt is installed and what encryption is supported. It will then pick the best available (such as AES or Twofish) and uses that.

Passwords are not supposed to be encrypted, they are supposed to be hashed. By using encryption instead of hashing you are weakening the system because the plaintexts can be recovered given the key. And you have to store the key somewhere.

I would love to personally work on this and see it included. I've been working on a mod that updates the encryption for phpBB (and I'm confident it will finally pass validation). I think security is very important and I want to help make phpBB more secure.

I am sorry, but storing an encrypted version of a plaintext along with the decryption key is as dumb as storing the plaintext itself. If this is the case for your mod, I will personally make sure it will not pass validation anytime.

I'd like to see where... phpBB tossed out md5 encryption since we moved from 2.0 to 3.0. Now, like Oleg said, we use phpass.

MD5 is the underlying cryptographic hash function used by our modified version of phpass, so md5 is used. It is just not "plain md5".

I'm sorry, but I am going to side with US-CERT over a web developer on webdev. US-CERT says it's broken so in my eyes, it's broken - no matter how you use it.

Surely, using a proper hash function is better, your approach of using encryption instead of hashing certainly is not. I'm not convinced md5 being broken as a cryptographic hash function is a practical issue for this use case right now. I should probably research that a little.

I know cracked password isn't as bad as someone getting your credit/debit card details, but there is a reason credit card/ssn/etc information is required to be encrypted, not just hashed and salted with md5 or sha.

You seem to be confusing a few thing here. The difference between credit card numbers and passwords is that there is no need to store passwords, they can be stored in a hashed version that do not allow obtaining the plaintext. Credit card numbers have to be used as plaintexts however, so all you can do is encrypt.

If we are going to change hashing algorithm, we should sneak some unusual characters into the data being hashed for the benefit of rainbow tables. Something from the 1-32 control char range and 128-255 which is not valid utf-8.

This is not a problem and should not be done as the salt takes care of rainbow tables.

[brunoais]

I'm sorry, but I am going to side with US-CERT over a web developer on webdev. US-CERT says it's broken so in my eyes, it's broken - no matter how you use it.

Surely, using a proper hash function is better, your approach of using encryption instead of hashing certainly is not. I'm not convinced md5 being broken as a cryptographic hash function is a practical issue for this use case right now. I should probably research that a little.

MD5 is not broken. Not even near that. The problem is that MD5 uses a 128 bit key, which is a small key for nowaday's computers and its hashing result has too many clashes (string is too small).
That is the reason why MD5 is not longer secure enough. We need to move on to a better one with less clashes just like SHA-256 (or better). With passwords like this calculations estimate that it takes about 10^9 years to find the original string with brute force and by picking up the strings that create the same hash.

[Oleg]

Agreed with everything bantu said (except for the rainbow tables part which I will take on faith, and I still think if we add stuff to plaintext we might as well add characters outside of the usual ranges - surely it cannot be a bad move).

There is a lot of terminology misuse, and possibly misunderstanding resulting out of it, in this topic.

For example:

MD5 is not broken. Not even near that.

Depending on your definition of "broken", it is. Cryptographers certainly consider it sufficiently broken.

For our purposes however, I think the current password hashing system is acceptable. Yes, we can make it better, but there are other things that we can do that will add a lot more value.

[igorw]

For the record: Yes, I was referring to bcrypt.

[visionviper]

It's time to get phpBB off of using md5 and using stronger encryption standards. What I am proposing is this: When phpBB is installed (or upgraded) it takes a look to see if mcrypt is installed and what encryption is supported. It will then pick the best available (such as AES or Twofish) and uses that.

Passwords are not supposed to be encrypted, they are supposed to be hashed. By using encryption instead of hashing you are weakening the system because the plaintexts can be recovered given the key. And you have to store the key somewhere.

I would love to personally work on this and see it included. I've been working on a mod that updates the encryption for phpBB (and I'm confident it will finally pass validation). I think security is very important and I want to help make phpBB more secure.

I am sorry, but storing an encrypted version of a plaintext along with the decryption key is as dumb as storing the plaintext itself. If this is the case for your mod, I will personally make sure it will not pass validation anytime.

If you use a method similar to the latest revision of my mod there is no universal encryption key stored, or any key anywhere. It's generated on the fly using salting, hashing and encoding to create a string that the final encryption key ends of being a substring of. This means that there is no concern of a person obtaining a key and decrypting all the passwords. Each password would have to individually be cracked and the time to do it has now been extended by the addition of a encryption layer.

[bantu]

If you use a method similar to the latest revision of my mod there is no universal encryption key stored, or any key anywhere. It's generated on the fly using salting, hashing and encoding to create a string that the final encryption key ends of being a substring of. This means that there is no concern of a person obtaining a key and decrypting all the passwords. Each password would have to individually be cracked and the time to do it has now been extended by the addition of a encryption layer.

Encryption schemes usually do not guarantee that bad things do not happen when you choose the encryption key "similar" to the plaintext you are encrypting, which is what you are kind of doing (albeit with a hash function in between). Encryption schemes usually require to pick the encryption key uniformly at random.

Also, this does not seem to be a standardized or well-established password hashing scheme, so I would certainly suggest using bcrypt (which is already provided by phpass, given PHP 5.3) over the approach you proposed.

[visionviper]

Also, this does not seem to be a standardized or well-established password hashing scheme, so I would certainly suggest using bcrypt (which is already provided by phpass, given PHP 5.3) over the approach you proposed.

Doesn't phpass work simply by salting, hashing and looping?

[brunoais]

FYI, hashing is about 200x faster than crypting.
Also:
If you hash, you don't need a key, you just need a salt (if you want to prevent the use of "rainbow tables"), even though the salt is not obligatory.
The sha-256 is about 50x slower than sha-1 and sha-1 is about 10x slower than md5.
I made some study (including asking a pro in the subject) md5 has a huge problem, instead of having a safety of 2^1024 operations for brute force, it has a safety of 2^256 operations for brute force. This means that, to break something in the md5 hash, you need to try (in the worse case) ~= 1,15792e77. That a lot but too little. According to the expert, that's the problem with md5 that was only discovered recently.

The way to reduce from 2^1024 to 2^256 happens if you use a really complicated math formula.

Anyway, hashing is very fast as passwords will be very well saved in the DB if they are saved using sha-1 and a salt.