Password hashing function

[code reader]

forgive me if i am wrong, i do not want to begin a flame-war or anything, but i think that obssessing about the specific algorithm used in hashing password is missdirected.
i dont intend to imply that security is unimportant, what i really mean to say is that the specific hashing algorithm has only marginal effect on security, even if it is somewhat weak.

let me describe my understanding of the possible attack martin implies:
in order to use the "collision" atack, the atacker is assumed to have gain access to the database, and have retrieved the hashed pw.
at this point they run this sophisticated algorithm, and find a "collision", ie, a different password that will hash to the same value. after this point, they can log-in as this specific member, and, say, read their PM's, post while pretending to be the other person, or edit this person's posts.

well, lets look at the actual threat.
the key point is, for any of these attacks to happen, the attacker has to gain access to the database. the hashing algorithm weakness is no help here. it only becomes meaningful after the attacker obtained the hashed pw.

but think about it: in phpbb, there is no reason for a database account with "read only" privileges to exist, and it is very rare that such an account exists.
hence, once you assume the attacket has read access to the database (let's say by using some form of sql injection) you must assume they also have write access.

so, any and all of the evil deeds they can perform, they can do without "cracking" the pw: the can simply replace the password with a new one, and then do whatever they want, and even, if they wish to "cover their tracks", they can put the original pw back in place.
they can make themselves admins.
they can read and modify PM's. (without even logging in: just read it from the db!)
they can post. they can edit posts. they can remove posts. (again, completely unrelated to passwords)


to summarize:
the possible "collision" attack martin describes, at least as well as i understand it, requires the attacker to gain access to the DB before the attack.
at this point, all the defenses, including the strength of the hash algorithm, are completely pointless.

any security enhanecement in this area should be geared at preventing this initial database access (sql injection or other), rather than trying to make the password more "robust" after the database has already been compromised.

it is more than possible that i missed something in my understanding of the suggested type of attack. if so, please set me right.

[Martin Blank]

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).

I strongly recommend that you have a look at your cookies, and the data contained therein. In particular, look for phpbb22_data, where you will find the MD5 hash of your password. Therefore, the password hash is transferred over a networking protocol (specifically, TCP), and is visible to someone watching the traffic.

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.

Thank you for stepping in here. Judging by the follow-up responses, security concerns often aren't taken seriously until a dev steps in and says that they're worthy of concern.

the specific hashing algorithm has only marginal effect on security, even if it is somewhat weak.

Just because it's a lower-level problem than something like a SQL injection doesn't mean that it isn't important.

let me describe my understanding of the possible attack martin implies:
in order to use the "collision" atack, the atacker is assumed to have gain access to the database, and have retrieved the hashed pw.

There is a flaw in your understanding: I have posited that they gain access to the hash, which need not be through database access. That's only one route. It can also be done via traffic sniffing, too, particularly on infrastructures such as cablemodem networks, but perhaps also via wireless connectivity.

at this point they run this sophisticated algorithm, and find a "collision", ie, a different password that will hash to the same value.
after this point, they can log-in as this specific member, and, say, read their PM's, post while pretending to be the other person, or edit this person's posts.

They only need the hash for that, with no need to run the collision finder (which in its current form doesn't work for phpBB, as phpBB passwords are limited to a length of 256 bits (32 bytes * 8 bits/byte), whereas the returned value from md5coll is 1024 bits. They would not, for example, be able -- yet -- to get ACP access because they could not supply a password that would be short enough, although now that I think about it, that presumes that the code is checking for the length of the password sent via HTTP, while a moderately skilled attacker could create the appropriate traffic to send the 128-character collision. Not sure about that.

any security enhanecement in this area should be geared at preventing this initial database access (sql injection or other), rather than trying to make the password more "robust" after the database has already been compromised.it is more than possible that i missed something in my understanding of the suggested type of attack. if so, please set me right.

While this is quite important as well (and certainly considering that it has been SQL injection attacks that have caused the bad press for phpBB in the past year), properly securing the passwords is also important. A previous poster seemed to imply that if someone uses the same password for multiple sites and is harmed because of it, it's their own fault. This is true to an extent, but I am arguing that phpBB should not be a vector for discovering a cryptographically identical password that then puts these users at risk insofar as we are capable within the limited scope we have to work with. Some may scoff at less-educated users, but those less-educated users make up a huge portion of the userbase, including a number of administrators. One of the strengths of phpBB is its access to the masses. That is also, in some ways, one of its major weaknesses, and it is a responsible community that looks after those who are less well-educated.

[code reader]

...
I strongly recommend that you have a look at your cookies, and the data contained therein. In particular, look for phpbb22_data, where you will find the MD5 hash of your password. Therefore, the password hash is transferred over a networking protocol (specifically, TCP), and is visible to someone watching the traffic.

i did look at my cookies, and a) i didnt find a cookie of that name, and b) i didnt find any other cookie that seemed to contain my pw hash.
i also tried to read the code (as the name implies) and couldnt find any place where the password hash is either transmitted, or assigned to a cookie value.
it is entirely possible i missed something, but it is also possible that you refer to an older version of the code.
i agree that transmitting the pw hash is less than secure, and if this is really the case, i think the right course of action is to not do it, rather than looking at enforcing the hash algorithm.
ttbomk, the only thing that actually goes over communication lines is the password itself, not the hash.

[Graham]

I think you might wish to take a look at the cookie contents yourself

One of the changes we made in 2.0.18 was to the session system to backport the code in use here (and have subsequently merged some changes we made there back in here as well). If you look at the cookie, not only will you not see the hash of your password, you won't even see an md5 hash at all.

However to correct a assumption you make above - yes performance is important, since there is a hash performed even in the case of autologins, so claiming that it is infrequent is incorrect.

[NeoThermic]

Judging by the follow-up responses, security concerns often aren't taken seriously until a dev steps in and says that they're worthy of concern.

Secuirty concerns are taken seriously. If you think otherwise, then please look around you. Look at things like the secuirty tracker, the code audit, and keep your eyes open for the future.

let me describe my understanding of the possible attack martin implies:
in order to use the "collision" atack, the atacker is assumed to have gain access to the database, and have retrieved the hashed pw.

There is a flaw in your understanding: I have posited that they gain access to the hash, which need not be through database access. That's only one route. It can also be done via traffic sniffing, too, particularly on infrastructures such as cablemodem networks, but perhaps also via wireless connectivity.

Seeing as your understanding is the flawed one, can you provide an answer to the original (quoted) question? Not withstanding that if you could do traffic sniffing, you might as well obtain the cleartext password anyway..

although now that I think about it, that presumes that the code is checking for the length of the password sent via HTTP, while a moderately skilled attacker could create the appropriate traffic to send the 128-character collision. Not sure about that.

The code checks that the password supplied is 32 or less characters. I dobut there's a way around that. (If so, you know where the secuirty tracker is)

While this is quite important as well (and certainly considering that it has been SQL injection attacks that have caused the bad press for phpBB in the past year)

Incorrect, phpBB hasn't had SQL injection for a while. What has caused bad press is the santy worm's remote code execution, of which a patch was out two months before the santy worm first appeared.

NeoThermic

[APTX]

Salt anyone?

[Martin Blank]

I think you might wish to take a look at the cookie contents yourself

One of the changes we made in 2.0.18 was to the session system to backport the code in use here (and have subsequently merged some changes we made there back in here as well). If you look at the cookie, not only will you not see the hash of your password, you won't even see an md5 hash at all.

The cookie that remained for me must have been a remnant from before. Logging out, removing the cookies, then logging back in did show me the new cookie structure. This does reduce this attack signature significantly, since it removes most, if not all, of the risk of sniffing. I stand corrected on this aspect.

Secuirty concerns are taken seriously. If you think otherwise, then please look around you. Look at things like the secuirty tracker, the code audit, and keep your eyes open for the future.

I am keeping my eyes open, Neo. I welcomed all of those things. I was not specifically referring to you when I said that, although I still think that your viewpoint that the use of MD5 is not any real concern is incorrect.

Seeing as your understanding is the flawed one, can you provide an answer to the original (quoted) question? Not withstanding that if you could do traffic sniffing, you might as well obtain the cleartext password anyway..

Insofar as I had not been aware of the changes removing the hash from the autologin, yes, my understanding was flawed. I have specifically said that there are security aspects which cannot be handled by phpBB because we don't have complete control over the entire chain of events, unless something drastic were to be done such as requiring SSL for the login page, which is above and beyond what should be done at this level.

Incorrect, phpBB hasn't had SQL injection for a while. What has caused bad press is the santy worm's remote code execution, of which a patch was out two months before the santy worm first appeared.

phpBB has no known SQL injection attacks. They may well be out there and known by some, but simply not publicized.

And to perhaps make a clarification for those who wonder, my job is network security. In this line of work, we cannot afford to make certain presumptions, and are always looking to improve things before we're forced to do so. The security audit was a great example of this, but we also have to be concerned about other aspects, and always look for multiple ways in which a vulnerability could be taken advantage of. Most people here are still worried about what can be done to the individual forum for which the password hash has been recovered, while I'm looking out in a broader sense. In my mind, the current change in the cookie architecture would shuffle this off to a v3.2 timeframe, but still should not be ignored.

[Yoda_IRC]

Feel free to correct me if I'm wrong but doesn't generating a collision mean that you only gaurantee that the hash of the new data (i.e. the item that is a collision) is the same as the hash of the orriginal password? It might not nessacarrilly be the user orriginal password but just a value which has the same MD5. Yes this new value could be used to log into the phpBB board as it uses MD5, but thiking about the point with users using the same password multipule times. If you try to use this collision value as a login then its only going to match passwords for sites that also use MD5?? unless ofcourse what you have is the orriginal password which will always match.

Even if your board is attacked it can be repaired, however even under a catastrpohic attack you wouldn't want sensitive data comprimised. Assuming the password hash is unbreakable (yes I know thy can all be broken given enough time) then even if they obtain all the data you have they will not have access to other sites or even your sites login data. However I suppose if the attack was bad and they could alter files they could just put in some spyware, change the login script to save the password and username to a file and send it somewhere but we can't really do anything about that as phpBB can only secure itself, it cannot secure your server for you.

Having said this isn't the security of the data's path only as strong as the weakest link? and is password hashing the weak link? Most boards I have seen don't have SSL, this means its sending your password unencrypted across a network. Im not too knowledgeable on these things but surely it could be intercepted on route? no password hash cracking needed, you got a nice unencrypted password to use. And then without SSL you don't have server authentication, meaning your machine could be impersonated to obtain login details.

The strength of security required really depends on the apllicaton. For instance E-commerce sites need alot of protection because they are handling extremely sensitive data. At an ordinary forum the risk is much less because there is alot less an attacker could gain so wouldn't bother trying so hard.

[Martin Blank]

Feel free to correct me if I'm wrong but doesn't generating a collision mean that you only gaurantee that the hash of the new data (i.e. the item that is a collision) is the same as the hash of the orriginal password? It might not nessacarrilly be the user orriginal password but just a value which has the same MD5.

This is correct. Any hashing algorithm with an output of less than infinity (read: all) will have collisions at some point, simply because at some point, the maximum possible variations of the hash output will be exceeded by the maximum possible variations of the plaintext input. A good algorithm, however, should be strong enough that finding a collision is computationally infeasible. These attacks against MD5 find collisions in an hour, give or take. In my tests, I've had them take as short as 47 minutes, and as long as just shy of two hours. Lengths of initial plaintext have been as short as six letters and as long as 128.

Yes this new value could be used to log into the phpBB board as it uses MD5, but thiking about the point with users using the same password multipule times. If you try to use this collision value as a login then its only going to match passwords for sites that also use MD5?? unless ofcourse what you have is the orriginal password which will always match.

The use of MD5 is extremely widespread, as it was believed secure. While phpBB is limited to 32 characters, and some sites limit lengths to 16 or even 8, not every site does so, nor can we be sure that every site properly validates the length of a provided password. At the moment, the programs provide only 1024-bit collisions, but there's no guarantee that a method will not be found that shortens this.

Even if your board is attacked it can be repaired

In this paragraph, you're getting into a whole range of other issues. While compromise of the database through SQL injection or other method is a concern, it is merely a vector for obtaining the information critical here.

Having said this isn't the security of the data's path only as strong as the weakest link? and is password hashing the weak link?

The weak link here is that we don't have an encrypted connection, but that's not feasible for the overwhelming majority of boards. Even for those that do have this as an option, most of them wouldn't know how to use it. Your other mentions here involve sniffing, DNS cache poisoning, or phishing, which are all vectors to gain sensitive material.

At an ordinary forum the risk is much less because there is alot less an attacker could gain so wouldn't bother trying so hard.

But the information so gained could be valuable elsewhere. This is, and has been, one of my biggest concerns. However, with the change to the authentication, the compromise of the hashes is less of a risk, and so this is now a lower priority issue.

[didijeeeke]

The md5 encryption is udesd to encrypt your passwords in the database. THis means that if a hacker hack's the database of the phpbb server.he can't read the passwords of the users. There are a lot of people who make use global passwords. this is not the people's there fault. you can't expect them to have a other pasword for every acount. That's why the passwords are encrypted. This doesen't makes phpbb more secure. If you are sure no1 can hack your database you don't even need a pasword encryption.

So i should not realy worry md5() as long you make you database secure eneuf.