Slashdot Mirror
Are Often-Changed Long Passwords Really Secure?
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?"
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?"
As long as they don't check the post-it note under your desk - the password is secure!
But seriously, does a policy like this do anything but encourace people to write down their passwords?
Of course, it's kind of a single point of failure in terms of security, if you don't take into account the need to use a boot password and Windows login. Also, if your laptop dies... and you haven't backed up the password file...
verify me.
"Well Ranger Brad, I'm a scientist. I don't believe in anything." - Dr. Roger Fleming
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?
The NSA: The only part of the US government that actually listens.
Is the problem not that your password has very strict complexity requirements but that there are too many of them?
/. last month I posted 10 times" this fulfils all requirements for complexity and is changeable and easy to remember.
I did read a paper (I think from Microsoft not sure) about how passwords were essentially redundant as you could pre compute the hashes of all alphnumeric combinations and then run a dictionary attack against a file pretty quickly. They suggested a pass phrase as the way forward. Perhaps something along the lines of "I love
The other solution I often tell people is make your passwords a personal acronym, who would guess "Il/mIp10t" as a password, yet it is easy for me to remember.
The only reason some people get lost in thought is because it's unfamiliar territory.
1.
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.
I hacked my own together with a USB key containing an encrypted keychain and encrypted copies of my SSH key files. (Granted, I have no idea if a PC equivalent exists - my office lives in Mac-and-Unix-Land.) The keychain is backed up to another secure location every time I add or change a password, because the passwords I use look like what you get when you fall asleep on the keyboard. The USB key comes with me when I leave the computer, and the keychain get's locked automatically after 10 minutes in case I forget.
Not perfect, but it's better than post-it notes, and it does implement its own version of the "something you have and something you know" philosophy.
Honestly this whole password thing is idiotic. Companies are finally answering to the security risks of ten years ago. At this rate by 2010 they will be fixing sql queries based directly off user input. when it comes to cracking/stealing a persons password the best method now days is always to steal. It doesn't matter if your password is 3 pages long if you give it to me I will be able to log in as you. strong passwords are only as good as the minds of those who use them. Add to that the fact that the longer and more complex a single password is, the more likely the employee is to use that password in multiple places. Lets say I want access to a companies VPN, even if I don't know how strong the passwords are, connecting and trying a bunch of easy ones would be pretty dumb. Instead 5 minutes on google will tell me the name f Joe Blow who works there, what his email address is, and a whole bunch of things that he is interested in. So I email Boe Blow with targeted spam, tell him about this amazing new website that just happens to be a community of people with exactly the same interests as him. He goes there and finds out that he needs to set up an account to view the forum. So he has this 10 page password from work that he has already memorized anyway (he wouldn't want anyone breaking into his forum account) so he goes ahead and puts it in the password field. Turns out the forum kind of sucks so he promptly forgets about the site. TADA VPN access, and it only took 20 minutes. This works more than 50% of the time, and the average company has a few more than 2 employees. Watch 90% of the people who see this change their slashdot passwords. :)
Crawl This - http://darkry.net/test/test.php
Well, one of the reasons. Two-factor authentication was defined (as I recall, by the US Bureau of Standards in the mid-70s) as any AAA system that requires presentation of two of the three factors (something held, something known, something one is), but there was originally an additional requirement: one of those factors must be resistant to replay, dynamic.
Sniff and replay were then, and in many places still are today, a prominent security threat -- and that threat grew exponentially with the evolution of local nets, and then exploded in scale and volume with the Internet.
The SecurID, or any One-time Password (OTP) used to provide "strong authentication," does indeed obviate the need for all the Draconian rules now used to buttress the static reusable password or passphrase. In '87, however, as the SecurID was first brought to market, we never thought the static password would survive, no matter how complex it became, because it had none of the inherent resistance to eavesdroppers provided by a dynamic password.
We never dreamed that -- to save, per user, the price of a keyboard -- the corporate bean counters would stay committed to static reusable passwords for another 20 years, using these increasingly painful routines to make those passwords more resistant to guessing, dictionary, and now pre-computed hash attacks. Nor did we expect that the market would consistantly undervalue one of the token's core virtues: its resistance to sniff and replay.
We thought it was obvious that a password, however strong, could never be enough.