Re: Strong, memorable passwords
- 7/6/2011 1:17:58
- fiammybe
This is a good idea! From an ImpressCMS standpoint, it could be hard to invent something that pushes people to do this. I could imagine a warning when the password is too short or not having numbers or uppercase or symbols, but is still remains the responsability of the user to have a decent password.
The warning might be possible though. Any ideas on this?
Strong, memorable passwords
- 6/6/2011 20:58:43
- Madfish
There's a good podcast by Steve Gibson looking at password strength and brute force attacks (MP3, 44MB), which is well worth a listen. He has an interesting take on what makes a password 'cracking resistant'.
He says that the difficulty of a password *doesn't* come from the amount of randomness in it, as is usually stated. The strength is actually a factor of the search space size (note that this assumes you have eliminated dictionary attacks).
If your password is all lower case, then each additional letter you add makes it 26 times hard to brute force. But if you have *just one* each of lowercase, number, capital and symbol in your password, then each additional character makes the password 95 times harder to crack, because you've increased the per-character search space that the attacker must investigate.
The upshot of all this is that you don't need to have random passwords that you can't remember. So long as you have included at least one of each class of character, then you can 'pad' the password with a private but memorable pattern of characters (effectively a salt) to make it long. Length is the most important thing in increasing the difficulty of brute force attacks.
So in summary, to have a very strong yet memorable password, he suggests:
1. Use at least one lowercase, capital, number and symbol.
2. Then pad the password out with your own private but memorable 'pattern' to make it long.
For more info, see his 'Password haystacks' page, which has a cool meter that gives you the actual search space size. Of course, reusing passwords across multiple sites is still a very, very bad idea.
Re: ImpressCMS - Security
- 29/5/2011 19:21:55
- skenow
as far as what we do that others don't -
* randomize db table prefix
* separate sensitive data and place in trust path
* randomize the trust path directory name
* randomize the name of the secure data file
* integration with html purifier
* multiple password hash options, selectable by site
* admin warnings for practices not followed
* of course, protector module
Re: ImpressCMS - Security
- 29/5/2011 11:39:30
- Madfish
Forgot to add: Session regeneration on login etc.
Re: ImpressCMS - Security
- 29/5/2011 11:09:16
- david
On the subject of security - I think it would be a sensible idea to look at moving the cache and compile directories to trustpath.
I notice that xoopscube also had this approach as well - as per this very good ticket suggestion here:
http://sourceforge.net/tracker/index.php?func=detail&aid=3101119&group_id=159211&atid=943472
The point about using a prefix is a very valid one, as it is possible I think to share trustpath over several sites on the same host (indeed, this is a possible way of achieving multi-site perhaps)
Re: ImpressCMS - Security
- 29/5/2011 9:48:28
- Madfish
Positives: The trust path, use of salts (see Vaughan's posts about how it works), and the updated hash algorithm. Also, support for SSL login and full-site SSL. There's the alternative authentication mechanisms but I haven't used them much so I don't know whether these are security enhancements or just conveniences.
Negatives: I think we have the basics covered. Sending passwords in the clear irks me, but the fact is that it is difficult to address in an out-of-the-box install and as far as I know all major CMS still work that way. I'm still working on adding support for 2-factor authentication (using hardware token) with Vaughan.
I think adding password stretching would be a useful improvement to harden password hashes against offline dictionary attacks, but I'm still arguing the case for that one.
ImpressCMS - Security
- 27/5/2011 16:48:20
- sato-san
I like to speak next week about CMS and security, in this case I like to show our special features. It is helpful for me, if you can tell me is short points what do you think about the ImpressCMS security.
Negative and positive things.
(Sure I have wrote my list, but maybe I forgot somethings?)
Thank you,
Rene
Re: Password stretching
- 19/5/2011 22:27:03
- Madfish
Citaat:
where $ithash has been run through a loop 1000 times, in essence it has rehashed it's own hash 1000 times? each time it appends $salted to the equation.
Yeah, except you probably only need to use the salt in the initial interation, as the interations after that are just to consume time.
It would probably take a bit of experimentation to find an appropriate value for $i (ie. one that won't kill an overloaded shared webhosting machine but still offers good protection). Might work best as an adjustable preference.
Apparently Lastpass will be hashing 100,000 times, but I imagine they can afford dedicated hardware to do that.
Citaat:
As for timing leaks... a random delay?
That should help.
Re: Password stretching
- 19/5/2011 17:33:18
- skenow
The author of the library I linked to used a fake hash and went through the process before returning the results, producing about the same time delay for both types of users.
I was incorrect in saying the library only hashes 5 - 30 times. That is the range for the number of times the iterations are doubled. At level 5, there are 32 iterations, at 6 there are 64, then 128, etc.
Re: Password stretching
- 19/5/2011 10:11:04
- Vaughan
Citaat:
Another interesting point is the timing leaks that can expose valid usernames because an invalid username returns more quickly than a valid username. (Usually, invalid usernames skip the hashing portion of authentication)
the solution to that is to create a dummy hash system if someone is randomly trying to guess usernames, so although the user doesn't exist, the system still goes through the hashing method before rejecting it.
The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!
Re: Password stretching
- 19/5/2011 9:41:31
- skenow
A good example is at http://www.openwall.com/articles/PHP-Users-Passwords
Several other projects have adopted this library for their password hashing (Drupal, WordPress and Vanilla are among them)
What is unique about his approach is the hash method, the salt and the number of iterations is encoded and embedded in the final hash. I guess it doesn't really matter where you store the salt, #of iterations or the method - if you get the db, you'll have them if you store it there, if they're stored in the filesystem, you could retrieve them, too, with an improperly secured host. He also uses only 5 - 30 iterations for stretching.
One could randomize the identifiers and store them in the TRUST_PATH, making it more difficult for an intruder - they would need the db and access to the file system on the server, as they do now with our current scheme.
Another interesting point is the timing leaks that can expose valid usernames because an invalid username returns more quickly than a valid username. (Usually, invalid usernames skip the hashing portion of authentication)
Re: Password stretching
- 19/5/2011 1:17:06
- Vaughan
so what you're essentially saying is that i should do this >
$pass = md5('password');
$salted = $salt1.$pass.$salt2;
$i = 1000;
$hash = hash('sha256', $salted)
$ithash = hash('sha256', $hash . $salted); // 1st iteration
where $ithash has been run through a loop 1000 times, in essence it has rehashed it's own hash 1000 times? each time it appends $salted to the equation.
hence 2nd iteration becomes;
$ithash = hash('sha256', $ithash . $salted);
& so on.
The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!
Re: Password stretching
- 18/5/2011 17:54:55
- Madfish
The salt is an excellent defense against dictionary attacks but it depends on the salt remaining secret. The case I had in mind was the possible breakin to Lastpass a couple of weeks ago, where they think both the hashes and the salt may have been captured.
A lot of our sites are probably on shared webhosting, where there is a fairly high risk of the server getting knocked over. Stretching isn't perfect either, but it might be a useful as an additional last-ditch measure to protect the passwords (which users will have inevitably used elsewhere) when all else has gone wrong.
Re: Password stretching
- 18/5/2011 11:40:34
- Vaughan
offline dictionary attacks shouldn't work on the hashes because each hash is unique to that user even if they have the same passwords.
ie. if 100 people register, and 50 of those use the same password, in the old version (and current xoops core), then 50 people would have the same identical hash.
in ICMS 1.1 this got changed as we introduced 2 salt keys into the equation.
1st key is stored in a file inside TRUST_PATH and stays constant.
2nd key is stored alongside the password in the users table, this key will be regenerated each time a user changes his password.
during the password hashing, each salt key is appended to the users password (which is 1st md5'd) which then is hashed again with whatever hash you select in admin.
ie.
$salt1 = 'gewgerhsggstrhTRHSHGRHJNTJTYHEGTRT54654ey4trrfgdgg92GtWbnmo57usf'
$salt2 = 'rgnjeroijgt884t8jf98ehsfdivusdbhviufbnREGRGHSREGSG435439ytfewfwefvn88'
$password = 'password'
$md5Pass = md5($password)
$hash = hash('sha256', $salt1.$md5Pass.$salt2)
essentially, both salt keys are a random 64 character alphanumeric string, the md5 hash is 32 characters in length.
this means we are sha256 hashing a 160 character password/string
i suppose i could improve that by generating a new user salt key & re-hashing the password each time a user logs in.
The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!
Password stretching
- 17/5/2011 23:38:48
- Madfish
Just thought I’d ask, does Impress already do password stretching? I just came across it recently and it looks like a simple way to increase the difficulty of offline dictionary attacks against password hashes.
Password stretching is just re-hashing the password a large (but fixed) number of times, instead of just once. The idea is simply to increase the amount of time required to calculate a password hash. If you rehash the password (say) 1,000 times before storing it, then a dictionary attack will take 1,000 times longer to run because the attacker must duplicate this process. Running an offline dictionary attack against a large number of password hashes (eg. if someone captures the database) suddenly becomes a much more time consuming affair. Maybe impossible, if you can crank the difficulty up enough.
Obviously this adds some overhead to the login process, but the level of difficulty could be set to whatever level people are comfortable with. The added delay to login might not even be noticeable to the end user. For example, nobody is going to notice an extra 0.1 second delay on login, but slowing hash calculations down to a few per second would severely impede dictionary attacks.
Worth a look, or am I already behind the times on this?
Re: The XSS Security Issue - How much of a risk is it in real terms?
- 23/12/2010 7:51:59
- skenow
Citaat:
Madfish wrote:
Should the download block be updated to version 1.2.4 or you got to install 1.2.3 and patch it?
Also, the system => version checker is still reporting 1.2.3 as the latest version. How does that work, by the way?
All the download blocks have been updated - thanks!
There is an xml file on the www site with the latest info in it - hadn't updated that, yet, but you should be good, now.
Re: The XSS Security Issue - How much of a risk is it in real terms?
- 23/12/2010 3:57:06
- Vaughan
did you update the system module?
The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!
Re: The XSS Security Issue - How much of a risk is it in real terms?
- 23/12/2010 3:52:26
- Madfish
Should the download block be updated to version 1.2.4 or you got to install 1.2.3 and patch it?
Also, the system => version checker is still reporting 1.2.3 as the latest version. How does that work, by the way?
ImpressCMS is a multi-language content management system for the web. It is community-built, an open source project and based on the common web technologies of PHP and MySQL.
Meer Info
