| Author |
Message |
papamike Theme Guru

Joined: Jan 11, 2006 Posts: 135 Location: Southern Influence
|
Posted:
Sun Dec 04, 2011 7:22 pm |
|
| 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. |
|
|
|
 |
duck Involved


Joined: Jul 03, 2006 Posts: 267
|
Posted:
Sun Dec 11, 2011 2:57 am |
|
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. |
|
|
|
 |
nuken RavenNuke(tm) Development Team

Joined: Mar 11, 2007 Posts: 1535 Location: North Carolina
|
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. |
|
|
|
 |
Guardian2003 Site Admin

Joined: Aug 28, 2003 Posts: 6373 Location: Vsetin, Czech Republic
|
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. |
|
|
|
 |
crypto Worker


Joined: Aug 02, 2004 Posts: 159
|
Posted:
Sun Dec 18, 2011 1:07 pm |
|
| 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) . |
|
|
|
 |
|
|
|
|