Password hash methods

MD5 is now officially all but obsolete: http://it.slashdot.org/it/05/11/15/2037232.shtml?tid=172&tid=93&tid=228

With that said, we should consider switching to a more secure format. We might consider storing multiple encryption methods in our DB though for legacy purposes and for integrating with other projects and having the "proper" formats ready to go.

A collision for an already existing hash is not what this is about. What this is about is the ability to create two items that have the same hash. So I would have to generate two plain-text passwords that have the same hash, get you to accept one of them...a big waste of time, because if I can get you to accept what I want as the password, why do I need two of them? This is a problem for electronic signatures for electronically marking files for download, documents, stuff like that, to make sure you have an authentic copy. Get somebody to legally accept the one document, replace it with the second, and they can’t deny it, since it has the same hash.

Not that a more secure hashing method would be a bad thing, just that there’s no reason to panic over this. One post did mention developers should make their apps able to adapt to different encryption methods.

Don’t know if this can be helpful, but I had come accross an article about password hashing

When you say to a more secure format, do you mean SHA1 ? Don’t know much about this, but security is of the essence thus it’s a good idea to have MD5 replaced...

Was indeed thinking SHA1... some apps already use it now, like SMF. And thanks for the info, too!

SHA1 is no better than MD5.
http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html

Apparently the latest preference is SHA-256 or SHA-512, neither of which is built-in to PHP at this time. However, there is an implementaion of the algorithm here:
http://dev.barad-dur.nl/sha256/

There is a lot of good reading in the user comments on the official PHP documentation pages for MD5 and SHA1.

Hmmm, I thought SHA-1 was stronger than MD5...

I think the point here is to make MODx secure enough to avoid easy hacking, but maybe investing too much time in making it more secure than any other CMS is not the right option.

One thing comes to mind, what would optionnal support of https in MODx entail ? Some CMS do it, it’s slower of course but if we’re talking security for corp folks it might be a path worth pursuing... ?

Quote from: davidm at Nov 16, 2005, 11:02 AM

Hmmm, I thought SHA-1 was stronger than MD5...

I think the point here is to make MODx secure enough to avoid easy hacking, but maybe investing too much time in making it more secure than any other CMS is not the right option.

I think that’s exactly right; I think this can all be left up to the individual by providing various pluggable authentication options, including an API and/or template with which to author their own. This is part of the federated user management concept and would allow us to offer various credential encryption options (e.g. users can decide if they want high-security and less performance, or lower-security in favor of increased performance, etc.)


Quote from: davidm at Nov 16, 2005, 11:02 AM

One thing comes to mind, what would optionnal support of https in MODx entail ? Some CMS do it, it’s slower of course but if we’re talking security for corp folks it might be a path worth pursuing... ?

I think we already support this and it’s just a matter of the webserver protocol support being turned on. There is an HTTP/HTTPS option in the system settings indicating which protocol the site is being served as, but I’m not sure if that really does anything.

About the https I just realized I had not seen the https setting, dumb me... yeah I am building my first MODx website right now, there are still things I am discovering

There is an HTTP/HTTPS option in the system settings indicating which protocol the site is being served as, but I’m not sure if that really does anything.

Don’t know if the https settting does something, but if your website is running https, wouldn’t that mean it’s harder to intercept the encrypted password, since the http request is encrypted too ?

Quote from: davidm at Nov 17, 2005, 02:46 AM

Don’t know if the https settting does something, but if your website is running https, wouldn’t that mean it’s harder to intercept the encrypted password, since the http request is encrypted too ?

It does, but (and someone correct me if I’m wrong) even though that is great for requests involving logging in or sending a credit card, it’s not so wonderful if applied to an entire site. Necessary in some cases, but not optimal.

I believe the best-case situation is to have the pages involved in the encrypted requests in a secure HTTPS-specific directory, separate from your public HTTP pages that are meant to be served quickly, without the performance degradation associated with SSL encryption. This is because with HTTPS, the entire request/response transaction is encrypted, rather than data elements that have been identified as requiring encryption.

That said, I’m not sure how we could handle something like this with MODx, but it does offer some flexibility for site admins who allow HTTP and HTTPS access to the same content, giving their visitors a choice of using HTTPS communication on whatever pages they choose to. In this scenario, it is still a useful security option.