Hello!

I am about to publish a hack that convert's the default XMB password hash from MD5 to SHA256, and just wondering if anybody here had a suggestion on handling existing user passwords that are hashed using MD5.

On our site, I simply required all users to change their password (and allowed them to re-use their existing one, for ease of use) although I'm certain there is a better way to go about it.

Another issue I'm having is determining an appropriate value to salt the hash with. I suspect that using the member's username would be more than sufficient, although I'm not sure what (if any) additional security in real-world terms would be derived from this. I do believe that modern IT infrastructure should be more than capable of handling the additional computational requirements of SHA256 over MD5, and that the additional protection afforded to passwords stored in the DB would be worth it.

I also considered using something like regdate + regip, since a username may change at the site admin's discretion.

From an XMB/session based perspective, this does nothing to prevent the traditional "pass the hash" type attacks, but it would certainly protect users who insist on using the same password for all of their accounts.

As far as other changes go, I love the quarantine features, the variety of ReCAPTCHA options and much more. 1.9.12 is a major improvement over the previous releases!

This was something I considered with the new session system. For example, if someone wants to write their own http digest handler then the existing hash wouldn't work. But ultimately this is what we've inherited and any customization will require at least a re-login to supply the plain text password to upgrade each account.

One of the tricks I've seen is to store the salt value in the config file so that it isn't available if only the database has been compromised. But I haven't researched or given much thought to whether this is worth the effort and inconvenience.

miqrogroove, I have been thinking that an existing MD5 hash could be handled by a one time upgrade to iterate through each row in the members table and SHA-256 it. Then hashing new passwords with MD5, then running SHA-256 on that result. This way we could upgrade existing users without knowing their password. It would add an extra layer of complexity from a performance perspective but does increase the time tradeoff required for cracking.

Most attacks I have seen are XSS/SQL injection based. If you can extract the hash (cookie or db), you can pass the hash! Offline cracking is only required if you want to use that password to pivot laterally and compromise other services using that password. Using a separate password for different sites is a great low-tech way to avoid this.

It would be nice to have a secure way to store the salt, but (correct me if I am wrong) I believe it is primarily designed to defeat precomputed hash tables and the scary speed modern GPUs crunch through them. If you were to store a unique salt per user in the database, an attacker would still have to perform a standard exhaustive search using that salt vs rainbow tables. It would force them to crack each hash separately, and subject them to any reasonable time-delays we can throw in like the sha256(md5(plaintext)).salt

Quote: Originally posted by miqrogroove

One of the tricks I've seen is to store the salt value in the config file so that it isn't available if only the database has been compromised. But I haven't researched or given much thought to whether this is worth the effort and inconvenience.

I'd say go for it.

There's also the password_hash function, which seems more feasible on the basis that it automatically generates a cryptographically secure salt when it is run.

One tip I was given by a security expert, use the relevant native cryptography functions where possible.