SHA256 instead of MD5 :: Possible?

[rob30UK]

Is it possible to switch vBulletin over to using SHA256 hashing instead of MD5?

If so, would it be possible by implementing a plugin, orwould the vBulletin developer framework not allow access at that level.
I really dont want to have to change the php file and nullify support.

Thanks for any help.

Rob

[Paul M]

I don't see how you could do it without editing a few files. Why would you want to do this ?

[rob30UK]

Paul,

I have a large forum that currently uses sha256 hashes for passwords.

I am converting to vBulletin but don't want to ask a few thousand members to use the 'lost password' feature.

I simply need SHA256 and if vBulletin are gonna nullify my support because I need this then so be it (Although it REALLY SHOULD be supported ANYWAY!!)

What vBulletin have to realise is that there are other boards out there with different hashing algo's. They support loads of boards via Impex, yet don't support other boards password algo's..... seems a very needlessly (dare I say lazy...) overlooked point.

Why only go half way?

[Eruantien]

This thread is particularly relevant considering the recent security breaches.

Instead of starting a new thread, I would really like to see if getting a SHA256 option can be made viable when using vB.

[squidsk]

The recent security problems have nothing to do with which hash function is used.

That being said you'd need to re-write the login system to use a sha-256 scheme including adding in a javascript library that will do the sha hashing on the client side. Additionally there would be encoding considerations to take into account in that you'd have to make sure that the character encoding of the password is maintained between the two forum softwares. There are probably other issues as well.

[kh99]

I'm not any kind of expert in password hashing or security, so someone please correct me if I'm wrong, but: I think it may be relevant because my understanding is that the user tables were taken, and some passwords obtained by some kind of guessing (brute force, dictionary, or whatever you call it). This is possible because the md5 algorithm is pretty fast, so a lot of guesses can be made quickly. And if that's true then I understand that crypt() with blowfish is better than just replacing md5() with a call to hash('sha256'...) because blowfish was designed to be slow to make guessing harder.

(Edit: It is true that the hashing algorithm wasn't the cause of the original security breach, maybe that's what squidsk meant).

I think it might be possible to do it using plugins today (things were different when Paul wrote the above comment), but I'm not sure if that's the best way to do it because if you have a need to disable all plugins (or some curious or careless admin disables the product), no one would be able to log in. As for dealing with the browser side of things, I think if you made the algorithm blowfish(md5(password)) then you could leave the browser side of things the same. And if you used blowfish(md5(md5(password).salt)) (where salt is the existing vb salt column) then I think you could also convert the existing passwords instead of making everyone pick a new one. That wouldn't help the OP who wanted to transfer passwords from a different database, but if your concern is security in case the db is stolen then it wouldn't matter. (BTW, "blowfish" isn't a php function, but you get the idea).

In any case, there is a mod that exists here: www.vbulletin.org/forum/showthread.php?t=288450 (which I haven't actually tried). I've been thinking of making one myself because I have a few other features/options I'd like to add (like converting of existing password as I mentioned above).

[FreshFroot]

Well even if the breech wasn't an attack via account compromise. The fact is the password hashes were STOLEN. And, they CAN be decrypted with the proper tools, time and effort. Although it would need to be a targeted attack for a certain member to go that far.

As for encryption, SHA1 should be used and I would've though vB5 would have it. Guess one more thing that IB failed at once again....

[squidsk]

Originally Posted by FreshFroot

Well even if the breech wasn't an attack via account compromise. The fact is the password hashes were STOLEN. And, they CAN be decrypted with the proper tools, time and effort. Although it would need to be a targeted attack for a certain member to go that far.

As for encryption, SHA1 should be used and I would've though vB5 would have it. Guess one more thing that IB failed at once again....

If the hashes are stolen then the hash function used is irrelevant as with modern graphics cards being used for processing power over a couple of machines brute forcing is not a particularly arduous task, especially as most people do not actually have very good passwords.

Just as a note SHA1 is not considered secure and is recommended to be discontinued by NIST. NIST, in a competition held a couple of years back, selected a new hash function to be SHA3 as SHA2 was no longer deemed to be secure enough for long term use and should not be used as of 2010.

[nhawk]

People need to remember that MD5 is a one way hash, it can't be decrypted into plain text.

MD5 was found to be insecure for things like security certificates and the like because of the possibility of a collision (duplicate MD5 hashes). It had nothing to do with password storage. Or at least I never saw anything about passwords and MD5 except to warn that the MD5 hash needs to be properly salted.

There are only two ways someone can get the password for vB. One is by brute force. Or more commonly known as guessing until the password guessed equals the MD5 hash. The other, more common way is for someone to use the same password on multiple sites, the clear text password is stolen and then used to access other sites.

[kh99]

Originally Posted by squidsk

If the hashes are stolen then the hash function used is irrelevant as with modern graphics cards being used for processing power over a couple of machines brute forcing is not a particularly arduous task...

Oh, I see what you meant. Yeah, that makes sense. But my understanding is that bcrypt was made to be slow and to be more difficult to implement using a GPU, by repeating the slower parts of the algorithm many times, so it's an improvement over using a hash algorithm directly. (What I said above wasn't quite correct - it's bcrypt that was designed to be slow, not blowfish, although bcrypt is based on blowfish).

But like you said it's likely passwords were discovered by trying a list of common or known passwords, so maybe using something that takes, for example, 1/2 second for the average server to check still isn't really slow enough to make a difference.

Edit: The first answer here has a good summary: http://security.stackexchange.com/qu...passwords?lq=1