Schneier on Security
A blog covering security and security technology.
« Removing Belts at Airport Security |
| Bulletproof Service Providers »
November 11, 2010
How often should you change your password? I get asked that question a lot, usually by people annoyed at their employer's or bank's password expiration policy: people who finally memorized their current password and are realizing they'll have to write down their new password. How could that possibly be more secure, they want to know.
The answer depends on what the password is used for.
The downside of changing passwords is that it makes them harder to remember. And if you force people to change their passwords regularly, they're more likely to choose easy-to-remember -- and easy-to-guess -- passwords than they are if they can use the same passwords for many years. So any password-changing policy needs to be chosen with that consideration in mind.
The primary reason to give an authentication credential -- not just a password, but any authentication credential -- an expiration date is to limit the amount of time a lost, stolen, or forged credential can be used by someone else. If a membership card expires after a year, then if someone steals that card he can at most get a year's worth of benefit out of it. After that, it's useless.
This becomes less important when the credential contains a biometric -- even a photograph -- or is verified online. It's much less important for a credit card or passport to have an expiration date, now that they're not so much bearer documents as just pointers to a database. If, for example, the credit card database knows when a card is no longer valid, there’s no reason to put an expiration date on the card. But the expiration date does mean that a forgery is only good for a limited length of time.
Passwords are no different. If a hacker gets your password either by guessing or stealing it, he can access your network as long as your password is valid. If you have to update your password every quarter, that significantly limits the utility of that password to the attacker.
At least, that's the traditional theory. It assumes a passive attacker, one who will eavesdrop over time without alerting you that he's there. In many cases today, though, that assumption no longer holds. An attacker who gets the password to your bank account by guessing or stealing it isn't going to eavesdrop. He's going to transfer money out of your account -- and then you're going to notice. In this case, it doesn't make a lot of sense to change your password regularly -- but it's vital to change it immediately after the fraud occurs.
Someone committing espionage in a private network is more likely to be stealthy. But he's also not likely to rely on the user credential he guessed and stole; he's going to install backdoor access or create his own account. Here again, forcing network users to regularly change their passwords is less important than forcing everyone to change their passwords immediately after the spy is detected and removed -- you don't want him getting in again.
Social networking sites are somewhere in the middle. Most of the criminal attacks against Facebook users use the accounts for fraud. "Help! I'm in London and my wallet was stolen. Please wire money to this account. Thank you." Changing passwords periodically doesn't help against this attack, although – of course – change your password as soon as you regain control of your account. But if your kid sister has your password -- or the tabloid press, if you're that kind of celebrity -- they're going to listen in until you change it. And you might not find out about it for months.
So in general: you don't need to regularly change the password to your computer or online financial accounts (including the accounts at retail sites); definitely not for low-security accounts. You should change your corporate login password occasionally, and you need to take a good hard look at your friends, relatives, and paparazzi before deciding how often to change your Facebook password. But if you break up with someone you've shared a computer with, change them all.
Two final points. One, this advice is for login passwords. There's no reason to change any password that is a key to an encrypted file. Just keep the same password as long as you keep the file, unless you suspect it’s been compromised. And two, it's far more important to choose a good password for the sites that matter -- don't worry about sites you don't care about that nonetheless demand that you register and choose a password -- in the first place than it is to change it. So if you have to worry about something, worry about that. And write your passwords down, or use a program like Password Safe.
This essay originally appeared on DarkReading.com.
EDITED TO ADD (11/14): Microsoft Research says the same thing.
"The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis."
Posted on November 11, 2010 at 6:45 AM
• 90 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
About the first remark, that people will take easy-to-remember, easy-to-guess passwords: I always use the same hard password where the last character changes. For the bank, it is a new password, for me, it isn't.
It would be great if IT auditors would be informed by reasoned discussion by recognized information security experts. Anybody have any thoughts on how to move us in that direction? Enterprises waste money and user attention on things that don't matter, often just to satisfy an auditor so they can move on to their next tasks. But then the auditor and everyone else notes a "best practice" since so many enterprises have taken the same needless steps. I'd be glad to hear thoughts on how to unwind that yo-yo.
Excellent points, especially the counter-intuitive advice to *not* change passwords frequently. Some companies I've worked for haven't understood that the results of requiring monthly password changes and prohibiting password reuse are that either passwords are written down in insecure locations or the same password is used repeatedly with a memorable suffix.
OK comic on reusing the same authenticators at multiple sites.
(stupid owner="me")I think most most people will never care about security until after they get their posteriors chewed off. If I could set up a working single sign on site for the web I could probably have more working site/username/password sets than I could ever reasonably use. If I could get such thing working and sufficient hosting, It'd probably be easier to estimate the number of sets the site didn't have.(/stupid)
My guess is that the main reason why many companies want you to change your password regularly is because their operating systems has a "password policy" function.
They don't know what settings to use and why they should or shouldn't use some settings but they set something.
What are people's thoughts on using the same password on multiple sites? My passwords for banking sites are always unique, but for less important sites I use the same password for many.
Recommendations are to use different passwords for sites that matter.
Of course, this means that Single Sign On or SAML is a bad idea as well ;-)
Different security domain (which pretty much is the case for what you probably mean by different sites), different passwords.
Note that many sites require an email address and will mail your (possibly a new one) password to that address. So you don't really need to care to much about forgetting passwords for such sites.
@AppSec, Single signon often involves a trusted third party as the only party actually handling the password. So Single Signon in that case does not really suffer from the bad properties of a password shared across multiple security domains.
@Terry -- Nothing wrong with reusing passwords across sites, as long as you can afford to (potentially) lose control of all those accounts if any one of them is compromised. I wouldn't feel bad using the same password for both Slashdot and BoingBoing, for instance. I think I can survive the loss of both accounts if either is stolen.
Personally, I like using SuperGenPass as a password manager. It hashes two strings together (typically the site's domain name and a master password which you provide) to generate a unique password for every site. These passwords never have to be stored anywhere, since they're generated deterministically. You just have to remember one password and you get the benefit of a unique strong password for each site. You're still vulnerable to someone finding out your master password, of course, but the risk of that is relatively low. (If you're really paranoid, don't use the bookmarklet to generate the password; generate it in a separate window and copy/paste it in.)
@Not Really Anonymous
Maybe ten years ago, that was okay. If a site can mail your password, then an online vandal can obtain that password from them. So as you note, different sites, different passwords.
Using Password Safe, Keepass, KeepassX, or Password Gorilla, you can afford to have a different, unmemorizable password for each site. Otherwise, you'll use your Yahoo or Google password on that online gaming forum site. When someone captures that database, they'll have both your e-mail and password.
Someone who steals your banking credentials might not use them instantly but rather sell them in bulk. Someone else will use them some time later.
So if you change your credentials during that time, you thwart the attack.
@Deke - "I'd be glad to hear thoughts on how to unwind that yo-yo."
Sorry, I don't have any solutions for you, other than if you're lucky enough to have an upper management level that truly understands IT security. As someone who performs an IT security audit role for one firm and an IT security manager role for another, I see the same story played out again and again. IT auditors that simply go down a checklist without understanding the principles behind that checklist, and upper management spending all kinds of time and money to meet a regulation without understanding how that effort could be leveraged to both meet the reg and truly better the security posture.
Amen to that, Bruce! It REALLY irritates me that my business bank (but not my credit union) requires that I change my password regularly - my password consists of personal factors that are ONLY known to me plus terms from a 2000 year dead language. The possibility of someone (or computer program) "guessing" my password(s) is minute, yet they are easy for me to remember. The more sensitive the account (Linux forums vs. bank/trading accounts) the more complex a password I use. Requiring that I change them regularly is an unforgivable imposition, IMHO.
The advice "But if you break up with someone you've shared a computer with, change them all." applies to corporate passwords as well -- if an employee leaves, any shared 'role account' passwords (e.g. root) that they COULD have known must be changed immediately. This is a hassle, but doesn't mean such a draconian password policy is bad (it does mean shared accounts are bad!).
I disagree that a corporate password change policy is just security theater. It's good to have a regular change interval for passwords in a corporate environment because cow-orkers often learn other employee's passwords, inadvertently or otherwise. Forcing corporate account password changes quarterly is, IMHO, a reasonable policy to address reduce the risk from this, especially the risk from ex-employees gaining access by using the credentials of people still with the company.
Part of the issue with passwords exists because the name itself implies the string is a word. We all know dictionary attacks make short work of that approach.
The ideal NIST standard of upper and lower case letters plus numbers and symbols and a decent 'random' generator is part of the answer however any string of 8 such characters is already vulnerable to re purposing the Nivida card with a brute force crack algorithm.
I've switched to a piece of software of my own design that generates one-time use, 32 character random strings for NIST level security. Of course, it can be argued that's over kill but by design the user interface is unconnected to the passcode itself so a user doesn't need to be concerned with the complexity of the string 'under the hood'. In essence the access challenge is based on an entirely different, easy to use and totally unrelated mechanism.
I'd caution in my experience any repetitive format password system that can be analyzed can be deciphered. Saying there are levels of sites or applications where some are irrelevant and supplying a password is simply tedious is exactly what leads to careless, repetitive patterns which very likely allow a motivated individual to try the same weak approach on your serious accounts. And surprisingly, nefarious folks use this to gain access more often than not.
The truly sad aspect of this is the number of major institutions and applications so phenomenally clueless they permit users to think they are secure using a six letter password: rudumb
in addition, I am constantly urging my friends and family to have and use at least 3 distinct and dissimilar email accounts:
tier 1: trusted financial matters,
tier 2: family, trusted friends, and less trusted financial dealings (most online non-bank merchants), and
tier 3: social networks, risky online merchants, and new or unknown people.
corresponding password strength for each. you can have my third-tier password, but it won't help you at all to get at my good stuff. and unless my brokerage or bank leaks, you'll never even guess my first-tier address.
I also have two tiers of browsers, one set for normal surfing, and another set that only visit go to 1st or 2nd-tier sites, nowhere else.
It isn't foolproof, but is another layer in my risk management practices.
First my usual comment about passwords,
"Why on God's little green apple are we still using 50year old ideas that where bad 50years ago?"
Single Sign On by the way is a bad idea, there is no such thing as a "trusted third party" especially when it comes down to Hey Mr CEO I'm Judge Hangem, if you don't reveal the information this LEO wants you are going straight to jail until without contact with anyone until I decide otherwise...
As for auditors what can I say the recent PCI thing with "yes you passed audit but you've been hacked therefore you've failed audit" kind of tells a story.
As for best practice "Oh please give me a break". It is a joke based on a very poor understanding of security in the information world. It works like this,
1, Set up an industry wide body.
2, Send a questionnaire out to your members that asks "have you been successfully attacked".
3, Go around and do a puff piece interview with the ten most prominent organizations that said the had not been successfully attacked.
4, Distill out the ten things in common that they say they do.
Can you spot any problems with this like,
A, Why should they tell the truth?
B, How do they know an attack has not been successful?
C, Have they even been attacked?
I always wondered about this, I play an MMO and any time there is a rash of hacked accounts the message is the same: blah blah blah, change your password frequently...
I think to myself, if they get my password they aren't waiting till after I change it to do stuff, they will go on right away, sell all my stuff and mail my cash off to their accounts. Pretty sure I would notice that, and change the password afterward, and try to scrape together my lost stuff.
I don't fault my employer for enforcing a one year retention, because of corporate spies, but as you said, back-doors are easy to construct in a one year time-frame.
One reason not mentioned here for corporate policies that force frequent change of passwords is that it creates an easy income for the hotline that helps when the password is forgotten.
There seems to be a lot of confusion - especially about requirements for password complexity...
But passwords really fall into 2 categories :
- Access control passwords
- Encryption passwords
For access control passwords, requiring utterly complex passwords is IMHO pointless. Password verification is always performed remotely, so how much processing power (like a CUDA application as previously mentionned) you have or method you use (directory attack) is moot - because, in the end, the password is verified remotely. Any decent access control mechanism will raise a red flag when excessive attempts are made and you can remedy at this point. Also, access control mechanism will tend to slow down verification after some time which will also mitigate the risk.
For encryption passwords, it's of course a little bit different. But first, the party attempting to determine the contents must first gain access to the encrypted data. But assuming this happens, of course it can run a dictionary attack or a brute force attack... Now, at this point, if it gets that critical - that's probably not the best option. see : http://xkcd.com/538/
Complex passwords (upper, lower, numbers, and symbols) can be difficult to remember. On systems that support long passwords, pass-phrases that are easy for the user to remember are far preferable. A 16 character pass-phrase consisting of 3 english words all lower case contains approximately 60 bits (1M words ^3). Even if you consider that the average person has a vocabulary of only about 64k words and abbreviations, that's 64k ^3 = 48 bits for 3 words. An 8 character upper, lower, number, and symbol password, which has just under 53 bits (assuming 96 printable ASCII characters), and unless it's truly randomly generated, it has predictably less than 48 bits.
That ranges from potentially a little weaker than to notably stronger than an 8 character "strong" password. However, the pass-phrase will be significantly easier to remember than a nearly random string of 8 characters. If you consider that there may be non-english words, some capitalization, and some numbers or symbols mixed in, a 16 character pass-phrase is easily 64-80 bits and can approach 100 bits. Longer pass-phrases are of course better, and arbitrarily long pass-phrases can still be easy to remember.
Here's more info and research on sane password policies.
If you're gonna age passwds, then those passwds should have ages dictated by their strength. Weak passwds prohibited, mild passwds have shorter lives, strong passwds have longer lives, and impenetrable passwds never expire.
impenetrable = >=16 characters, mixed case, digits, punctuation, and passes multiple dictionary attacks.
Can someone tell our IT department! Password ageing on Windows, Unix, Linux and SAP systems means that I have to maintain nearly dozen passwords that change every couple of months.
The only way to maintain all these passwords is to write them down...
They never listend when I said they should have good passwords not short life passwords.
Credit card expiry dates act as a secondary verification attribute, supplying 5 or 6 bits of security (12 months times 3-5 years). Not enough to stop a hacker from using a card but enough to stop them from using it at specific sites requiring it. Also useful for card-present fees (although the the CVV number on the back is better, but not all sites use this).
I developed the password policy for a large company (120k+ users) and often come under fire for the password change requirement. The reasons for it are not always obvious because we have several different authentication infrastructures.
The reason that I mandated a password change every 30 days was because I found out that it is possible with Lotus Notes for an ordinary authenticated user to download the HTTPpassword field from the NAB (directory) by saving it as a TXT file with the Notes mail client. It is usually hidden (obscurity anyone?) in standard views but not when saving an entry as a TXT file. I also discovered that there was no salt in the password crypto algorithm (we're talking the old R6 release here, some years ago). The result was that I could get all the hashes and crack 40% of passwords with no special access required. Another bright feature in Notes was that the HTTPpassword hash was displayed like "(password)" and if a user chose a password that began with "(" the system assumed it was a hash (already encrypted) and stored it as is (ie. plaintext) for all to see (if they downloaded the NAB as a TXT file).
To cut a long story short I instigated a series of control measures which included an upgrade of the Notes hash algorithm (the secure algorithm is now the default in Notes) and a password change policy to flush out the old hashes.
When the flush was complete we changed the password change to be every 90 days.
I have found the password change policy to be useful in flushing old hashes from various directories over the years, eg. NTLM v1 and Unix crypt.
Unfortunately auditors often pay more attention to the letter of the law rather than the reason for its existence.
I think the advice to not regularly change your financial password because it's not good prevention is disingenuous. Consider this. I am a dumb user and I use my bank password on other web sites. Next year somebody hacks one of those other websites, gets a list of email addresses and passwords, and tries them all on various popular sites, including perhaps citi.com (lots of people must have citibank cards, e.g.). If I have not changed my password in a year, I'm toast. If I have changed my password, I'm saved.
"If you have to update your password every quarter, that significantly limits the utility of that password to the attacker."
If the password thief used a keystroke logger, he'll just snag your new password. If he cracked someone's security to steal passwords, he can do it again. If he copied the complex password you wrote down, he can do that after you write down your new password. Or, if you use a systematic way of changing your password*, he can guess at your system.
* Example: MyPassword1& will probably be replaced by MyPassword2&
Just because it's too good to forget:
Most people use passwords. Some people use passphrases. Bruce Schneier uses an epic passpoem, detailing the life and works of seven mythical Norse heroes.
I completely disagree about not changing your passwords regularly. The most prominent attacks out there involve the bulk compromise of machines through a scripted attack and the harvesting of data (passwords, PII, etc.) to a centralized source. This information is then packaged up and sold off. The targets of these attacks are banks, online merchants, personal computers, corporate computers, etc. Changing your passwords on a regular basis helps mitigate the risk here. I doubt that anyone, Bruce included, is 100% certain on a day to day basis that their PII or password data is secure. Regular password changes limit one's exposure and should be considered good practice. More intelligent password management programs make this process much less painless than walking through it manually for every account that you have.
"... Bruce Schneier uses an epic passpoem..."
Which rarely can be used because most password fields have character limits. Some of the internet sites I visit allow only 12 characters for passwords. I've rarely seen any computer security system that allows more than 40 characters for a password.
Bruce: I did not get the reason for changing corporate passwords.
After all, if an attacker gets access to my corporate account, then she can occasionally run her own "password update" script to get me to change the password to something she knows, and then immediately update the real password to it. Alternatively, as you said, she can install a backdoor, etc.
In terms of attacker guessing my password, as you noted, updates only make it easier.
So, the only rational reason I do see for this, is that people might "leak" their passwords - e.g., when on travel, a person might tell his password to the secretary/colleague/spouse/etc to access some urgently needed files (he should change the password after that on his own, of course, but might neglect to do so).
Am I missing something?
Many online sites have scripting to prevent pasting passwords into the edit controls; this can also be found in standard console applications (and of course, both require you to type the password twice). This sort of "security" thwarts the whole "secure password I copy in" approach, and is one of the things which would virtually guarantee that I used my "low security" password for the site/app. In a similar manner, policies which require regular password changes beg for algorithmic password incrementing, and I'd guess that happens in at least 90% of the cases. A more general statement of these two special-cases might be that "bad" security policies lead to bad password security.
Bruce, may I direct you to this:
A Microsoft researcher even says that a rotating password policy -- which can be done easily in their own Active Directory -- is a waste of time. Is this not what you call Security Theater?
To echo kevinm and MattB above: I recall from reading about security in the ancient days of the mid-1990s that the original reason behind password expiration was the possibility of the encrypted password file (/etc/passwd or the equivalent) being copied. Password expiration was to avoid giving an attacker effectively unlimited time to break the password encryption.
Of course, far more effort now goes into protecting the encrypted passwords, so if an attacker has the modern equivalent of /etc/passwd then you've got a lot bigger concerns than the time window until users change their passwords.
There is an aspect to passwords that people tend to forget longevity.
This happens with passwords that are used on accounts that may not be used for a considerable period of time.
Often it falls back to the "secret question" or Email to an account you likewise have not used in ages and cannot remember the password to either.
For important accounts for which there is no "human access portal" (becoming more common with banks) such as a help desk there should be some mechanism by which you can prove who you say you are bit by bit.
I know of a couple of people who where "suddenly downsized" who had mad the mistake of using their work email address (opps) the result was in one case they lost control of an account and had to jump through hoops and loops just to get it shut down and then through another long drawn out process just to get their money back...
In the final remarks there was a recomendation I like. Always have 2 paswords, one for the sites that matter, and one for the sites that don't. The one for the sites that matter should be very difficult to crack. You will be logging often and remember the password always. The one for the sites that don't matter should be simple. You will be relaxing your security with these and if you forget the password you will be trying a lot of passwords you have used before. If someone is keylogging you, you have given them a dictionary of the passwords that really matter.
Dirty Davey - as far as I know - /etc/passwd contains the one-way hash of each password, it is not possible except through brute force to "decrypt", if you have root/physical access you can blank it out. I use what I think are easy to remember but hard to guess passwords for important stuff, some numbers, some common words with punctuation between each word and a capital in some words, then another set of numbers. Who is going to guess that?
I work in deskside support. If you have a 90 day password expiration period, that is 4-5 weeks a year where everyone is carrying around little scraps of paper or leaving password on sticky notes on their desks. Not only does this increase your helpdesk requirements, it also increases the ease and likelihood of someone (accidentally or intentionally) learning passwords.
Focusing on password expiration tends to cause people to miss critical security errors (e.g., logging into your bank account from a hotel lobby computer). It also goes along with the obsession with 1950s-era "secret questions" whose answers can frequently be found by a simple Google or Yahoo search. And it dissuades people from changing passwords when they suspect that someone else may have obtained their passwords.
That last sentence should really be first. "Use a program like PasswordSafe."
It really does make a lot of those other problems go away.
Changing passwords regularly is saver than using the same password everywhere forever. But humans will forget regularly changing strong passwords.
So should we adapt the users to the system? Or the system to the user?
It's not only important to pick a mathematically secure password, but it's also important to store that in a place that cannot be easily accessed. If you make strong passwords but store them in a text file on your computer, you may have a problem.
A recent example is a malware that was stealing FTP passwords from common FTP programs. Those passwords could have been 100 characters long and it wouldn't have protected you.
Save your passwords somewhere secure like a password safe.
Every other week, always 63 character length generated on a one-time use site and never entered by keyboard. Not a software solution either.
I would be curious as to your opinion of my favorite solution "PasswordMaker";
It generates a password from your Master Password, the domain, and one of several hash algorithms. Is this actually a good Idea, or do I merely *feel* safe with this?
We had a system that forced password changes every month, and kept track of 13 prior passwords. Led to passwords looking a lot like jun2001, jul2001, aug2001, etc.
Actually I think that forcing users to change their passwords doesn't really improve security and it may well decrease it.
Good passwords are hard to memorize and if I'm forced to change it every few months then I can do two things: change it as little as possible (e.g add a number or a character at the end and cycle between them as allowed) or use a weak password (and maybe do the same with it).
Now if one has a lot of accounts and passwords and tries to be safe and use an app like passwordsafe then the ignorant service operators who force frequent password changes can turn life into a really bad experience forcing us to do password changes every few days on one system or the other (or just force the user to give up on secure passwords).
For some time, I have thought that what is really needed for remote authentication in particular is a better password checker. We have password checkers that check for uppercase letters, lower case letters, numbers, and punctuation, but this only tells us if a pure brute force method will work. Many of the world's most common passwords will pass these checkers, but fail in the real world. A hack at an employer of mine hacked hundreds of passwords that were plenty strong enough in that sense, but weak because they were things like "OurBusinessName#1!".
My full suggestion is way too long for this post, but it basically consists of comparing their password to a list of the 10,000 most common passwords known to be in use today (updating the list is an exercise for the reader :), comparing it to the most pertinent information about the password user for partial matches ("myname45", for example), and lastly doing comparisons to pieces of the URL, business name, and similar identifiers of wherever they are logging into, so as to catch "Comcast#23" and "Bruce#1Schneier".
Sure, the comparison may take a few seconds to minutes, especially if you are really thorough with the personal information, but why shouldn't a password test take five minutes, if it gives you a far better password?
One exception to the above would be your wireless router WPA passphrase. It fits very much into the passive abuser scenario.
The biggest PIA password expiration date policy that I experienced at a corporation was 30 days! Hey guys, why not make it 31 days? Change your password every month!
Their policy prevented recycling the past six passwords so that eliminates names of pets, kids, etc.
The argument appears to be, if the password is hard, then password expiration is a bad idea.
So why not measure the hardness of the password and then set a expiration date based on that. This would give folks an incentive to build hard passwords, which is what we really want anyway.
@Terry - Someone already commented that it is okay to use the same password for multiple sites as long as you don't mind the possibility that if one gets compromised, they are all compromised.
That being said, what many people don't consider is that being compromised doesn't just mean being hacked. One simple question most people probably don't think about is how do you know the web site is storing your password in a secure/encrypted state? I would bet there are a lot of sites, especially smaller sites, that store passwords in plain text. So if you use the same password on multiple sites, you could be telling the developers of that site your credentials for other sites, no hacking required.
What's even worse than password expiration is sites that LIMIT the available character set. Some say "no punctuation". Some allow only certain punctuation characters. On occasion I see "no spaces". And these are high-value sites! The cluelessness here is unfathomable. Not only does such a rule force the user to use a less secure password than they would prefer, it throws a real wrench into password generation systems, both mental and computational.
I suspect that what's going on is that these passwords are winding up in strings that are passed around inside the Web app via Unix shell commands, or something similar. This is, of course, no excuse at all. Have these people never heard of hex encoding???
The standard practice should be to allow, not just any printing ASCII character (plus Space) -- that should go without saying -- but all of Unicode.
"It generates a password from your Master Password, the domain, and one of several hash algorithms. Is this actually a good Idea, or do merely *feel* safe with this."
I don't know of the system you mention, however from what you say some things can be said.
Firstly a hash function is not a maker of entropy it just spreads what there is around a bit, each time you apply it. However it has the advantage of being effectivly a one way function (if it is any good).
The downside of a publicly known hash function is that there is no secret added to the mix as with a public encryption algorithm.
Thus it is important to know how the master password is mixed in as the domain name is public knowledge.
One method to mix the master password in is to "whiten" it by exclusive oring it with another secret random number used as a salt.
That is you use the service domain name to generate a pointer to a table that is populated by random numbers. The first random number pointed to then gets exclusive ored with the master password, this gets hashed and the output from the hash then gets exclusive ored with the next random number and hashed again etc. The actual form of the hashing can be a chain or other structure such as a Fiestel round.
The final output from the mixing process is then used to generate some kind of usable plain text to use as the password.
However there is a problem with this final process humans are fairly lousy at copying a string of realy random charecters so it is better to use the random number to generate nonsense words seperated by numbers or punctuation charecters.
The form of the nonsense words are VC, CVC, CVVC, CVCVC, etc where C is a consonant an V is a vowel.
@ Doug Williams,
"So why not measure the hardness of the password and then set a expiration date based on that. This would give folks an incentive to build hard would give folks an incentive to build hard passwords, which is what we really want anyway."
It sounds like a nice idea the only problem is how do you decide what is and is not a hard password.
For instance "thecatsatonthemat" is most definatly not a hard password as it is a well known piece of plain text.
But what if it was "7h3c475470n7h3m47" superficially this looks like a hard password although a human can quickly see that the onl difference between the two is numbers have be substituted for some frequent letters.
That is humans can see through simple obsfication such as substitution to the underlying pattern which computers are not so good at.
However if I took,
and modified it via a simple rule to
Then it would probably pass as a hard password to both a human and a computer.
(the simple rule put in groups of three and add the group number starting at 0 to each char in the group mod it's alphabet size. So cat became c47 under the first rule and as it was group 1 became c+1=d 4+1=5 7+1=8 "d58" under the second simple rule).
The point being when does known plaintext become under simple rules a hard password and importantly why.
The worst I have seen are those places that limit the length of passwords.
My credit union upgraded its security to require a second password to transfer money to someone you havent transferred money to before (which is a good thing). They also require inputting the password via an onscreen keyboard to help thwart keyloggers. But they limited the length of the password to 10 characters.
Thats poor security practice IMO.
I like the idea of single sign-on: a single master password grants access to one's other, unique-for-each-site passwords which can be as random and meaningless as one wishes.
Personally, I use LastPass, which works pretty well. One has to trust that they're unable to read one's passwords (and that's a personal choice, naturally), but for me, I'm more concerned about bad guys gaining access to my accounts than LastPass going rogue (as doing so would destroy their business model).
I like the fact that they do time-delay account lockouts when the wrong credentials are presented a certain number of times.
LastPass offers multi-factor authentication, which is also nice: if I access my account from a trusted computer (e.g. my desktop at home), I need only enter my username and master password. If I (or a bad guy) try to access my account from any other system, they need to know four randomly-picked coordinates from a grid that is randomly generated and known only to me and LastPass. The grid exists only in my wallet and in LastPass' records. (If I lose the grid, there are means of retrieving it, but that's even more of a hassle for a bad guy.)
I know there's risks to storing such information online, even if it's stored securely and the decryption is only performed locally, but for my needs it works excellently.
Disclaimer: I have no relation with LastPass other than being a user. I have no interest or stake in the company.
You can tell whether you need to change a password by the likelihood that it will become known by others.
The more unique and unlikely to be discovered, the less it needs to change. The more it has to be shared, especially for business purposes, or exposed to insecure communication channels and systems the more often it should change.
The economics of password management also should be considered; there is a cost burden on password recovery systems and helpdesks when changes are more frequent and more complicated.
Changing passwords is a security relic to me, like castles. It was an important control for shared accounts; shared accounts used to be prevalent but are far less needed now.
A mail service, for example, used to mean you had to give a password to any representative of the service and not just a single person (sick days, firings, holidays, etc. guaranteed a password would be shared). Fastforward and technology enables identity management systems to distribute unique and individual passwords that need not be disclosed and therefore need not be changed (as often).
A good online password manager is clipperz.com
However, it is better to install the community
Edition locally if you are paranoid about
Not storing your passwords online.
The nice thing about the tool is that it can
Generate strong passwords for you. And
There is an option for an offline copy which
You can carry around on a USB stick.
At my work I have 8 different passwords the shortest lived one only lasts 4 weeks and can't repeat the last 6. All have different rules for strength ranging from none to Draconian. I spend 1 morning every month trying to get them all in sync, (except one whose rules contradict the others) BTW they have the strangest dictionary ever as I get errors "Dictionary contains parts of password please try again." for combinations of symbols that look random to me.
Of course when I finally get one that works I write it down on a post it note and hide it somewhere on my desk like everyone else.
I work for a company that requires a rather long password, special characters, and it sophisticated enough to recognize-and disallow-new passwords with only 1 digit changed. So I use a formula for my new passwords. I use the same special character and specific number/letter substitutions. When the password request comes in, I select an obscure character name from whatever book I'm reading at that moment, conver the number/letters, add my special character and I have a super secure password. As someone who reads 60 books on average in a give year, you'd have to know every book I've read, figure out which character I'd select, then crack my number/letter substitutions. But in the end, I never have any trouble remembering my new password!
@bart - that's weak. Any passwords cracked I assume are reused as prefix/suffix/other mutations on other sites.
I gave up a more elaborate scheme based on the website name long ago (hopefully 1 wouldn't reveal the pattern, 2 or more likely would to a clever attacker).
One-Time Passwords is the only solution that makes sense (with time synchronization in the 5 mins range -and no-replay IVs, this is perfectly viable).
It does not exclude a password / passphrase to protect your secret key (USB key?) against theft.
In which case what you have to remember can afford to be weak from a security point of view because its goal is merely to pollute the perfect security used BEFORE it.
The only real question is why things have not been designed this way -the proper way.
I like passwordcard.org as one solution - an encoded hard copy. I imagine I'll use it a lot once I start working in a corporation.
@wh1968 A few years ago I did XP desktop rollouts at a company that requires a rather long password, special characters, and it sophisticated enough to recognize-and disallow-new passwords with only 1 digit changed. I can confirm that your approach is an exception, generally if the user was not present the password would be on post-it note (a) in the top drawer of the desk (b) under the keyboard (c) my favourite... taped to outside of the laptop.
Although this approach may have made the systems less secure, it made my team's job much quicker. How unusual it is for a security requirement to have that effect!
I've always found that writing passwords down is pretty useful - and if done correctly pretty safe...
Of course I don't write the password itself down but the other way around; I generate a bunch of long password strings (using something like "pwgen -y -s -1 80 50") and print the result. That's the writing down part. The resulting paper can be left in plain view if necessary, and each actual password is found somewhere on the printed page. Pick a spot that you'll remember (there's always something that catches your eyes) and then move left, right, up, down or diagonally if you like, in as many steps as you want or are required to, accumulating characters for the password along the way.
Each password is as secure as they can be because it is using all types of characters chosen truly randomly, and you don't have to remember the entire password, just remember the starting spot and direction. There's an almost endless number of possible passwords so even if you're required to change the password often, you'll have no problem, and you can always just generate and print a new page if you feel you're running out of memorable patterns.
If someone throws away the paper... Well, unless you saved a copy elsewhere you'll need to have your sysadmin reset the password for you, but at least it wasn't compromised... ;)
My bank has a good policy. Every time you attempt to login from a different ip address you're prompted with a security question.
The security questions are quite clever too, not Googleable stuff like "what's my pet's name".
Passwords always generate a storm of opinion. IMHO this is because it is a simple concept that interfaces with multiple, complex, issues.
Passwords are ONE part of security. The majority of breaches (IMHO again) bypass the authentication process because there are normally easier to exploit vulnerabilities (SQL for example).
Password weaknesses are also often stated independently of how they are used - yes you can brute force the hashfile but that is no help at getting past the web interface.
One other thing that intrigues me is how there is frequent confusion over what makes a strong password policy (as opposed to a specific choice of password) and when this should be implemented. For example, there is a different requirement for how I authenticate myself to my phone vs my bank.
It is important to decide what attack you are defending against when creating a password policy. Online guessing attacks should be detected and blocked, albeit, this is hard to do with distributed attacks. But those should also be detected, and whitelists of allowed ip addresses should be used.
On the other hand, if an attacker can steal a password file and mount an offline attack, any short (16 characters or less) password can be brute forced. However, this implies that the system has already been cracked, and should be rebuilt with all new passwords.
And, by far the biggest threat is impersonation arising from hacked computer, so hosts must be on guard for impersonation using the correct credentials. One-time passwords can defend against this, but existing sessions can still be hijacked.
So in conclusion, many organizations penalize their users with unnecessary password changes because they are not properly detecting attacks.
"Passwords always generate a storm of opinion IMHO this is because it is a simple concept that interfaces with multiple, complex, issues."
Yes and no, part of the problem is the history of passwords.
As many in the military know passwords started from the chalenge "Halt who goes there, friend or foe?"... "advance one and be recognised". This challenge-response procedure then proceads to a supposadly covert wispered password phase where the challenger whispers the first of a pair of words to which the chalenged person should reply the second or get shot / disarmed / apprehended / etc.
The whole point of the word pair was that they where easy to remember and have a life of no more than a guard / sentry shift or the time a roving patrol was due to be out.
As such they are low tech and if (and only if) carried out correctly relativly safe procedures.
The problem is most times they are not carried out correctly (ie the chalenger is not backed up correctly / more than one potential enemy aproaches / the word pair are not wispered / etc).
These problems occure because those involved don't understand why things are the way they are and the implications of not doing the steps correctly (such as the sentry may end up very dead as will some of his comrades).
The computer password system which is derived from this challenge-response system suffers from exactly the same self problems and then a whole bunch on top.
The reason actually started with laziness by humans which is encoraged by no effective punishment for those who breach the rules or fail to explain them in the first place.
This gives rise to a new generation of "rule followers" who have no idea what the system is about who then go on to implement their own system or augment an existing one.
As I said above computer passwords where a bad idea 50 years ago and still are 50 years later.
Atleast those 50 years ago had a semblance of an excuse in that the systems then where pushed to even support the simplest of password systems. Those implementing such systems today have absolutly no excuse.
If you think about it the generalised computer password system is lacking some of the precautions of the military challenge-response system. It would be better for the authentication process to be "public authentication" then "private authentication" then a one time secret exchange by both parties usually from a paper word list or other other equivalent token.
The steps being,
1, User - hits key code to get secure channel.
2, User - checks the channel is secure.
3, Comp - gives login prompt.
4, User - gives public identifier.
5, Comp - Returns public identifier,
6, Comp - Issues private challenge.
7, User - gives private response.
8, Comp - issues a secret challeng word
9, User - checks word is on list and is expected next unused word.
10, User - enters the coresponding secret response word, or duress word, or error word.
The point is both the user and the computer authenticate to each other privatly before going on to the one time word pair exchange.
The user can enter the correct word to procead normally, an error word if the secret word presented by the computer is not the correct one or a duress password if somebody is standing there with a gun to the users head.
But you are very unlikley to see such a system in practice for a number of reasons (based on human laziness).
Such systems have been proposed in the past with Trusted Computing Base systems but never progressed into the normal computing world.
It's pretty easy to tell from this thread who's got boots on the ground. A couple of commenters got it right.
vwm: "Someone who steals your banking credentials might not use them instantly but rather sell them in bulk. Someone else will use them some time later.
So if you change your credentials during that time, you thwart the attack."
People who look at this as "attacker steals password, attacker uses password" are oblivious to what's actually happening out there.
I highly recommend checking out the paper "The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis" which was presented at this year's ACM CCS conference. An online version of it is available at http://www.cs.unc.edu/~yinqian/password.html
Zhang's group performed password cracking attacks, (with approval), against passwords collected from UNC students/employees to measure the effectiveness of password change policies. For example, they found that if they had one password for a user, they could break their subsequent passwords 13% of the time using just five guesses.
On a similar note, I'd like to point people to a paper I co-authored and presented at the same conference, "Testing Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords" which is available at http://goo.gl/wqcX
@TylerK: I wonder how much time typically passes between the theft of banking credentials and their use.
I would expect this time to be relatively short, maybe 2-4 weeks on average.
First of all, what reasons could there be for not using the credentials immediately ? It takes time to transfer them from the credentials thief to the credentials user. It may also take time to find a buyer. Since using the credentials may reveal the theft, one may want to collect a certain number before "going public". There may be some days where the catch will be better than on others, e.g., right after payday.
Now, why not sit on the credentials for a long time ? They will rot naturally, by people closing accounts, changing passwords, etc. The more they rot, the more attacks will fail, increasing the risk of triggering an alarm. The mechanism for obtaining the credentials may get discovered and the victims or their bank may take actions. If the credentials are sold to many buyers, the risk of discovery multiplies. Once the credentials are being used, the risk of discovery and effective defense increases. Thus, if there are many uncoordinated buyers of such credentials, you'd want to be the first to use yours. An excessively large collection of credentials may just be impractical to use.
So it would seem to me that there's a strong motivation for using credentials quickly and the only thing that would slow this down would be logistics and the wait for payday.
If the wait for payday is considered unnecessary, collection of credentials is fast, and buyers can be found on short notice or even in advance, the minimum delay between theft and use may be well below one day.
If the credentials are "in transit" only for a few weeks, you'd have to change passwords very often to significantly reduce the risk. If they're in transit for only a few hours, there's little point in even trying.
So I wonder what patterns are there in real life, both in terms of transit time for credentials, and the moment they get used. (I.e., does such a "payday" effect exist or not ?)
"So I wonder what patterns are there in real life both in terms of transit time for credentials, and the moment they get used. (I.e., does such a"payday" effect exist or not ?"
It may not be possible to find this out due to the fact neither the merchants who lose the credentials and the Payment Card Industry who field the complaints want to go public.
However it is possible to build an adhoc model with the three phases from the time the credential gets stolen.
For the "selling phase" I suspect the two main shaping forces of the market are,
1, minimum bundle size
2, time to sell
with the addition of
3, credential transfer time.
Only when this is finished is the selling phase compleate.
From the transfer point on you are in the "realisation phase" and I suspect it depends very much on,
4, The abilities and methods used to realise money.
By the person who purchased the credentials. They may have reason to make one large one off hit or many small repeated hits depending on how they work.
Then there is the "reporting phase", which starts with the first use of the credential.
For instance with credit cards it might take upto 60days for the user to become aware of the theft with post out statments.
Also as has been seen some online banks systems get a MITM attack on the customers PC so that it does not display certain transactions, so the customer does not actually report the loss.
And the person may not recognise that there has been a loss or even report it for a whole variety of reasons.
To get into my office each day, boot my laptop and check my email, I require nine different passwords, including one time passwords generated by both SecurID and ActivIdentity hardware tokens.
I work for a phone company, not the CIA.
Passwords have had their day.
"I work for a phone company, not the CIA"
Yup and those nine passwords are to keep the CIA out (or that's what the NSA told your bosses boss ;)
@Antiono. I use a unique password for the bank. It isn't used anywhere else. I just change its last character when it expires.
I agree that things arent helped by people implementing rules without understanding why they are in place (which is why we are scared of writing down passwords because the sneaky hacker on the other side of the world can read them).
However, lots of the solutions to the "password problem" simply change where the risk takes place - there is no real reduction in risk.
(SSO / password safes are an example, effectively putting all your eggs in one basket and encouraging an attacker to expend more resources to crack that one repository)
Rather than try to overengineer a solution to a single problem, we should re-assess what our security provisions are and how *any* form of authentication feeds into that.
An article by Mike Howard in 2006 titled "How often should you change your password – or should you bother?" (http://is.gd/h7DVY) basically says that if the retry rate is limited, changing a "good" password is not necessary. A condenced version of his article also appeared in ;login: december 2006 (http://is.gd/h7E44). It's "heavy" on math but nothing Bruce or you should be scared of :-)
@Deke: "It would be great if IT auditors would be informed by reasoned discussion by recognized information security experts. Anybody have any thoughts on how to move us in that direction? Enterprises waste money and user attention on things that don't matter, often just to satisfy an auditor so they can move on to their next tasks. But then the auditor and everyone else notes a "best practice" since so many enterprises have taken the same needless steps. I'd be glad to hear thoughts on how to unwind that yo-yo."
Good luck. I've been an IT auditor for 12 years, and I've spent a great deal of that time harping on "The Law of Unintended Consequences" when it comes to everything from passwords to policy to perverse incentives. IT auditors, unfortunately, are often either mislead or constrained by ill-advised mandates as well.
There has been more than one time that I've had to push for a parameter that I did not agree with but my employers and clients would be subject to disciplinary action and liability if they didn't comply. Of course, I report this to the bodies, but it usually falls on deaf ears.
I'll keep fighting the good fight, but it's a tough battle.
John, CIA, CISA
I agree on changing passwords and esp. password safe. I have to remember many passwords (computers, keypads, etc.) The websites are even more annoying. Why do they want an account and password for me to read the Financial Times or local news site? I know, but it still annoys me. I use password safe (yep sucking up), generic for sites like NYT (password FU) that I don't care if I remember or not and throwaway webmail, and RSA tokens for VPN business when I need to. I think my practices are ok, but certainly open to suggestions from the very knowledgeable readers of this fine blog. (more sucking up). take care, Jacob.
The last line of the conclusion of the empirical analysis: "We believe our study calls into question the continued use of expiration and, in the longer term, provides one more piece of evidence to facilitate a move away from passwords altogether."
All I can say is good luck with that.
I don't really change passwords, I rotate them
for example my facebook gets my gmail password gets my twitter password gets my school password gets my work password gets my facebook password
and whenever I join something I generate a random password
I use Brian's "AugPassword" "SepPassword" etc system at work, but the "password" section of it is a good password, that I change annually.
It, sadly, makes sense when we're dealing with ACCIDENTAL one time password exposure.
AKA I gave my pass to co-worker (who quit the job), or I logged to company mail from public (aka. trojaned).
Though it's 43567634675637'n level of security, and it should never be used as a replacement for competent IDS.
Hell, I will give you an amusing example. It comes from EVE Online mmo (where btw, players employ espionage and counter-espionage strategies only found in intelligence agencies). People like to switch corporations (guilds) from time to time and some of them, sometimes* they don't change all their passwords when they join new one. Political landscape changes frequently, and even without that, it's good to have spy even within your enemies. As such, everyone will cheeck if old passwords ex-member won't start working in systems of hostile corporation. In this, random password purges are very effective.
However, there is another side - one corporation decided, that instead of spying quietly on enemy corporation directorate, they would do bruteforce-copy of their entire forum and make nastiest parts public to create some immense PR damage. Long story short - they were extremely successful, whole game lived with secrets of BoB directorate for weeks.
Similar attack was ran against my own corporation few months later. Luckily, we had form of IDS operational: it detected abnormal activity, and after several pages started feeding their web crawler with garbage. Which in fact provided nice PR win, because attackers announced they infiltrated us before they looked at what they got:D
I guess that next level would be detecting phony login and then feeding infiltrator with neatly modified data (automatically change op dates and other important details) and some nice stenographied message like "YOU'R dumb and ya mommy smells of cranberries".
*with corporations numbering up to 6000 players, someone, sometimes might iss quite a sizable group of people
To expand on what Chelloveck said, I'm also a fan of SuperGenPass (although I find the actual algorithm pretty poorly thought out. See http://stackoverflow.com/questions/554224/... for more about that).
The way to use SuperGenPass safely, however, is to use a browser plugin instead of the bookmarklet. It's unfortunate that the bookmarklet is still the most heavily promoted version as DOM-external plugins are the only safe way to use it.
I am an adjunct instructor at several colleges that enforce a 90-day password change policy, instead of the obvious one semester (about 16 weeks, or 112 days). What genius thought that one up?
I've been with a certain site for what seems like FOREVER. I never ever got hacked. I only changed my pw once a year. BUT since I started using their new feature (which I have to pay for) my pw has been stolen about once a month!!! Shouldn't security on a paid feature be STRONGER than non-paid features??? Especially on the same website? I'm very tempted to stop paying for lower security!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
The link text for the MS Research study has "framework" spelled "framwork."
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..