How to salt passwords?

Theme Guru Joined: Jan 11, 2006 Posts: 170

Quote:

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.

RavenNuke has about the best development team that I've seen. If they run across something that should be fixed I am confident that they will fix it. You seem to be grabbing bits and pieces of articles and pasting them here. Then running off of those.

Most security breaches that you read about are usually the work of an insider just trying to prove a point. Just like the person who has been making these little puny attacks against my website since I started responded to this topic. Went from 0 to 50.

In my 35+ years as a Network Engineer I've never seen anyone more entrenched with the idea of security. When a network is first setup and running, all kinds of possible attacks are run off grid in an attempt at breaching security. When found they are corrected.

Anyhow, I do enjoy using a product as secure as RavenNuke, definitely a hot ticket item.

Involved Joined: Jul 03, 2006 Posts: 273

I agree with Crypto and just because you don't see a lot of cases of Ravennuke password hacks exposed does not make for a good argument not to beef security. One can argue back that there isn't many reported cases because Ravennuke is off the hackers radar because it is so sparsely used nowadays compared to other cms's. Nobody is interested in hacking RN sites because most of them have nothing of value to offer them. I mean if you want to search for Vul's in a CMS wouldn't you want to aim your efforts at something like word press or Druupal etc which have millions of sites each or would you prefer to aim at a cms that has a handful? Incidentally I had an RN site compromised. Not actually due to the code itself but by users stupidity and the fact their is not much built into it to help alleviate the weaknesses caused by user stupidity. Things like salts and other hashing methods could do immense effort to reduce those vulnerabilities.

registered · Posted: Sun Dec 11, 2011 6:34 am

This is something the RN Team will look at for future releases. RN 2.5 is too far along to add anything else to. A change like this would require much testing and planning as to how do you deal with existing passwords stored in the database.

Posted: Sun Dec 11, 2011 9:06 am

I think the easiest way to deal with password changes is to force a reset so the user has to go through the 'lost password' routine.
My main concern with changing the encryption method is how it might affect some 'ported' modules or 'bridges' that utilise their own authentication method.
Obviously it would be too much of an issue if we had a full Auth API that could deal with registrations, logging in, lost passwords and authentication etc so it could be extended for use in bridges.
I actually had to do something similar recently in my Job Board module as I needed to create stand alone accounts for Job Seekers and Recruiters that fitted around the existing RN routines.

Worker Joined: Aug 02, 2004 Posts: 165

nuken wrote:

This is something the RN Team will look at for future releases. RN 2.5 is too far along to add anything else to.

We know that scheduling is a hard task because there is lots to do and resources are limited. Let's hope that "for future releases" doesn't mean that it will take a long time... IMHO this should be highly prioritized and the 'release target' should be put more like an upcoming few months, not like a year(s) Smile

.

Posted: Sat Jun 02, 2012 5:43 am

What is the status of this? How this has been proceed?

Posted: Tue Jun 05, 2012 11:46 am

As nuken mentioned in his post on December 11th; it is something that is being looked at.
No one can say for certina when such a change will be made because there are so many, many things to consider.

If you are desperate to use a salt or a different encyption technique then you might want to go ahead and modify your own installation to suit your specific needs.

Posted: Mon Jun 11, 2012 3:27 am

Guardian2003 wrote:

As nuken mentioned in his post on December 11th; it is something that is being looked at.
No one can say for certina when such a change will be made because there are so many, many things to consider.

Yep yep... This is something that should be fixed: We have seen the risk what could happen if salt is not used and leak happens... e.g. at Only registered users can see links on this board! Get registered or login! where 6,5M unsalted passwords were leaked (3,5M of which have already been revealed through brute force attacks).

Are rvn-developers working on at this topic actively? Could somebody comment more detailed about possible fix / patch / new release -estimations?

Posted: Mon Jun 11, 2012 9:37 pm

I'm not sure if anyone is actively looking into this issue specifically, but it's likely a job for one of our more experienced coders whom are in high demand; both locally and abroad.... Although I will verify it is on our internal road map Smile

As for release date estimations it's too early in our dev cycle for me to guess... and I'm probably not the one to ask... although we ARE striving toward attaining regular release schedule. It will depend somewhat if we end up cutting a patch release or not, as there is an ambitious amount of work planned (and already completed) for the next major release.

I'm pretty sure if a patch is released it would be unlikely to include anything regarding this; as it's not a "minor" issue.

Posted: Sat Mar 16, 2013 12:43 pm

spasticdonkey wrote:

Although I will verify it is on our internal road map Smile

I'm pretty sure if a patch is released it would be unlikely to include anything regarding this; as it's not a "minor" issue.

This has been on the table very long time... May I kindly ask that what's up regarding this feature request / topic?

Posted: Mon Mar 18, 2013 4:11 am

crypto wrote:

spasticdonkey wrote:

Although I will verify it is on our internal road map Smile

I'm pretty sure if a patch is released it would be unlikely to include anything regarding this; as it's not a "minor" issue.

This has been on the table very long time... May I kindly ask that what's up regarding this feature request / topic?

We tend to work methodically. We release a major version and then one or two patch releases with minor enhancements/bug fixes.
The whole "password" enhancement is really a major work because it impacts a lot of different area's of the core code; registration, lost passwords, converting old user accounts, user authentication, forum session authentication etc.
As Spasticdonkey mentioned, the development team as individuals, are always busy and in demand, whether it be 'real life' or in the virtual world giving support, writing code for others so we have to prioritise the work that goes into RavenNuke(tm) when we do manage to get some free time.

On top of all this, the Team have also been working on a completely new system to make the most of UTF-8 support, a flexible user API, a new "look" with a new CSS driven GUI system including lots of new templates, RTL and LTR language support, built in support for a number of different 'tools' such as sliders, tooltips, a global feedback messaging system, breadcrumbs, flexible templates so you can alter various layout types without editing any code, mobile freindly templates, HTML5 ready/compliant and the list goes on and on and on....

Posted: Wed Mar 27, 2013 7:21 am

It's sad to hear that security enhancement got so low priority in this case. Let's hope that it won't take another 18 months to get this fixed.

Posted: Wed Mar 27, 2013 7:34 am

For what it's worth, Drupal went from a MD5 encrypted password to a salted and encrypted password in a fairly recent release. Their code is open source and we could possibly "borrow" some of that (or at least look at it for guidance) if we decide to go that way.

That said, the primary risk here is that a hacker group will get a copy of your user table and be able to hack away at it on a separate computer where they can run multiple cracks at each password. MD5's can be broken that way but so can salted and encrypted passwords. The latter is just more difficult and time consuming but with the right program and a computer you can just leave running the cracking effort anything can eventually be done.

Incidentally, the recent release was just a patch release fixing obvious bugs in RN2.5. 3.0 will be a feature and infrastructure release.

Posted: Wed Mar 27, 2013 9:07 am

Things we would like to accomplish and things we have the man power and time to do are two totally different things. Enhancements like adding a salt or changing encryption methods are major changes to the system that will take many hours of testing and coding. If a hacker has access to your database to get the encrypted passwords in the first place, you are already in a world of hurt. IMO, admins using weak passwords are a bigger threat to site security than anything. The beautiful thing about open source is that any user that has a need for changes to their cms and make those changes.

Posted: Mon Nov 11, 2013 10:55 am

It's easy to implement:

ALTER TABLE cms_users MODIFY COLUMN user_password varchar(255) NOT NULL
UPDATE cms_users SET user_password = 'md5:' || user_password

Verify password by

Code:

'SELECT user_password FROM cms_users';


      list($algo, $pass) = explode(':', $user_password, 2);


      return \Poodle\Hash::verify($algo, $_POST['password'], $pass);

http://code.google.com/p/dragonfly-cms/source/browse/includes/poodle/classes/hash.php?name=v10

You can store passwords in SHA1, SHA256, BCrypt, SCrypt, PBKDF2, etc.
The trick is to store the password hashing algorithm inside the password field separated by a colon.

When a user logs in and $algo is still MD5 you can update his password to BCrypt for example.
Else, it will stay MD5.

Custom implementations are possible as Hash::verify() has a "if (function_exists($algo))".
So you could have:
UPDATE cms_users SET user_password = 'ravenhash:' || SHA1(user_password);

Code:

function ravenhash($string, $raw) {


    return sha1(md5($string))


}

Posted: Tue Nov 12, 2013 8:40 am

I made a quick patch for RavenNuke v2.5.1

Not tested
Probably requires PHP 5.3 (or modify it yourself)
only user accounts (not admins)
default password hash algorithm = bcrypt
does NOT replace md5 password at login with new hash

http://mhxsolutions.nl/media/archives/RavenNuke_v2.51-password.tar.gz

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

Thanks DJ! We'll take a look.

Posted: Thu Nov 21, 2013 9:56 am

can u please explain the changes to the rest of the files u have been done because there are many people with mod installed.

Posted: Sat Nov 30, 2013 8:49 pm

hicuxunicorniobestbuildpc wrote:

can u please explain the changes to the rest of the files u have been done because there are many people with mod installed.

Grab an original copy of the Ravennuke i mentioned and then diff it.
Then you know what i've changed Wink

Posted: Thu Jan 02, 2014 3:11 pm

Is this mod going to affect the rest of the password has been made from the rest of the users? Rolling Eyes

Posted: Thu Mar 06, 2014 5:42 am

Anyone tried this mod with success?

registered · Site Admin Joined: Aug 22, 2007 Posts: 1775

Sorry no, because you should write a clear documentation.

Posted: Thu Mar 27, 2014 10:51 am

neralex wrote:

Sorry no, because you should write a clear documentation.

1. Download the above mentioned zip
2. Either:
a. use password-patch patch file and upload /html/includes/
b. upload contents of /html
3. run db-changes.sql

Not that hard to use it Wink

Posted: Thu Mar 27, 2014 1:58 pm

I know how i should install it but this is not the question.

Do you have it tested because lines like 'not tested' creates in the most cases a lot of errors and i don't have the time to crash a fresh install because i don't know how it really works and for that you have which files updated?!

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

djmaze,
Thanks again for providing this. The team has been pretty busy, but certainly we are interested in this as it could reduce the effort to implement with RN.