How to salt passwords?

crypto · Worker Joined: Aug 02, 2004 Posts: 159

Is there step-by-step guides how to salt passwords in ravennuke 2.4x?

fkelly · Posted: Sun Nov 13, 2011 8:56 am

You don't need to. The field type is md5. User enters text and the system stores the result as a md5. You don't need any salt with that pepper.

Obviously, there are more secure approaches to storing passwords which do involve salts etc. and it wouldn't take a genius to hack some MD5 based passwords, particularly where the text version of the password is not somewhat complex, but on the other hand I am not aware of anyone really hacking at *nuke site passwords. The stuff that is stored on most of these sites isn't worth the effort to hack at, IMHO.

crypto · Worker Joined: Aug 02, 2004 Posts: 159

Yes, I'd like to know if someone has successfully salted ravennuke's MD5 passwords to gain extra-security for passwords. Can this be done easily?

Guardian2003 · Posted: Sun Nov 13, 2011 8:19 pm

Yes it can be done, though you would need to alter a number of files as well as write a routine to upgrade existing hashes.
Can it be done easily? I guess it really depends on your level of PHP skill. The basic concept is well known and straight forward;
$password = $salt + $password;
$newpassword = md5($password);

Now before you run off and set to work, there are a few things to think about. Apart from the need to change a fair amount of code to make sure you are doing the same thing consistently, you also need to keep in mind that MD5 creates a 32 character string (or 16 character if you use the 'raw' option). So, you have to ask yourself, what is the difference between one 32 character string and another 32 character string?
Unless your user has used a common or predictable password, there is no difference whatsoever. Someone using Rainbow tables on a truly random password (that uses numbers, letters and other characters in uppercase and lowercase) will find it just as time consuming to try and guess that 32 digit sequence whether it was slated or not.

If you need better security use something like SHA2

crypto · Worker Joined: Aug 02, 2004 Posts: 159

Well, it's better to let this to be done for someone who is more familiar of this topic & coding Smile

.

Would it be possible to get patch/addon/module for this?

Guardian2003 · Posted: Fri Nov 18, 2011 9:18 am

No, because it involves changing the core code, which might get accidentally wiped out during an upgrade and if you lose the salt value, you'll never, ever be able to log-in without a lot of work.

montego · Posted: Sat Nov 19, 2011 12:47 pm

I thought that is what $sitekey was for in config.php? New installations should ALWAYS change that to something else.

Guardian2003 · Posted: Sat Nov 19, 2011 1:02 pm

As far back as I can remember (nuke 5.6) $sitekey has never been used for anything relating to user passwords.
RN does however currently use it as part of the anti-csrf token.
I think this is why it has always been possible to create a password in the DB and then switch the table field to md5 - you wouldn't be able to get a log-in match if the password was salted using this technique.

montego · Posted: Sun Nov 20, 2011 7:09 am

Guardian2003 wrote:

I think this is why it has always been possible to create a password in the DB and then switch the table field to md5 - you wouldn't be able to get a log-in match if the password was salted using this technique.

Fantastic point Mr. G! Agreed.

crypto · Worker Joined: Aug 02, 2004 Posts: 159

Have you made any plans for rvn v2.5 e.g. converting MD5 to more secure format or adding salt to it? By including this to ravennuke core; it would help ravennuke to be securer distro than ever + due the extra security it could give good security related PR.

Guardian2003 · Posted: Mon Nov 21, 2011 11:15 am

As per our PM's, please see this thread as it contains some more information.
Note also that RN uses a different authentication technique than the forums module so in essence there are two authentication routines that would need to be modified.

Only registered users can see links on this board!
Get registered or login to the forums!

Palbin · Posted: Mon Nov 21, 2011 11:16 am

I think the sitekey was used for the CAPTCHA at some point.

fkelly · Posted: Mon Nov 21, 2011 3:49 pm

@crypto ... is there any evidence that passwords have been hacked in real world attacks. I see plenty of hacking attempts on my site but not a password guessing hack. Mostly it appears to me that the idiots just want to create accounts so they can get in and spam the forums. RNYA handles that quite nicely if you require administrative approval of new accounts ... though I recognize that may not be feasible for some sites.

Even with MD5, if your administrative passwords are reasonable complex then hacking them is no picnic.

crypto · Worker Joined: Aug 02, 2004 Posts: 159

fkelly wrote:

is there any evidence that passwords have been hacked in real world attacks.

Yes, there are several 'forum db user/pw theft' cases found out in last few months. I don't publish cases here so these cases don't get unnecessary (extra) publicity. Risk factor is higher than earlier due the per-calculated md5-rainbow tables.

That's why I want to raise this topic on the table. I hope that next version of Ravennuke can add extra security for passwords by salting or using other stronger methods.

Guardian2003 · Posted: Sat Nov 26, 2011 8:50 am

Please PM me any links or other information you have that involves cracking of RavenNuke(tm) user credentials because I constantly monitor over a dozen security related sites and have not come across anything, so I would be very interested in any new sources of information.

I know in php-nuke it is fairly easy to obtain user/admin credentials because the php-nuke CAPTCHA doesn't actually work very well and the core code has several un-fixed vulnerabilities but in RN we have counter-measures for a number of attack vectors including CSRF, XSS, brute-forceing, proxy and others.

crypto · Worker Joined: Aug 02, 2004 Posts: 159

These sites weren't using Ravennuke; they were using different CMS's. I'll send more info via PM.

These were case where attacker(s) got access to user data in way or in other, e.g. maybe they got root access or admin/user rights somewhere, or attacked via security holes at sqlserver/webserver/cms. There are no detailed information available regarding the attack method. All of these cases were taken to the police for detailed investigation.

The point is that CMS should have enhanced security for passwords. For example US-CERT says that MD5 "should be considered cryptographically broken and unsuitable for further use," and most U.S. government applications now require the SHA-2 family of hash functions.

papamike · Posted: Mon Nov 28, 2011 11:40 pm

I see no reason to go beyond salt unless a SHA-2 algorithm is used. But SHA-2 can always succumb to the same mathematical problems that SHA-1 had. Maybe SHA-3, when released will be the saving grace.

MD5 actually provides 128bit security and has been broken. Not really sure if it could be used for bank transactions as an API is usually used in concert with other applications to conduct those high risk transactions. (I'll have to update my knowledge on that).

Anything can be attacked, nothing is really safe. But, by using a algorithm there can be several avenues to take that slows down a attack.

Salt on the other hand can be successfully attacked, but, it may take some time for the hacker to decipher just one password. Hacking several is just plain out computer intense. And by there being a super secure CMS (like Raven Nuke) with umpteen users all having different users with different passwords pretty much frustrates the hacker into quitting. Even if the database is hacked.

Now, by using untested blocks and/or modules on a RN site and the site is defaced, or otherwise hacked. Then you can surely blame it on that untested block and/or module. Beware of add-ons too.

crypto · Worker Joined: Aug 02, 2004 Posts: 159

In last few weeks media/press has reported many many cases where user logins and passwords have been stolen from websites. For example, today was published that UN email addresses, passwords and logins was hacked. Some think that the hackers used vulnerability on the website of the UN Database to extract the stolen details.

Only registered users can see links on this board!
Get registered or login to the forums!

.

As we know, RavenNuke can give extra protection against sql-injections and other attacks, but there could be also other ways how hacker could get in the user database. That's why CMS developers should prepare to do something against the 'worst case'.

I hope that RavenNuke development team will act now and try publish a permanent solution/fix where current MD5's can be 'upgraded' for better format or bring a way how MD5's can be salted. This should be a core function so it would helps all RavenNuke sites.

Bottom line is not that how "good or bad" password user have typed in; it's more about how password's has been saved in the database. Let's not talk about how users act regarding the passwords, let's focus how CMS can solve this situation.

fkelly · Posted: Wed Nov 30, 2011 3:49 pm

I am sure that your suggestion will be taken into account for subsequent releases of RN, particularly if there is evidence that RN has been hacked through passwords ... but even if not. However, note that RNYA configuration currently lets the admin set the minimum password length. Right now the default length, if the admin doesn't do anything is 4. That's probably too low. But how many admins have gone in and boosted it?

In the link you provided it says:

Quote:

It seems that some of the email account holders made it easy for hackers with some usernames apparently having blank passwords.

Of course if there is a site that lets users set a blank password they almost deserve to get hacked. There are probably other settings we could use that would be as effective, if not more so, than upgrading MD5 encryption. For instance, not allowing dictionary names, or even people's names, not allowing the username or email to be used as a password, requiring at least one special character and/or number in a password, locking the account after x failed attempts, etc. It always bugs me when sites have their own idiosyncratic password requirements (sort of like Animal House, double secret probation in some extreme cases) but it does make automated hacks a lot more difficult.

And quite honestly, even if you have SHA-3 on steroids, even something where the NSA and all the other supercomputers in the world can't crack the encryption, the password can still be hacked if the hacker can guess it because it's a simple dictionary word or equal to the username.

crypto · Worker Joined: Aug 02, 2004 Posts: 159

fkelly wrote:

There are probably other settings we could use that would be as effective, if not more so, than upgrading MD5 encryption. For instance, not allowing dictionary names, or even people's names, not allowing the username or email to be used as a password, requiring at least one special character and/or number in a password, locking the account after x failed attempts, etc.

It's good to understand that new 'pwd-policy' (above) doesn't give better protection for users who have already registered because their pwd's stays on the 'weaker format' vs. 'new policy' in the db. In that case, pwd change should be able to be forced e.g. at by admin "manual command" which generates unique passwords for all users immediately. Then the password should follow a new policy + $ya_config['pass_min'] and "$strs =..." parameters (in functions.php).

For new RavenNuke installations and for 'new user registrations' it might give better pwd-security against rainbow tables at first place, but it doesn't fix the root cause: weakness of MD5.

How big work it would be to get MD5's to be fixed for upcoming version / core?

papamike · Posted: Wed Nov 30, 2011 4:49 pm

Lol, I've been doing this a long time. Why attempt to fix something that's not broken. RN hasn't been defaced/hacked and it's been out there long enough for anyone to dig through the code and look for holes. If you install an add-on, module, etc., that hasn't been properly tested, then you open yourself up for attack.

I can't imagine how fast a standard computer would have to be for it to run a "guessing game."

Instead of messing around with the security code of RN, seems to me that the users need to be educated in regards to things that they shouldn't do. See my first paragraph above for examples.

crypto · Worker Joined: Aug 02, 2004 Posts: 159

papamike wrote:

I can't imagine how fast a standard computer would have to be for it to run a "guessing game."

If you have a high-end home computer boosted with 8xAti Radeon 6970, it can calculate about

Only registered users can see links on this board!
Get registered or login to the forums!

(26.000.000.000 c/sec). With cheaper win7 machine with one ATI HD6990 the speed is 6,3 billion c/sec. There are also online services available which can give shared calculation power etc.

papamike wrote:

RN hasn't been defaced/hacked and it's been out there long enough for anyone to dig through the code and look for holes. If you install an add-on, module, etc., that hasn't been properly tested, then you open yourself up for attack.

As I already said that even that RavenNuke can give extra protection against sql-injections and other attacks, but there could be also other ways how hacker could get in go the db. That's why CMS developers should prepare to do something actions for this.

The key focus is to add more strenght RavenNukes db entries/hashes! This is something that many other CMS has already done. I hope that Ravennuke will follow them by adding extra protection to db.

This is something that should be fixed regardless how 'good or bad' RavenNuke is blocking injections or how' secure/unsecure' 3rd party addons are or 'what kind of passwords' users are using.

papamike · Posted: Thu Dec 01, 2011 8:28 am

Quote:

If you have a high-end home computer boosted with 8xAti Radeon 6970, it can calculate about

Only registered users can see links on this board!
Get registered or login to the forums!

(26.000.000.000 c/sec). With cheaper win7 machine with one ATI HD6990 the speed is 6,3 billion c/sec. There are also online services available which can give shared calculation power etc.

The video card isn't going to help at all unless the entire system configuration is changed to meet the requirements. I would say that the home computer will bottleneck and cause the system to freeze. Hackers/Crackers whoever don't usually use Windows, they're usually a bunch of Linux freaks. And 8xAti Radeon 6970 is useless unless the user knows how to reconfigure the hardware for optimal use.

Actually there are password sequences that can't be attacked through brute force because of the motherboard configuration. You must remember that the motherboard will only accept 1's and 0's (True Machine Language). For instance a password of 0000001000000 is harder to hack than a standard *Tll06*$-Klm because of the way the motherboard handles code.

And, once a surge is identified by the host server it will cause the server handling that account to shut down automatically, until the cause for the surge is identified. And most host will call the owner of the account before re-initiating service.

montego · Posted: Thu Dec 01, 2011 8:07 pm

Not to mention NukeSentinel(tm)'s anti-flood measures (if you choose to turn it on of course).

crypto · Worker Joined: Aug 02, 2004 Posts: 159

papamike wrote:

And, once a surge is identified by the host server it will cause the server handling that account to shut down automatically.

Montego wrote:

Not to mention NukeSentinel(tm)'s anti-flood measures (if you choose to turn it on of course).

RavenNuke's nice security features (e.g. anti-flood, script blocker etc.) doesn't help if attacker can get in to the db in way or in other.

Db's information security has to be taken care also. Something should be done so that pwd-data could be secured in other ways than with plain MD5. I hope that this could be prioritized highly in the RavenNuke development.

The risk is out there so why not act now? What is the major reason to ignore this topic and not enhance pwd-database-security? This would benefit all Ravennuke sites/users and drive Ravennuke to be more secure CMS.