[RFC] More secure hashing

These requests for comments/change have lead to an implemented feature that has been successfully merged into the 3.1/Ascraeus branch. Everything listed in this forum will be available in phpBB 3.1.
Post Reply
User avatar
callumacrae
Former Team Member
Posts: 1046
Joined: Tue Apr 27, 2010 9:37 am
Location: England
Contact:

Re: [RFC] Update encryption standards

Post by callumacrae »

brunoais wrote: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.
This is one of those cases where we *don't* want it to be fast. Trickier to rainbow table!
Made by developers, for developers!
My blog

User avatar
brunoais
Registered User
Posts: 964
Joined: Fri Dec 18, 2009 3:55 pm

Re: [RFC] Update encryption standards

Post by brunoais »

callumacrae wrote:
brunoais wrote: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.
This is one of those cases where we *don't* want it to be fast. Trickier to rainbow table!
Actually, we do want it to be fast and we do want it to be secure. So we can take a very secure option.
SHA-1 is quite safe but SHA-256 seems to be the best (with salt, ofc).
SHA-256 is about 300x faster than RSA (the safest cypher algorithm at the moment), one of the reasons is that RSA needs padding to be correctly secure, without padding it is less safe than md5.
I say no to encryption and yes to hash.
I say no to md5, ok to SHA-1 and yes to SHA-256.

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: [RFC] Update encryption standards

Post by Oleg »

visionviper wrote:
bantu wrote: 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?
Yes, and as far as I know this is the state of the art as far as storing passwords is concerned.

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: [RFC] Update encryption standards

Post by Oleg »

The most productive thing in this topic would probably be looking at phpass and seeing what algorithms it supports that are better than the one we presently use, and how much effort it would be for us to use them.

Please read at least http://www.openwall.com/phpass/ and possibly the drupal discussions linked to from there.

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: [RFC] Update password hashing algorithm

Post by Oleg »

I edited the topic title as the old one was very wrong.

User avatar
callumacrae
Former Team Member
Posts: 1046
Joined: Tue Apr 27, 2010 9:37 am
Location: England
Contact:

Re: [RFC] Update password hashing algorithm

Post by callumacrae »

What about updates? The new function will have to have a way o knowing whether it is the old or new password, and then check against the respective method and update the password if it is the old one.

This code will have to stay in phpBB forever, unless the board deactivates their account or something for 4.0.
Made by developers, for developers!
My blog

User avatar
brunoais
Registered User
Posts: 964
Joined: Fri Dec 18, 2009 3:55 pm

Re: [RFC] Update password hashing algorithm

Post by brunoais »

callumacrae wrote:What about updates? The new function will have to have a way o knowing whether it is the old or new password, and then check against the respective method and update the password if it is the old one.

This code will have to stay in phpBB forever, unless the board deactivates their account or something for 4.0.
Not really. We can use both password cores simultaneously.
We just need to update to the new hash when the user logs in.

I already did this in a previous project when I was updating from md5 to sha-1. It worked like this:

During updating sequence:
Update the table to accommodate the bigger hash.
Delete all sessions (logout everyone).

During a login:
Load the (hashed) password from the DB.
Check the hash size. If it corresponds to the size of a md5 hash, execute the input password as an md5 hash, else execute as a sha-1 hash.
If it executed as a md5 hash, update the table with the sha-1 hash.

6 months later:
This transitional feature is removed. If someone wanted to get the account back, he/she will need to use the password recovery system.

This worked for that specific program. Do you see any faults in it?

In a conversation with Oleg, this was brought up and produced this response:

Code: Select all

[10:12] <aw-> we already handle this better
[10:12] <aw-> the way you handle that is
[10:12] <aw-> 1. expand tables
[10:12] <aw-> 2. implement new hashes
[10:12] <aw-> 3. make sure you can still authenticate against old hashes (i.e. don't remove the old code)
[10:13] <aw-> you need to embed what kind of hash it is into the hash for this to work
[10:13] <aw-> e.g. if you look at our hashes they begin with $X$ or similar
[10:13] <aw-> X tells you what type of hash it is
[10:13] <aw-> 4. when a user successfully logs in, you know their password
[10:13] <aw-> this is when you check if the hash is using the old hashing algorithm
[10:14] <aw-> if it is, you rehash the password using the new algorithm and write it to the db
[10:14] <aw-> i believe this is how we went from simple md5 in phpbb2 to the current salted md5 in phpbb3
[10:14] <aw-> and this discussion should not be private
[10:14] <aw-> please post the log in the topic when we're done

User avatar
callumacrae
Former Team Member
Posts: 1046
Joined: Tue Apr 27, 2010 9:37 am
Location: England
Contact:

Re: [RFC] Update password hashing algorithm

Post by callumacrae »

That's almost exactly what I said. You can't lock people out if they happen to be inactive for six months after the upgrade.
Made by developers, for developers!
My blog

User avatar
brunoais
Registered User
Posts: 964
Joined: Fri Dec 18, 2009 3:55 pm

Re: [RFC] Update password hashing algorithm

Post by brunoais »

callumacrae wrote:That's almost exactly what I said. You can't lock people out if they happen to be inactive for six months after the upgrade.
Note: My idea does not lock out ppl 6 months after the update. It just requires ppl to request a new password using the password recovery. after that time.

User avatar
naim
Registered User
Posts: 50
Joined: Thu Oct 13, 2011 7:21 pm
Location: Isolation
Contact:

Re: [RFC] Update password hashing algorithm

Post by naim »

Not all boards support password recovery.

Whats the point to upgrade phpBB hashing tables, it's good enough for now.
Why would anyone want to break into a phpBB forum DATABASE for passwords?

Post Reply