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 »

code reader wrote: you could take the "prefix" idea much further. ... with the appropriate delimiter, you could reduce the table to use a single field!

That's why I said "where possible and practical." Your description is possible (and is nearly a definition of a flatfile table), but not practical.
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. ... 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.

This is a good point. If a salt is to be added, then it starts getting in the way to combine so many things into one field (though some applications that rely on a single algorithm do tie the salt and the hash together in the same field in a similar prefix pattern, and IIRC, Unix crypt does the same thing). Once you get beyond two pieces of information, it becomes more hassle to combine things into a single field. Here, you're talking about three items (at a minimum), which would reasonably suggest a need for multiple fields.
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.

Changing on each login is a bit of overkill since you need to define a login. Is it the beginning of a session, or just when a password is actively entered? I think that changing on each password change (which of course is now a configurable item) makes for a stronger system. At the most, I think it should be when the user actively enters the password. Otherwise, larger boards may suffer an unnecessary performance hit when sessions are started and the hashes are calculated for comparison and then recalculated with the new salt and stored. Not every hash is as nice on the CPU as MD5.
moondream wrote: 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

OK, I see what you're saying. I thought you meant that the MD5 implementation was different, when it's essentially a change to the plaintext. In this case, yes, there will be some translation issues, but for those not using special characters, the hashes should be identical.
phoenix-cms wrote: 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.

I see the value of being able to opt for SHA1, and of course the merits of salting have been well-discussed in this thread. However, I'm not clear on the value of using base64 encoding. All that does is provide an obfuscation layer, incurring an additional process that doesn't seem to me to be terribly necessary. It may push a few people down the wrong path, but base64 is fairly recognizable to people with a little experience, and decoding it to get the plaintext is trivial.
You can never go home again... but I guess you can shop there.
phoenix-cms
Registered User
Posts: 34
Joined: Sat Mar 04, 2006 3:40 pm

Re: Password hashing function

Post by phoenix-cms »

well since using my own encoding, and even phpbb3 is easy to pull hash data out i done it many times and even the cvs its been there for about 2 months once its final i start bug reporting but i not registered on main forum so i cant be bothered right now with that.
and my encoding class its practually hack proof, if the dev team would be intrested i be more then happy to let you take a look.

and you can actually have more then one encoding in the forum for starters if your users were using md5 and you wanted to sha1 you dont actaully have to force them to reset there passwords.
use case

like if($encryt == "md5") { some stuff here
} elseif($encryt == "sha1") { other code here
} else {
some default code here like
$user = new phpbb3_encryption();
$user->password('$password');
}

Steve ;)
working on a cms to be intergrated with phpbb 3 without any major code changing to keep with phpbb 3 guidelines
code reader
Registered User
Posts: 653
Joined: Wed Sep 21, 2005 3:01 pm

Re: Password hashing function

Post by code reader »

Martin Blank wrote: Changing on each login is a bit of overkill since you need to define a login. Is it the beginning of a session, or just when a password is actively entered? I think that changing on each password change (which of course is now a configurable item) makes for a stronger system. At the most, I think it should be when the user actively enters the password. Otherwise, larger boards may suffer an unnecessary performance hit when sessions are started and the hashes are calculated for comparison and then recalculated with the new salt and stored. Not every hash is as nice on the CPU as MD5.

i just want to relate to this one point.
i was talking about changing the salt every time the password is entered (i don't even see how it can be changed otherwise).
as to cpu load:
currently, every login requires both reading a row from the users table, and writing it back, to update the lastvisit and maybe some other stuff.
relative to two db queries, computing the hash twice instead of once if absolutely negligible in term of server resources consumed. this point is completely meaningless, regardless of the algorithm used.
if the web server and the db server reside on different boxes, it actually means even more resources consumed for each query, as anyone familiar with the way tcp/ip stack opertates could attest.
either way, i do not believe that having to compute the hash twice has any significance whatsoever in terms of server resources.
just my 2c.
Martin Blank
Registered User
Posts: 687
Joined: Sun May 11, 2003 11:17 am

Re: Password hashing function

Post by Martin Blank »

phoenix-cms wrote: and you can actually have more then one encoding in the forum for starters if your users were using md5 and you wanted to sha1 you dont actaully have to force them to reset there passwords.

I'm not questioning the use of multiple hashing algorithms. In fact, I entirely support it, and that's what the prefix/extra field idea that code reader and I have discussed is about. There is no universal change required for the users if that happens.

What I was questioning is the use of base64 encoding. Where are you using the encoding? You have the cleartext, the salt, the encoding, and the hash, not necessarily in that order, and the order is what I was attempting to clear up. I can see where salting the password and then encoding it could provide some further protection against dictionary attacks (short passwords + salt may not be long enough to get past some brute-force attacks). I just want to be sure that's what you're doing.

I'm also not convinced right off the top whether this improves or hurts security, but since I've not seen it before, it doesn't seem to be widely used, and so may not help significantly enough to be worth it.
code reader wrote: i was talking about changing the salt every time the password is entered (i don't even see how it can be changed otherwise).

That's what I was wondering. Thank you for clearing that up. We are in agreement on that point. Unless the users are prevented from using saved logins, this should not be an issue.
You can never go home again... but I guess you can shop there.
phoenix-cms
Registered User
Posts: 34
Joined: Sat Mar 04, 2006 3:40 pm

Re: Password hashing function

Post by phoenix-cms »

the base64 part is not used for the password itself but for encoding the saltkey
hope that helps

Steve ;)
working on a cms to be intergrated with phpbb 3 without any major code changing to keep with phpbb 3 guidelines
Martin Blank
Registered User
Posts: 687
Joined: Sun May 11, 2003 11:17 am

Re: Password hashing function

Post by Martin Blank »

Let me see if I have this correct. You take a password, create a salt, base64-encode the salt, then combine them to pass to the hash? Example of password of 'password' and salt of 'abc123':

sha1('password' + base64('abc123')) = sha1('passwordYWJjMTIz') = d5902f399c21411825e9e9f59830316b224f36a0

Why encode just the salt? When you do that, you limit the character set for part of the hash to only 64 characters, as opposed to a wider possible range of at least 93 characters (quick count of visible characters on my keyboard, plus space) or more for the salt. The length of the salt is increased, but I suspect the cumulative entropy drops somewhat, probably below what is possible for an expanded character set. This isn't a particular concern considering the lengths involved and the difficulty of getting past the salt anyway, but it still seems to me to be an unnecessary step.
You can never go home again... but I guess you can shop there.
Lieutenant Clone
Registered User
Posts: 161
Joined: Tue Feb 28, 2006 6:13 pm

Re: Password hashing function

Post by Lieutenant Clone »

I belive what he meant was to use the salt unencoded, then encode the salt for database storage as so wandering eyes would not accedentally see it. This works ofcourse because you can reverse a base64 encoding ( base64_decode() ).
Dennis Robinson
Image
comperr
Posts: 1
Joined: Sun Jun 25, 2006 6:00 pm

Re: Password hashing function

Post by comperr »

personally, from a sec standpoint I prefer a modified hash rather then a programmed hash (create your own MD5/SHA-x sub and modify it a little bit.) That way it makes it harder for crackers (not hackers) to brute force it at all....That way you don't have to care what ersion of PHP you are using. Also I use they should use function_exist type things to offer "php 3/4/5 only" type things.
Post Reply