Password hashing function

Discussion of general topics related to the new version and its place in the world. Don't discuss new features, report bugs, ask for support, et cetera. Don't use this to spam for other boards or attack those boards!
Forum rules
Discussion of general topics related to the new release and its place in the world. Don't discuss new features, report bugs, ask for support, et cetera. Don't use this to spam for other boards or attack those boards!
Post Reply
Martin Blank
Registered User
Posts: 687
Joined: Sun May 11, 2003 11:17 am

Re: Password hashing function

Post by Martin Blank »

moondream wrote: The current hashing scheme could be considered as an aid for the administrator not to read the passwords by accident when he browses through the db. Plain md5 is no longer secure against collision and wordlist attacks.

MD5 has never been secure against wordlist attacks if the wordlist encompasses the password. Passwords which are long enough are computationally infeasible to break with simple brute-force attacks. The collision issue is still mitigated for now in that the end-product is a 1024-bit (128-byte) result that is not applicable to phpBB, since it limits the password length to less than that (32 characters, IIRC). Whether this remains the case is yet to be seen, but given how quickly it crumbled, I don't like the idea of 'wait and see.'

SHA1 looks to be headed down a related path, too, but adding in other options starts to get more complex since other major algorithms only started appearing with the hash() function around 5.1.2.
(NOTE: even phpBB2 is not completely compatible to the Olympus md5 hash)

What changed in how the hash is handled between v2 and v3? The MD5 hash algorithm is well-defined, and both use, IIRC, the PHP implementation to handle it.
You can never go home again... but I guess you can shop there.

agent00shoe

Re: Password hashing function

Post by agent00shoe »

Worrying about password "security" in phpbb seems like a waste of time. If an admin wants your password, they can grab it when you log in before it gets hashed. If you're worried about brute-forcing the login form, there are many ways to set limits to the number of failed logins and ban IPs etc.

code reader
Registered User
Posts: 653
Joined: Wed Sep 21, 2005 3:01 pm

Re: Password hashing function

Post by code reader »

admin stealing password is not the main concern.
let me try to explain what i view as martin'w conern:
1) someone get a read-only access to the db. most probably by obtaining a copy of a backup file.
2) by employing a "collision" attack they find, not necessarilly a user's password, but rather another password that produces the same hash. due to a certain vulnerability of md5, this is significantly easier than it's supposed to be.
3) they use this contrived password not only on the compromised board, but they try it in other places where same user has an account. since many users use the same password in more than one place, it makes the user him/herself somewhat exposed.

it turns out that using a salt will make the main concern in (3) go away, because the attacker will not be able to use the same contrived password elsewherre.

my point was somewhat different, though:
adding an "algorithm" column to the users' table, not only makes a future conversion to any other algorithm easy and smooth, without any inconvinience to the users, but it will also make converting from other bb system, presumably using a different hash algorithm just as smooth. this was why i woke up this 5 months old thread.

Lieutenant Clone
Registered User
Posts: 161
Joined: Tue Feb 28, 2006 6:13 pm

Re: Password hashing function

Post by Lieutenant Clone »

I completly understand and agree with you code reader. This is the method I am using in the CMS I am building.
Dennis Robinson
Image

APTX
Registered User
Posts: 680
Joined: Thu Apr 24, 2003 12:07 pm

Re: Password hashing function

Post by APTX »

I can't believe this thread is still alive...
Don't give me my freedom out of pity!

Martin Blank
Registered User
Posts: 687
Joined: Sun May 11, 2003 11:17 am

Re: Password hashing function

Post by Martin Blank »

code reader wrote: adding an "algorithm" column to the users' table, not only makes a future conversion to any other algorithm easy and smooth, without any inconvinience to the users, but it will also make converting from other bb system, presumably using a different hash algorithm just as smooth. this was why i woke up this 5 months old thread.

I see your point, though I'd rather use a prefix in the password field (lack of prefix means MD5, with other hashing algorithms specified in some standardized way). I try to avoid using a separate field where possible and practical. Either way is just as valid, though, and simply a matter of developer preferences.
You can never go home again... but I guess you can shop there.

code reader
Registered User
Posts: 653
Joined: Wed Sep 21, 2005 3:01 pm

Re: Password hashing function

Post by code reader »

you could take the "prefix" idea much further.
say, in the users table, use the user name as a prefix, then the registration date, then number of posts, etc.
with the appropriate delimiter, you could reduce the table to use a single field!

i dont know enough to seriously discuss the pros and cons of appending multiple pieces of data to use a single field with database use, but generally, in all the applications i'm familiar with, this is generally not done.
when the developer wants a new piece of information, they usually create a new column in the database, rather than appending it to an existing column as a prefix (or suffix). currently the users table contain some 70-odd columns, some of them for pretty obscure pieces of data.

having a dedicated column also means you wouldn't need a special treatment for md5 ("no prefix means md5"). you would just initialize the new alg column to "md5" for the existing users when this new column will be added.

i think it is simpler, and more in sync with the way things are done in phpbb in general to define a new column when a new piece of information is required.
adding one more column, for password hash salt, would round it nicely. now, each algorithm would be free to use or not use the salt in any way it wishes.

if/when changing salt is used, changing it with each login would also somewhat increase the security, because this way, obtaining an old backup copy will only mean something for users who did not log in since the backup was made.

(i refer to obtaining an old copy of the database, because ttbomk, this is the only way someone can have a "read-only" access to the database. any other way i know of someone can read the database, they can just as easily write to it. as many people noted, once someone can write into your db, md5 hash collision is not your main security concern any more)

moreover, by using a changing salt, you create a situation where using a collision value immediately breaks the original password, which may alert the admins that a break-in had happened.
using a salt which is regenrated every login does not cost any additional db queries, because the users table is updated for each login anyway (updating user_lastvisit, and maybe some other fields).

APTX
Registered User
Posts: 680
Joined: Thu Apr 24, 2003 12:07 pm

Re: Password hashing function

Post by APTX »

code reader wrote: you could take the "prefix" idea much further.
say, in the users table, use the user name as a prefix, then the registration date, then number of posts, etc.
with the appropriate delimiter, you could reduce the table to use a single field!

I agree You should do it like this.
Don't give me my freedom out of pity!

moondream
Registered User
Posts: 33
Joined: Tue Aug 19, 2003 1:27 pm

Re: Password hashing function

Post by moondream »

Martin Blank wrote:
(NOTE: even phpBB2 is not completely compatible to the Olympus md5 hash)

What changed in how the hash is handled between v2 and v3? The MD5 hash algorithm is well-defined, and both use, IIRC, the PHP implementation to handle it.


Some special characters are hashed as html entities in current Olympus if they didn't change that without me knowledge (I read the cvs diffs). the "&" character is hashed as "&" so any password with "&" in it will be incompatible

phoenix-cms
Registered User
Posts: 34
Joined: Sat Mar 04, 2006 3:40 pm

Re: Password hashing function

Post by phoenix-cms »

i use my own encryption on phpbb2 which is basailly md5 / sha1 pending on php version installed. then use of base64 and salt so the stored hash is never the same.
and i know for a fact it would never break upgrades. and more secure in my terms becuase if someone discoved a cookie issue and gained your hash key it would be useless becuase the next time you try and login the hash would of changed.

thats my 2 cents

Steve ;)
working on a cms to be intergrated with phpbb 3 without any major code changing to keep with phpbb 3 guidelines

Post Reply