This is really aimed at the core and security devs but general discussion is welcome also.

The XOOPS auth provisioning looks to be based on a MD5 hash. Ross Anderson, author of Security Engineering (had mine for seven years already) states that the security of MD5 and SHA1 have been cracked years before that.

So I recently set out to find other maintained alternatives and here is what I found.

crypt_blowfish algo, is said to be several orders of magnitude more secure than MD5. A portable version of the script is available online.

Another is Whirlpool, capable of up to 512 bit length having no known successful crack attempts.

MD$ is useful as a high speed file integrity check process, but honestly, should it really be depended on for auth provisioning for future XOOPS versions when we know what we know about its shortcomings?

Just food for thought.

Yes, the plan was to use bcrypt in XOOPS 2.6.0. There were also some other extra security measures that we wanted to implement in 2.6.0, like minimum 8 characters for password, minimum 5-6 characters for a database prefix, etc. This has not been done yet.

Excellent answer. But my grey matter is now trying to solve how hashes of existing passwords would transparently migrate over to the new hash (without user having to enter new P/W). I don't see a way. Would not even the password change process no longer recognize the old password because of incompatibility of the new hashing formula to the old hash?.

Quote:
I guess, this class, or some similar approach, might help. The goal would be to make it transparent to users in existing installations.

@xoobaru,

The 'easiest' way to make this somewhat transparent is the following:

1) On the new XOOPS version installation the update script would read each user's MD5 password from the database and then pass the MD5 encrypted password to the bcrypt::hash method with a workfactor set by the admin during install - this would prevent every XOOPS installation from using the same salt. Then store the result back in the database.
2) The XOOPS password routine would then just take a password from a user, MD5 encrypt it and then execute bcrypt::check method to verify password.
3) The password update feature would also take the XOOPS password from the user, MD5 encrypt it, and then execute bcrypt::hash before storing the new password in the database.

The site's users will never know that password storage has changed except for the first time they return if they have 'remember me' selected. I believe in that case we'd need/want to have them re-enter their password the first time after the XOOPS update.

The current setup is secure unless someone gets a dump of the database. Then it is a relatively simple matter to break any password you want. Off the top of my head I don't see an issue with the idea zyspec has mentioned. Sounds like it would work well. For some reason I dislike putting an "insecure" method in there but realistically the end product would be secure so it doesn't really matter since you would never have access to the md5 based password.

Otherwise the only other way I can see to do it would be to make use of the password retrieval service. Which of course requires the user to have their email recent etc.

More I think of it I think for an upgraded system the method zyspec mentions is likely the only one that makes sense. Anything else would need to be for a new system otherwise it is not likely to be secure if someone can access the database.

Realistically though, how secure do we need to make the database entry? The ONLY thing we are preventing is if someone gets a dump of the database that they can break the passwords. Realistically if they have access to dump the database they likely have access to also update a record and to update a record all they need is the "recipe" to make a password and they can "grow" their own password at home and inject it into the database for the account they want. Of course then the password won't work for the original user but by then a good hacker will have installed a new user or done something else to regain access later. Although cracking a current users password would be the most "stealth" way to do it.

Quote:

That's what this class I've mentioned before is doing:

Problem with that code Michael is you are supporting both the old and new password versions in the database. Unless there is something in that class I didn't catch, you will not be any more secure than you are with the current system for any users not having signed in since the change has been made. Hacker could also insert an older style MD5 password into the database and the system would update it for them. NOT cool.

With what zyspec is suggesting you do away with the insecure database all together and are still incorporating the old passwords into the system. The end result stored in the database would need to be cracked first to get the original MD5 version. There would be NO insecure data involved no matter how long it has been since the user has logged in.

Without looking I am assuming there is a system wide "key" that can be used with bcrypt. If you store this key in the secure.php file then it becomes pretty much impossible for a hacker to inject a new password into the system without that key or to break a current one in zyspecs suggestion even if they have full access to the database.

Also realize that I don't know how relevant this becomes because if someone can inject things into the database they could simply register to the system and upgrade their account to webmaster level and have full access anyhow.

By securing the passwords like this all you are preventing is someone using someone else's password to gain access to the system. And only if they get a database dump. And again, if they can do a database dump they likely can inject new data in the database and change passwords or groups. You may be able to detect new users with higher access than they should but that is really all your gaining by making the passwords more secure in the database.

Having other options to force stronger passwords would make more sense. And you could do this by group so that an admin level person would need a password that was say 12 characters minimum with mixed case etc.. Where someone with basic access could get by with a 4 character password with either one capital or 1 digit.

Quote:

Assuming passwords stay the same, any hacker getting his filthy clutches on a historical database backup can subject it to the MD5 exploit and use the raw recovered password on a new bcrypt powered auth. So I would be inclined that once users make the transition by re-entering their password, to prompt/require them to change it again under 100% bcrypt process. As long as XOOPS is pure bcrypt after the intitial requirement to use MD5.

Bear in mind webmasters that the most secure auth hash in the world is pointless if you are not ssl encrypting your website, as a simple well targeted sniffer is all that would be needed to recover anyones authenticaton. Without having to resort to database access/hash cracking.

Quote:

This would be very hard to get a copy of without gaining access to wherever the backups are stored but Realistically the way to handle this potential issue is to incorporate a password policy system into xoops which I do not believe is currently possible. When a user's password expires force them to have to get a link via their email account to allow them to change their password.

With a password policy system you could upgrade and expire everyones passwords. Or give them a 10 day window to change before they expire etc.

And as far as SSH goes, even with SSH a hacker could gain access and get the passwords by either hacking into either the server or the client computer or by a "man in the middle" attack. We did in in class. You need to look at the potential of the attack and see if it is a situation you really need to worry about it. No matter what you do a hacker will gain access if they want to one way or another if determined enough. We just want to make it more difficult.

If I wanted to gain access to this system as an example. If I can get the IP address of any of the site admins and can track them back to their PC's I can get into their PC's and retrieve any passwords I want one way or another. So regardless of how secure the site is the admins would at some point be the easier target. So we can go through scenarios all day long. What makes sense?

The easiest thing to maintain the current status "I" believe is a system like what has been spelled out here with a password policy forcing users to change passwords on occasion and making them somewhat cryptic. Then you only keep out those who are really determined.

And yes SSH is a great idea... But also make sure you never use open WiFi to access a site you administer, and always use a system with the most up to date security updates and security software to access your site. Your router needs to have the latest firmware as well.