Are Often-Changed Long Passwords Really Secure? 233
Zweistein_42 asks: "I work at a large, navy-coloured IT corporation. A new, more secured password policy has just taken effect and will be strictly enforced: 8 characters alphanumeric, changed *every 90 days*, with standard checks for non-repetitiveness, dictionary, uniqueness, etc. Is there any research to support whether such requirements actually increase security?"
"I have almost a dozen applications I use daily (e-mail, VPN, Windows login, intranet, FTP, etc), plus 20-30 I access 'occasionally', and their passwords have to be unique - and change at different times. I usually take the trouble to memorize random alphanumeric, un-guessable combinations; but even I won't bother memorizing an average of 2 random strings a week. Eventually, won't most people use their pets names (fuzzy1cat, fuzzy2cat, etc) and start writing passwords on a note on their screen?
Every time I see such a policy, I strongly believe it makes *my* passwords less secure. What is the average user's reaction? What about lost & support time trying to regain forgotten passwords?"
You don't have to remember them all (Score:1, Informative)
You just set it, make the program learn it, and you're done. You don't _HAVE_ to remember them all.
Passwords can be saved on crypted files (not word please, as we all know that they can be cracked open in milliseconds), and your access to your corporate thinkpad can be granted at the BIOS level with the embedded fingerprint reader.
Go T42! GO!
cheers
Re:This is the reason (Score:3, Informative)
And the answer is... (Score:5, Informative)
I, like everyone else on the planet, work to make things easier for me and to hell with security. A new password every 90 days means people will design a password that passes the requirements but is easy to remember when you have to change it. For example, my last job required at least an 8 character password with at least two numbers and one case change, and you could not reuse passwords for at least 5 changes. So my first password was Th1s1smE. Anyone want to guess what my next password was after the first 90 days?
Anybody with half a mind (and you KNOW who you are) would run through the likely possibilities quickly enough.
My opinion: It would be better to provide a tool that would allow a user to rate a password which would let them come up with a password that passes a minimum quality requirement, a password that they could remember without writing it down, and then require it to be changed less frequently (like once per year). And, equally important, provide a second, different authentication mechanism to support the password security (a hardware token system would be one example, biometrics would be another, a prearranged "callback" mechanism would be a third, there are many others).
Beside, my experience with gaming a requirement like this is that users tend to mess up their password frequently and end up with their password set back to a known default (assuming the admins provide such a default, which in of itself is a very bad security decision). And so sometimes a policy like this will actually provide less security, because at any given time there will be a relatively high percentage of user accounts which are set to a known password. Years ago, I personally demonstrated this situation with one of the VP's of the company I worked for by going through the ID's of the senior managers until we found one using the default password.
So, long story short, changing passwords frequently does not automatically mean better security. But we all knew that, right?
Re:This is the reason (Score:5, Informative)
it's trivial to defeat - see here [ep.liu.se]
A few points (Score:5, Informative)
Changing passwords is ofcourse to reduce impact when a password is stolen/cracked. 90 days sounds a bit long -- is this policy based on evaluating what's *needed* or just based on vague assumptions ?
If it is expected that keyloggers, bruteforcing or some other form of password-theft is likely, 30 days might be more apropriate.
2.
According to various textbooks on computer security, forming a password from 1st (or some'th) letter in a sentence forms passwords which in general terms are as hard to brute-force as "truly" random passwords:
madly typing at keyboard: 32nfia.-!
I once saw four naked girls dancing in the moonlight: I1s4ngditm!
The latter form *may* be slightly more open to guessing the frequency of letters -- but bruteforcing a password with 12 alpha-numeric characters takes a *lot* of effort.
The main point is that passwords "generated" like that is *much* easier to remember. They may also be more "random" than just typing at the keyboard...
Some punctation and variations in capitalization should be encouraged/enforced.
3.
If you are authenticating against Active Directory -- just use pass phrases. Harder to bruteforce -- and prevents the ntlm-hash (16 chars, one case) being accepted by some braindead system.
4.
I personally think single-sign on is an important part of a good security strategy because it allows for more frequently changing of passwords -- admins would typically still need 2-3 accounts (normal user, admin role, testing role), but more managble than 10+
5.
Just because a password is written down does *not* mean it's compromised! If security really is so important that everyone needs 5 or more 8 letter "random" and uniqe passwords, I would *strongly* recommend that arangements be made for all passwords to be kept in escrow in a safe.
That way employees won't have an excuse to keep the password somewhere insecure. Everyone should be able to get their password during work-hours easily (for instance the receptionist that either knows everyone, or is instructed to _demand_ id, could have access to the safe).
The downside with any kind of escrow, is ofcourse, that one is forced to trust the few people with access to all passwords completly. This is a tradeoff -- but so are all security decisions.
6.
You mention bios boot passwords. Is that truly neccessary ? Bios configuration password sounds more reasonable to me. But either one is of rather limited use, unless you are using some form of fortified pc case.
If you do mean configuration passwords, that is a primary candidate for writing down, and locking in a safe IMHO. Normally all admins would have access to this, so that seems reasonable.
This can make things worse (Score:5, Informative)
Re:This is the reason (Score:2, Informative)
Read the packaging, there's a disclaimer: Do not use to protect anything you really care about.
Also, you should always remember that any use of biometrics without additional factors is for convenience-- never about security.
Re:Password Safe (Score:3, Informative)
For the Windows folks [sourceforge.net]
For the *nix folks [sourceforge.net]
Re:This is the reason (Score:5, Informative)
WRT to F/OSS, these are hardware devices. What you really need is a free reference design.
You could sorta fake it, but it wouldn't be the same. For example, suppose you kept GnuPG keys stored on a USB key fob. Then you encrypt the keyring with a simple password. Voila -- two factor security.
The only problem is that the key fob has to trust the computer it is connected to, because it is going to hand over the secret key to it. If they computer is compromised -- that's it.
What you really need is a device with its own computing power, such as an iButton. You then have software which sends a challenge from the server to the iButton, calculates a hash, then calculates another hash on that hash using standard password techniques. [maxim-ic.com]
The password of course would be very little addditional protection, but very little is needed. What you want is to buy a few hours of protection after you lose your device to notify the network administrators and get your account locked out.
PDA password keepers (Score:2, Informative)
My password app includes a utility to generate random but pronounceable passwords (which I don't generally use). My coworker told me one of these a year ago. I haven't used it in 9 months, and I still remember it. Oh $%^*, the system probably expired it.
Rainbow Tables (Score:4, Informative)
You can either spend a few months creating your own Rainbow Tables http://www.antsight.com/zsl/rainbowcrack/ [antsight.com], or you can buy the 64GB tables for $640, http://www.antsight.com/zsl/rainbowcrack/rt_price. txt [antsight.com].
Re:Desk (Score:5, Informative)
According to the site it can be used on Windows, as well as an older PocketPC version.
some actual research (Score:5, Informative)
That being said, here's at least one academic paper on the subject:
http://www.cs.ucl.ac.uk/staff/S.Brostof
An interesting quote:
"forced password changing causes password problems. The result was highly significant." followed by actual statics demonstrating the significance.
Here's a white paper that seems to argue that complex passwords only provide real protection if you're able to reduce the number of passwords needed (this may just be a marketing pitch for a single-signon product)
http://www.protocom.com/whitepapers/Eva
Most opinions that complex passwords and often changed passwords are more secure are probably based on the presumption that such policies increase the time required to crack a password:
http://scholar.google.com/url?sa=U&q=h
However, as far as I can tell, no one has really gone out of their way to scientifically compare the effective security provided by various types of password policies in "real world" situations like you describe.
Re:Don't mod this if you've never... (Score:2, Informative)
What you meant was "Don't mod this if you've never seen the movie Sneakers"
Uplink copied this from Sneakers, which you have apparently never seen.
Re:This is the reason (Score:2, Informative)
These are fine for many environments, but it worth remembering that a software app is always going to me less secure, and more dependant on the user for its physical and logical integrity, than a sealed hardware fob or card, the classic SecurID.
To actually use phones or PDAs or pagers with this token-emulation code to authentication against an RSA Authentication Manager (RAM, aka ACE/Server), you will need to buy the 128-bit seed from RSA. The RAM will only accept "seeds" digitally signed by RSA.