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 »

NeoThermic wrote: I also have to note, I've been unable to find any links to proof of attacks on input data which is less than 1024 bits. The user of a phpBB system is actually limited to a password of 32 characters, so we are a good deal short on the 1024 bits that seems to be required at minimum for the attacks.
A year ago, it required a small supercomputer to find collisions in a reasonable time. Today, it can be done on a relatively common CPU. You point out that the collision IV is 1024 bits now. In order for it to work with phpBB's password length limitation, it has to decrease to 256 bits.

You're defending an algorithm that is collapsing under fire from all sides.
As was noted as well, there's not much you'll be able to go to either. SHA1 needs 4.3.x (not withstanding the fact that SHA1 has nearly the same problems as MD5), while SHA256/512 are not generally avable in PHP.
SHA256 is available via the Message package in PEAR. Even aside from that, there's this code that provides SHA256 under LGPL.

Claiming that one shouldn't use a function because it's not generally available in PHP is a really weak argument. How many functions were re-written for phpBB 2.0.x to take into account that some were not available until certain later versions of PHP?
As a final note, as is pointed out in this topic a few times, if you, as an outside attacker, can obtain MD5 hashes, then you've already got enough access to do more than that (such as change passwords, etc).
You're still thinking narrowly, putting the attacker in one place. What about traffic sniffing? Multiple users on one computer? Gaining access to the hash is the first step, and there are various means of doing so. That's sometimes a weakness that can't be addressed by a server, because the server isn't a part of the entire chain. Securing that part which we can, within reason, is the sign of a responsible community. We can't put SSL in place on every box, or distribute one-time pads to every user, but we can improve the hashing algorithm to move beyond the not only weakened but clearly doomed MD5 algorithm.
If you're using the same passwords over many diffrent login systems, that isn't the fault of any software, just you.
So we shouldn't take reasonable precautions to protect the users? How difficult would it really be to move to something else? I don't subscribe to the school of thought that says that if a person uses the same password in more than one location, they get what they deserve. Protections should still be put into place.
You can never go home again... but I guess you can shop there.

User avatar
DavidMJ
Registered User
Posts: 932
Joined: Thu Jun 16, 2005 1:14 am
Location: Great Neck, NY

Re: Password hashing function

Post by DavidMJ »

SHA256 is available via the Message package in PEAR.
Even aside from that, there's this code that provides SHA256 under LGPL.
That first link at PEAR has ZERO code that computates hashes, it calls on mhash. That last link does compute a hash.. Except that it is.. sub optimal in terms of speed... It makes calls to assert and PCRE functions... I am also 100% sure that he some of the bitwise used is not optimized... He did funky things to get around the lack of a proper circular shift, kills speed...

They did not rewrite all function in 2.0.x, realpath was tossed away. SHA256 in PHP is awful for CPU and memory. Large boards with thousands of users online would bottleneck.

Did you just copy those links straight off of wikipedia?
Freedom from fear

User avatar
smithy_dll
Registered User
Posts: 461
Joined: Tue Jan 08, 2002 6:27 am
Location: Australia
Contact:

Re: Password hashing function

Post by smithy_dll »

If their traffic sniffing or have access to the users computer (implying access to e-mail or other stuff), they already have the unhashed password, and no amount of hashing is ever going to secure that.

To secure that base you really have to use SSL and delete your e-mail that has passwords, or secure it using simillar methods.

I don't think you really understand the concepts at play here, and are just pointing to the "Bigger is better" argument without understanding why.

SSL secures the transfer of data from the browser to the server. The password in phpBB (like in FTP) is transfered to the server in plain text. SSL is the only acceptable way to secure that point.

There is no-where in the phpBB code in 3.0 or 2.0.18 and upwards where the password hash is transfered over any networking protocol (unless mySQL, but then thats internal networking presumably, and presumed safe, if not then there are other issues such as the transfer of the mySQL password).
Image
phpBB, its open source, become involved, write a modification!
Modifications Database | MOD Development Forum Rules | MOD Studio

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

Re: Password hashing function

Post by Martin Blank »

They did not rewrite all function in 2.0.x, realpath was tossed away.
Where did I say that all of the functionality was rewritten? Nowhere. Never did I say that. I said that there were functions rewritten for use when some core PHP functionality was unavailable, and was needed for something in phpBB.
SHA256 in PHP is awful for CPU and memory. Large boards with thousands of users online would bottleneck.
How often are hashes even calculated? Answer: Not that often, because most people are using auto-login. I doubt it would slow a board significantly, let alone bring one to its knees.

As for extra resource usage for different hashes, get used to it, because as MD5 breaks further -- and it almost certainly will -- it's going to become a bigger liability.
Did you just copy those links straight off of wikipedia?
I found the LGPL one through a Google search (sha256 php LGPL), and I knew of the PEAR entry because when the weaknesses first started to become apparent a year ago, I went looking for other things. I wasn't arguing that those were the only solutions, just that saying that something isn't included in core PHP is a weak argument for not considering switching.

Hardened PHP has introduced it; it's only a matter of time before the main implementation includes it, which would be much better from a resources perspective, but even if someone does it in PHP, it would be better than relying on MD5 for the next few years.

I don't know why it is that bringing this up gets people so defensive, other than that some may perceive it as an attack on phpBB's security. I'm trying to avoid being defensive myself and stick to logical arguments. Is it a concern right now, right this second, that has to be changed in 2.0.19? No, it's not, nor did I ever say that. What I said, and I will repeat it for those that may have missed it, is that MD5 is a dying, crumbling algorithm that should be considered for replacement in the very near future.
You can never go home again... but I guess you can shop there.

User avatar
DavidMJ
Registered User
Posts: 932
Joined: Thu Jun 16, 2005 1:14 am
Location: Great Neck, NY

Re: Password hashing function

Post by DavidMJ »

http://cvs.sourceforge.net/viewcvs.py/p ... 64&r2=1.65" target="_blank
Know what this tells me? PHP 4.3.3 is needed to run phpBB 3.0.x. sha1 was introduced in 4.3.0. If the devs want to break compat with 2.0.x, they can switch the hash. Otherwise, its pretty moot.
Freedom from fear

User avatar
Acyd Burn
Posts: 1838
Joined: Tue Oct 08, 2002 5:18 pm
Location: Behind You
Contact:

Re: Password hashing function

Post by Acyd Burn »

Guys, please stay on arguments. :) For 2.0.x there will be no change, point. But for Olympus i do not know at the moment. We might think about it of course, but not only the implementation has to be thought of, the upgrade process too. And additionally - if md5 gets replaced - we want to be sure that we do not need to change it again for some time, meaning a strong, future save (as far as can be evaluated today) replacement. This discussion should be helpful at least.

So, i like this discussion, but why not discuss the following aspects in more depth:
- which hashing function would be the best solution
- how to achive this in respect of performance (especially if a wrapper function is needed)
- how this would affect upgrades
- Olympus requires at least php 4.3.3 - use it. :)

Image

markus_petrux
Registered User
Posts: 376
Joined: Fri Jun 18, 2004 10:58 pm
Location: Girona, Catalunya (Spain)
Contact:

Re: Password hashing function

Post by markus_petrux »

hmm...

Imagine there is a list of function names stored somewhere (maybe a simple array of function names). Each function would implement a possible hash algorithm (based on builtin or user supplied functions). phpBB would call any of those functions through a wrapper function, maybe something like phpbb_hash($password). Such a wrapper could then call the appropriate hash function depending on several factors.

Board administrators could choose the hash method in the ACP (or at installation time) and the proper function identifer would be stored in the config table. The function identifier would also be stored in the users table, every time the password is updated, so phpBB know which method was used to hash the password for each user. At migration to phpBB3 time, the default value for all existing users would be 'md5', which may not match the one selected by the administrator. However, that insignificant issue could be solved as follows:

At login time, phpBB would use the hash method specified in the users table. If for whatever reason, that method was not the current selected method at board level, and the user supplied password was correct, phpBB would have to re-hash the password (at login time phpBB would have the unencrypted one, just supplied by the user itself) and update the user record with the new hashed password and the correct identifier of the hash method. So the next time the user logs in, its own hash method matches the one selected by the board administrator.

...each board administrator could balance performance/security issues with capabilities of his particular installation. Or people could easily write MODs to use more, new, better, different hash methods.

:?

uranusalien
Registered User
Posts: 32
Joined: Mon Oct 27, 2003 4:48 pm
Contact:

Re: Password hashing function

Post by uranusalien »

Changing the hashing function wouldn't actually require users to change their password. Autologin users might have to re-login, yes, but it's a simple matter of prefixing the hash with an identifier (like said above), i.e. '$MD5$' . md5($pw).

When the user logs in, simply confirm the entered password matches the legacy hash, then reencode with the preferred hash based on the password the user entered, add the appropriate prefix (e.g. '$SHA256$') and save it into the database. It's all transparent.

Also, has anyone looked at Whirlpool and Tiger hashes? Pretty hard to find detailed info on them since they haven't attracted much attention.

User avatar
DavidMJ
Registered User
Posts: 932
Joined: Thu Jun 16, 2005 1:14 am
Location: Great Neck, NY

Re: Password hashing function

Post by DavidMJ »

uranusalien wrote: Changing the hashing function wouldn't actually require users to change their password. Autologin users might have to re-login, yes, but it's a simple matter of prefixing the hash with an identifier (like said above), i.e. '$MD5$' . md5($pw).

When the user logs in, simply confirm the entered password matches the legacy hash, then reencode with the preferred hash based on the password the user entered, add the appropriate prefix (e.g. '$SHA256$') and save it into the database. It's all transparent.

Also, has anyone looked at Whirlpool and Tiger hashes? Pretty hard to find detailed info on them since they haven't attracted much attention.
I like this idea a lot. The only problem is the initial prefixing. Large boards would need to do a lot of reindexing. A far more efficent, single pass system would not look for $MD5$ but for a hash length of 16. If the hash is 16 characters long, its MD5, if its 20, its SHA1. SHA256 is of a different length. So is Whirlpool. Tiger is of length 48.

As long as the hash you want to change to is of a different length, this system works fine.
Freedom from fear

User avatar
DavidMJ
Registered User
Posts: 932
Joined: Thu Jun 16, 2005 1:14 am
Location: Great Neck, NY

Re: Password hashing function

Post by DavidMJ »

Acyd Burn wrote: - which hashing function would be the best solution
- how to achive this in respect of performance (especially if a wrapper function is needed)
Tiger, the SHA family and MD5 all depend on zero filling. A bit wise operation known as circular shift. In C variants and even Javascript, you simply use

Code: Select all

<<<
or

Code: Select all

>>>
(It depends on the hash function)
PHP does not include a mechanism to do this. Instead, a function must be coded to replace this functionality. In a weak algorithm like MD5, this is done over 60 times. SHA256 uses a right rotate many times.
Freedom from fear

Post Reply