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

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

Posts: 51
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


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!


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


Posts: 410
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

  Go To Top

Powered by XMB 1.9.12
XMB Forum Software © 2001-2020 The XMB Group
[Queries: 16] [PHP: 18.8% - SQL: 81.2%]
Thanks to competitions website.