[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
bantu
3.0 Release Manager
3.0 Release Manager
Posts: 557
Joined: Thu Sep 07, 2006 11:22 am
Location: Karlsruhe, Germany
Contact:

Re: [RFC] Update password hashing algorithm

Post by bantu »

MartinTruckenbrodt wrote:Hello bantu,
no, this doesn't increase security.
How? Source for this statement?

It clearly does. When there is a SQL injection I get all the salts and all the user password hashes.

Your proposal:
1 salt
u user hashes

I take my dictionary with w words and hash all the words with the hash function and the one salt.

Complexity for hashing all words: 1 * w
Then I compare the results with all u user hashes.

Per-password-hashes:
u salts
u user hashes

Again, I take my dictionary with w words and hash all the words with the hash function, but have to do this for every salt.

Complexity for hashing all words: u * w
Then I compare the results with all u user hashes.

Also, the salt changes when the password changes.
MartinTruckenbrodt wrote:I think it's more secure to have one salt in CONFIG_TABLE and all passwords in USERS_TABLE insteat of saving all salts and all passwords together in one table USERS_TABLE.
Yeah, you can think that if you want. Again, please read up on Password Hashing and Salting. Buy a good crypto book or something.
MartinTruckenbrodt wrote:Still I don't believe that there are rainbow tables with hashes for random strings. Please show me a source for this statement.
Use your favorite search engine and search for "rainbow table".

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

Re: [RFC] Update password hashing algorithm

Post by brunoais »

Anyway, the best option is a boardwide salt and a user salt.
I actually don't know how better it is against a user salt nevertheless it is better. And we could save that salt in a harder-to-find place like the config.php. It's not full proof but it's harder to reach because the attacker would need to attack the DB and the file system in order to get that salt.

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 »

brunoais wrote:Anyway, the best option is a boardwide salt and a user salt.
I actually don't know how better it is against a user salt nevertheless it is better. And we could save that salt in a harder-to-find place like the config.php. It's not full proof but it's harder to reach because the attacker would need to attack the DB and the file system in order to get that salt.
Yeah, this.
Made by developers, for developers!
My blog

User avatar
Marc
Development Team Leader
Development Team Leader
Posts: 185
Joined: Thu Sep 09, 2010 11:36 am
Location: Munich, Germany

Re: [RFC] More secure hashing

Post by Marc »

A PR for this has been submitted: https://github.com/phpbb/phpbb3/pull/1716

softelp
Registered User
Posts: 3
Joined: Mon Oct 21, 2013 12:13 am

Re: [RFC] More secure hashing

Post by softelp »

+1 for scrypt or bcrypt
+1 per hash (user) salt
-1 for per board hash (explained below)
-1 for PBKDF2
-50 for any use of H(key.salt) or similar homebrew functions.

Per hash* salt is the way to go

*similar to per user but every time a hash is created a new salt is generated.

Password Hashing is meant to slow down cracking attempts 1000 iterations of MD5 is exponentially better than 1 iteration of SHA-512.
Preimage/Second-Preimage resistance is not relevant, not is the primitives speed just adjust the number of iterations to taste.

I voted against per board hashing for portability, if a board admin changes the board wide salt everyone must reset their password. I feel it will cause more problems than it could potentially solve.

May I suggest the cost is board configurable, even better would be to store the function, cost(s) and result in the database; allowing security to be increased while users can transparently update their hash on next login.

Post Reply