XMB Forum Software
Not logged in [Login - Register]
Go To Bottom

Printable Version  
Author: Subject: SHA-256 and thoughts on 1.9.12
bfgadmin
Member
***




Posts: 52
Registered: 5-7-2020
Location: Pittsburgh, PA
Member Is Offline

Mood: Technical

thumbup.gif posted on 12-4-2020 at 09:48 PM
SHA-256 and thoughts on 1.9.12


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!

:thumbup:



View user's profile Visit user's homepage View All Posts By User
miqrogroove
XMB 1.9.12 Lead Developer
*********


Avatar


Posts: 462
Registered: 10-1-2002
Location: Florida
Member Is Offline

Mood: Past Three O'Clock

[*] posted on 12-5-2020 at 12:58 PM


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.
View user's profile Visit user's homepage View All Posts By User
AlwaysLosingPasswords
Member
***




Posts: 21
Registered: 11-25-2022
Member Is Offline


[*] posted on 11-27-2022 at 02:15 AM


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! :lol: 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
View user's profile View All Posts By User
flushedpancake
Member
***


Avatar


Posts: 30
Registered: 4-1-2024
Member Is Offline

Mood: Optimistic

[*] posted on 4-23-2024 at 02:54 AM


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.



[insert witty quote here]
View user's profile View All Posts By User

  Go To Top

Powered by XMB 1.9.12 (Debug Mode)
XMB Forum Software © 2001-2024 The XMB Group
[Queries: 16] [PHP: 28.1% - SQL: 71.9%]