[RFC] More secure hashing

[MartinTruckenbrodt]

Hello naim,
if users are using the same weak password for serveral boards or other acoounts, too. Also there databases with MD5 password hashes. So you just have to compare the stolen data with these databases.

Salted passwords area a nice idea on the first look. But IMO it's not possible in real life to make the password salty enough. Users and/or administratos will be annoyed by it! (My job is IT administrator in a 200 clients company. ) So IMO this feature is not really a good security feature. I think a time limit te renew the password after a configured time period with password history would be a better and much more usefull security feature.

@ the "we" community:
Why not to upgrade the encryption algorythm?
If there is not any important reason not to upgrade then you should upgrade it. At least it would be a good thing for the image of phpBB to be on the top in this point.

UPDATE 23-03-2012: Somethings added!

Bye Martin

[/a3]

Salted passwords area a nice idea on the first look. But IMO it's not possible in real life to make the password salty enough. Users and/or administratos will be annoyed by it! (My job is IT administrator in a 200 clients company. ) So IMO this feature is not really a good security feature.

Salting a password completely changes the hash. Also, I don't understand how it would annoy users, since it doesn't change anything on the user-facing end.

@ the "we" community:
Why not to upgrade the encryption algorythm?

Main reason would be backwards compatibility.


I don't really do much coding work with phpBB so not sure if this is helpful at all, but perhaps looking at what the Drupal developers did with Drupal 7 might help. They ended up using SHA512 with salt.

[MartinTruckenbrodt]

Hello /a3,
backward compatibilty?
IMO there is only one thing needed: For boards upgraded from Ascraeus (or Olympus) MD5 still should be implemented for the migrated user accounts and forum passwords.

Salting passwords changes first the password and then second the hash.
It's easier to forget a salted password.

Bye Martin

[/a3]

Salting passwords changes first the password and then second the hash.
It's easier to forget a salted password.

The password is salted after the user enters it in, every time. It's designed to prevent attacks by rainbow tables. You don't have to remember the salted password since it's done by phpBB each time.

[MartinTruckenbrodt]

Hello /a3,
does salted passwords mean "Password complexity:" ?

Bye Martin

[/a3]

Hello /a3,
does salted passwords mean "Password complexity:" ?

Bye Martin

No, it's where the user chooses their password, the password is "salted" (modified) and then hashed. It does two things:

1. Prevents rainbow table attacks and dictionary attacks, since it the MD5 doesn't represent the password but instead a salt of the password. Also, administrators can change the salt, as far as I know.
2. Makes producing dictionaries slightly more processor-intensive. This makes creating rainbow tables more difficult. Also, I believe a rainbow table must be created for every new salt.

I'm not really an expert on cryptography at all, most of this was just taken off Wikipedia and a few other websites.

Salt (cryptography) - Wikipedia
Rainbow table - Wikipedia

[callumacrae]

Hello /a3,
does salted passwords mean "Password complexity:" ?

Bye Martin

No, it's where the user chooses their password, the password is "salted" (modified) and then hashed. It does two things:

1. Prevents rainbow table attacks and dictionary attacks, since it the MD5 doesn't represent the password but instead a salt of the password. Also, administrators can change the salt, as far as I know.
2. Makes producing dictionaries slightly more processor-intensive. This makes creating rainbow tables more difficult. Also, I believe a rainbow table must be created for every new salt.

I'm not really an expert on cryptography at all, most of this was just taken off Wikipedia and a few other websites.

Salt (cryptography) - Wikipedia
Rainbow table - Wikipedia

That's correct. Also, if you have a different salt for every user then they have to be rainbow tabled one at a time.

[MartinTruckenbrodt]

Hello,
okay. So it seems that I have been completely off-topic.

As I understand what you mean I think this salting thing has not the effiency which you want to get. This salting thing really would need to have random mechanism. At least a random passphrase for the board is needed created by the initial setup. A random passphrase for every user IMO is not a good way.

BTW: What is state of the art for Olympus?

Bye Martin

[callumacrae]

Hello,
okay. So it seems that I have been completely off-topic.

As I understand what you mean I think this salting thing has not the effiency which you want to get. This salting thing really would need to have random mechanism. At least a random passphrase for the board is needed created by the initial setup. A random passphrase for every user IMO is not a good way.

BTW: What is state of the art for Olympus?

Bye Martin

A random salt for every user is the generally accepted way, and the way recommended by every security expert. Why don't you think it is a good idea?

Anyway, I'm against this entire RFC, as there have been no problems so far and it would create backwards compatibility issues.

[MartinTruckenbrodt]

...A random salt for every user is the generally accepted way, and the way recommended by every security expert. Why don't you think it is a good idea?...

Hello Callum,
you know every security expert's opinion? Great!

For me the salty thing is an alternative for increasing the hash algorhythm. I think it's easier to get backward compatibility with a higher hash algorhythm.

Based on my job's experience I always prefer simplyfied server side solutions.

Bye Martin