![[topcap]](/images/floating_sidebar_topcap.png){kind=small}
![[bottomcap]](/images/floating_sidebar_bottomcap.png){kind=small}
(This is an updated version of a contribution I made to the Educause security mailing list last week.)
In the practice of security we have accumulated a number of “rules of thumb” that many people accept without careful consideration. Some of these get included in policies, and thus may get propagated to environments they were not meant to address. It is also the case that as technology changes, the underlying (and unstated) assumptions underlying these bits of conventional wisdom also change. The result is a stale policy that may no longer be effective…or possibly even dangerous.
Policies requiring regular password changes (e.g., monthly) are an example of exactly this form of infosec folk wisdom.
From a high-level perspective, let me observe that one problem with any widespread change policy is that it fails to take into account the various threats and other defenses that may be in place. Policies should always be based on a sound understanding of risks, vulnerabilities, and defenses. “Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment.
Consider the underlying role of passwords: authentication. Good authentication is intended to support access control, accountability and (in some cases) accounting. Passwords provide a cost-effective and user-familiar form of authentication. However, they have a number of failure modes depending on where they are used and the threats arrayed against them. Failure modes include disclosure, inference, exposure, loss, guessing, cracking, and snooping. In the most general case, passwords (such as the security numbers on credit cards, or mother’s maiden name) are not sufficiently secret and are simply too weak to use as strong authenticators. I’ll skip this case, although it is far too pervasive to actually ignore.
Disclosure is a systemic threat on the platforms involved, as well as in the operational methods used to generate and transmit the passwords. This cannot be addressed through changing the password. Instead, the methods used to generate and distribute passwords needs to be examined to ensure that the passwords are not disclosed to the wrong parties. Most operating systems are currently designed so that passwords are not stored “in the clear” and this reduces the chance of disclosure. Unfortunately, some 3rd-party applications (including web-based systems) fail to adequately guard the passwords as they are entered, stored, or compared, resulting in potential disclosure.
Another form of disclosure is when the holder of the password discloses the password on purpose. This is an education and enforcement issue. (Anecdote: at one location where a new policy was announced that passwords must be changed every month, a senior administrator was heard to moan “Do you know how much time I’m going to waste each month ensuring that everyone on my staff knows my new password?”)
Inference occurs when there is a pattern to the way the passwords are generated/chosen and thus can be inferred. For instance, knowing that someone uses the same password with a different last character for each machine allows passwords to be inferred, especially if coupled with disclosure of one. Another example is where generated passwords are employed and the generation algorithm is predictable.
Exposure is the case where accident or unintended behavior results in a sporadic release of a password. As an example, think of someone accidentally typing her password as the user name in login, and it is captured in the audit trail. Another example is when someone accidentally types his password during a demonstration and it is exposed on a projection screen to a class.
Loss is when someone forgets his or her password, or (otherwise) loses whatever is used to remind/recreate the password. This introduces overhead to recover the password, and may induce the user to keep extra reminders/copies of the password around — leading to greater exposure — or to use more memorable passwords — leading to more effective guessing attacks. It is also the case that frequent loss opens up opportunities for eavesdropping and social engineering attacks on the reset system as it becomes more frequently used: safeguards on reset may be relaxed because they introduce too much delay on a system under load.
Guessing is self-explanatory. Guessing is limited to choices that can be guessed. After a certain limited number of choices, the guessing can only transform into a cracking attempt.
Cracking is when an intermediate form of the password (e.g., an encrypted form stored in the authentication database) is captured and attacked algorithmically, or where iterated attempts are made to generate the password algorithmically. The efficacy of this approach is determined by the strength of the obfuscation used (e.g., encryption), the checks on bad attempts, and the power and scope of the resources brought to bear (e.g., parallel computing, multi-lingual databases).
Snooping (eavesdropping) is when someone intercepts a communication employing the password, either in cleartext or in some intermediate form. The password is then extracted. Network sniffing and keyloggers are both forms of snooping. Various technical measures, such as network encryption, can help reduce the threat.
Now, looking back over those, periodic password changing really only reduces the threats posed by guessing, and by weak cracking attempts. If any of the other attack methods succeed, the password needs to be changed immediately to be protected — a periodic change is likely to be too late to effectively protect the target system. Furthermore, the other attacks are not really blunted by periodic password changes. Guessing can be countered by enforcing good password selection, but this then increases the likelihood of loss by users forgetting the passwords. The only remaining threat is that periodic changes can negate cracking attempts, on average. However, that assumes that the passwords choices are appropriately random, the algorithms used to obfuscate them (e.g., encryption) are appropriately strong, and that the attackers do not have adequate computing/algorithmic resources to break the passwords during the period of use. This is not a sound assumption given the availability of large-scale bot nets, vector computers, grid computing, and so on — at least over any reasonable period of time.
In summary, forcing periodic password changes given today’s resources is unlikely to significantly reduce the overall threat — unless the password is immediately changed after each use. This is precisely the nature of one-time passwords or tokens, and these are clearly the better method to use for authentication, although they do introduce additional cost and, in some cases, increase the chance of certain forms of lost “password.”
So where did the “change passwords once a month” dictum come from? Back in the days when people were using mainframes without networking, the biggest uncontrolled authentication concern was cracking. Resources, however, were limited. As best as I can find, some DoD contractors did some back-of-the-envelope calculation about how long it would take to run through all the possible passwords using their mainframe, and the result was several months. So, they (somewhat reasonably) set a password change period of 1 month as a means to defeat systematic cracking attempts. This was then enshrined in policy, which got published, and largely accepted by others over the years. As time went on, auditors began to look for this and ended up building it into their “best practice” that they expected. It also got written into several lists of security recommendations.
This is DESPITE the fact that any reasonable analysis shows that a monthly password change has little or no end impact on improving security! It is a “best practice” based on experience 30 years ago with non-networked mainframes in a DoD environment — hardly a match for today’s systems, especially in academia!
The best approach is to determine where the threats are, and choose defenses accordingly. Most important is to realize that all systems are not the same! Some systems with very sensitive data should probably be protected with two-factor authentication: tokens and/or biometrics. Other systems/accounts, with low value, can still be protected by plain passwords with a flexible period for change. Of course, that assumes that the OS is strong enough to protect against overall compromise once a low-privilege account is compromised….not always a good bet in today’s operating environment!
And, btw, I’ve got some accounts where I’ve used the same password for several years with nary an incident. But in the spirit of good practice, that’s all I’m going to say about the passwords, the accounts, or how I know they are still safe. 
One of my favorite Dilbert cartoons (from 9/10/05) ends with the pointy-haired boss saying “…and starting today, all passwords must contain letters, numbers, doodles, sign language and squirrel noises.” Sound familiar to anyone?
[A follow-up post is available.]
del.icio.us »
Digg this »
April 20th, 2006 at 7:51 am
“Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment.”
I would submit that very few of us have sufficient data to do an accurate risk assessment from scratch. Cyberworld incidents aren’t as stable and foreseeable as floods and burglaries. Risk assessments that do not take into account changing environments are not accurate. Risk assessments that don’t need to are probably too general to be of much practical value.
Best practices provide a floor to build on. I’m not saying they should be followed blindly and I agree with your comments about password expirations but best practices should not be dismissed lightly.
April 22nd, 2006 at 11:16 am
I agree with Gary’s take on best practices — they’re rarely perfect but useful to establish a baseline for a particular organization to tailor to its needs. We’re about to expire passwords for the first time in 10 years and increase their strength. Given that we have sensitive data, and the burden that dual-factor authentication would place on many important workflows, having passwords expire, increasing their length and complexity and restricting password resuse was deemed the best fit for our organization. As Gary points out, risk assessments are incredible difficult and depend on which department does them. If our information security team was the sole gatekeeper of risk assessments, we’d be submitting DNA every morning for authentication.
April 22nd, 2006 at 12:46 pm
[...] A blog post by Eugene Spafford which examines password security, and the way that detrimental security practices sometimes get propagated because they’re considered by many to be "best practices."read more | digg story [...]
April 22nd, 2006 at 12:47 pm
Users will respond to such password-change policies with a strategy to compensate for the added complexity. If users are unable to remember passwords - for example, because they have several accounts on different networks and updating the password for all accounts is too time-consuming, then such a strategy would be a piece of paper locked in their desk, or a text file (maybe encrypted) containing all the current passwords. Alternatively, they will use consecutive numbering in their passwords, to the next password can be easily guessed if the previous one is known.
None of these strategies is particularly welcome from the security stand-point. The result of a change-password-every-month policy is a less secure system.
April 22nd, 2006 at 12:47 pm
[...] Here’s an interesting post about forcing password changes. [...]
April 22nd, 2006 at 1:05 pm
“Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment.”
This is one of the most enlightened statements I have read in the recent past. Thank you for sharing it. I now have a proper defense when someone says, “But you’re not following so-and-so’s best practices! We’re doomed!” Previously, this kind of statement would stop me in my tracks because, even though I found the statement disquieting, I had no proper rebuttal.
April 22nd, 2006 at 1:23 pm
While you may have a point, I could also tear apart every single security facet similarly. However, when taken as part of a whole, this helps.
I think you’re being ignorant, overly chest-thumping to get attention, and just panic-attacking over having to change passwords in some environment, possibly where you work.
By the way, which is more secure or at least better from a security perspective: changing passwords every month (or regularly) or do as you do, keep them the same for years? That simple question is enough to debunk this entire, poorly organized piece.
What about encryption keys? Should we keep those the same as well, even though the longer you keep them the same, the more data you can collect to try and crack it?
If “any reasonable analysis” shows that password rotation is moot, then do it!
April 22nd, 2006 at 2:06 pm
[...] read more | digg story [...]
April 22nd, 2006 at 2:10 pm
The problem with “best practices” is that they frequently leave out the significant factor that we are dealing with human beings. I work in the heath care industry, and HIPAA has made access control pretty important for us. We also mandate regular password changes, and the policy is that a password cannot be reused until some number of changes has occured. When that number was 3, I could remember the three passwords I used, and keep that information more or less secure in my head. Then someone decided that the number of changes ought to be increased to 8 to provide even more security. What most people did in response to this was to use a base password with a different number that end. I did something slightly different: I typed up a list of my 8 passwords and keep it in my desk. In any case, my estimation is that by increasing the number of changes from 3 to 8, the actual level of security has decreased.
April 22nd, 2006 at 2:41 pm
[...] read more | digg story [...]
April 22nd, 2006 at 3:06 pm
I agree with most everything you’ve said. However, expiring passwords on a regular basis will help protect a network against accounts that should be disabled/removed due to staff turnover, but have managed to slip through the cracks. Granted, accounts that “slip through the cracks” reveal other operational weaknesses, but it does offer at least some protection until an account audit can be performed.
April 22nd, 2006 at 3:45 pm
[...] In this post Prof. Eugene Spafford of Purdue talks about security and passwords. There are so many buzzwords and scare-tactic marketing in security that most of the non-technical people I know are reduced to the cyber equivalent of burnt offerings: they subscribe to some (often) dysfunctional security product and then cross their fingers. They don’t have the time and energy to understand where the threats are and how to avoid them (like using Firefox instead of IE, for example). This article briefly delineates the major threat modes for passwords and then offers some thoughtful advice. [...]
April 22nd, 2006 at 4:04 pm
In my industry (Healthcare in Alberta) we are struggling with implementation of enhanced security (ISO). Our move to strong passwords that expire every 45 days has provided some security but has definitely caused most users to has a negative opinion of security efforts in general and a certain percentage of users to write down, share passwords, in some cases never log off rather than going through the process of changing passwords. We need to find a new way, people have too much to remember as it is, we do not live in a perfect world of integrated authentication and single sign -on. At the end of the day our policy has led to more breaches, not less. We are in the process of changing to a 90 day expiration period. Security is not about rules that never change, it is about responding appropriately to identified threats.
April 22nd, 2006 at 4:24 pm
I believe the author’s conclusion is still probably valid, but I think the author is missing an argument which favors periodic password changes.
If a password is compromised, that security breach gives the attacker access to sensitive data and services for that moment. If the user’s account grants access to historical information (saved emails, older documents, etc.) then the attacker would gain access to those sensitive items as well. The attacker only gains access to FUTURE documents and services for as long as the login credentials are still valid.
If the user leaves the company, those credentials aren’t valid for the attacker any longer. If the user doesn’t leave the company for many years, those credentials are valid for many years, and the attacker will have access to many years of documents and/or services.
If the company requires users change their password every month, the attacker would lose access to future information for the same period of time the user doesn’t use the same password again. If the user changes their password monthly, and NEVER reuses old passwords, an undetected attacker would not have any future access to this account without exploiting a new security vulnerability. If the user never changes their password, the attacker would conceivably maintain access to the user’s account indefinitely.
Requiring users change their passwords at intervals limits the impact of some kinds of security vulnerabilities. A password-changing policy is still likely to do more harm than good, but this kind of policy is not without merit.
–Michael Spencer
April 22nd, 2006 at 4:30 pm
anonymous at April 22nd, 2006 at 1:23 pm posted a comment that is amazingly wrong. Changing a password does not change the probability that it will be guessed at all. Do the math! Assuming passwords are randomly distributed in the keyspace, the probablity that a guess matches a password is the same independent of how often the password changes. (The above assumes an online attack. If you have an offline copy of a list of encrypted passwords then you need to guess them before they become stale.)
April 22nd, 2006 at 4:58 pm
Entropy.
You can consider regular password changes as a way to artificially increase the entropy of a password, making brute forcing the password more difficult in a given period of time (yes, assuming the change interval is smaller). Same function as complexity requirements.
April 22nd, 2006 at 5:49 pm
As a multi-hat (admin,pgmr,user,etc…who isn’t these days?) with dozens of systems to maintain, I have some 70-80 different ids/passwords for the systems I have to access. These are typically all different (though similar) due to password aging and complexity differences, and range from 4 digit PINs to 20+ chr “pass phrases” and secure card tokens.
So forget the piece of paper, I have to use a “little black book” to keep them all. With a dozen or so changes per month, it gets full of permetations and erasures fast!
Obviously, this security control method does a pretty good job of mainly keeping me out of the system, but probably not that great against someone interested in hacking.
I suspect most successful hacks are not by attacking passwords, but exploits or social engineering. You could change your password every day, but if your system is unpatched, who needs the password!
April 22nd, 2006 at 9:53 pm
Password are, and will always be a weak form of security. To have a secure system, corporations (or individuals) must use a system with multiple level of security. A combination of Password and Secure ID tag is a perfect exemple of this. ANY password can be cracked fairly quickly by using cracking software that uses rainbow tables to break down even the most complex password. Even if you are using complex password with special charater, your password will be easily cracked with software like Ophcrack 2. . In the article we’ve only been using the standard alphanumerical character set, but the cracking process can easily be done via a full charset.
April 22nd, 2006 at 9:54 pm
Sorry, the commenting system removed the link to the article. here it is: http://geeksaresexy.blogspot.com/2006/04/cracking-your-windows-sam-database-in.html
April 23rd, 2006 at 3:17 am
[...] read more | digg story [...]
April 23rd, 2006 at 5:49 am
Taken alone, forcing monthly password changes is not effective. Any good information security officer should enforce other password security schemes such as:
- minimum password lengths
- force a combinaton of letters (a,b,c…) and numbers (1,2,3…)
- password is rendered inactive after a defined number of tries
- ID owner is alerted if several wrong password attempts
April 23rd, 2006 at 7:01 am
[...] I was quite surprised at a blog from CERIA (Security Myths and Passwords, written by Purdue professor) as well as its corresponding Digg article. [...]
April 23rd, 2006 at 4:50 pm
[...] link [...]
April 23rd, 2006 at 7:45 pm
[...] Articles/Features FBI’s Top 11 Deaths of the Year Lost Levels - Pescatore Top 10 Windows XP Tips Of All Time Security Myths and Passwords The World of Final Fantasy Seanbaby’s Worst NES Games of All Time [...]
April 24th, 2006 at 12:57 pm
[...] Spaf: Security Myths and Passwords [...]
April 25th, 2006 at 12:46 am
I suggest this be discussed further in sci.aquaria.passwords.
April 25th, 2006 at 1:35 am
It’s amusing to read the reply from “anonymous” about how this is a chest-thumping article. It isn’t. The article itself points out that all password-age policies do is limit the time of exposure. Which is not to say that even this is true. Typically, when you’re in, you stay in, regardless of password changes. It sounds like “anonymous” never went to university and changed other students “hosts.allow” file. At a minimum, access to some-one’s desktop account at even the most strenuously guarded companies will enable you to get enough information to mount some serious social engineering attacks if the password does change in an unpredictible manner. But here’s the rub; passwords do NOT change randomly when they have to be changed monthly. No one puts up with that.
Password change policies, on the whole, make things worse, and taken as a single factor would only improve things a tiny, tiny bit.
April 25th, 2006 at 1:51 am
A couple of responses to the comments here….
First, systems such as MS Windows will still allow a user to log on after their password is expired, it just immediately prompts the user for a new one. Therefore, expiring passwords doesn’t help with accounts that “should have been disabled”.
To Mr. Spencer, you should note that any competent cracker will, having once obtained access to an account, likely have access to it in the future. On a Unix shell, for example, it would be simplistic to generate a new SSH authorized key - the user is highly unlikely to ever check his .authorized_keys file, so even after changing the password, the cracker would still have access. This is only one example; there are plenty of others.
Monsolo - I don’t see how adding other controls on top of one that doesn’t enhance security makes that one any more useful. As Spaf said, password rotation is a defense again brute force password guessing and human guessing. Ok, I’ll give you that enforcing the controls you mentioned would decrease the likelihood of a human guessing the password, but password rotation will have a less-than-negligible effect on that. No human will ever randomly type @D8as%nhñgS when trying to guess the password, so why bother?
That being said, I’ve mandated rotating passwords before. My thought was that I knew my users shared passwords over time (oh, I need to use your computer for a few minutes, but your screen is locked) so by forcing a change I was hoping that if a person left the company they wouldn’t retain access to anyone’s accounts. However, the better solution in that case would have been termination for people who shared passwords and/or forcing all users (only about 15-20 in the company) to change passwords everytime someone left.
My 2 cents.
April 25th, 2006 at 1:57 am
I’m an actual user, but with a background in cryptography unrelated to my current job. My principal concern is getting my job done; security is secondary.
With restrictive password policies, we end up with:
1) passwords on paper or a shared text file
2) passwords being changed by adding 1, eg. password56, password57
The restrictive password policies have decreased actual security by promoting shared and guessable passwords.
Of course, the biggest actual risk is social engineering, which the password police have done nothing about.
April 25th, 2006 at 2:24 am
But you’re simplifying the type of abuse; you’re assuming that unintended access is instananeous. For many common attacks, this is not the case. For example, accessing someone’s email; a malicious person would probably try to conceal their access perpetually, using it maybe only to read the user’s mail. If the password is never change, recovering security is contingent on the intruder being discovered. If the password is changed periodically, security will eventually be recovered (at least, until the next intrusion).
This, I believe, is why periodic changes are mandated in many places; it’s not the intrusions you know about that you’re concerned about, it’s the ones you don’t know about. And may never know about. But you can still limit their damage.
April 25th, 2006 at 2:31 am
I wonder how many people deploy the “change passwords once a month” as an audit checkbox to be ticked?
April 25th, 2006 at 2:31 am
jimmy Says: Entropy..
Lets assume that there’s a fixed amount of password entropy in each person’s brain. If we change passwords once a month then the entropy per password goes down. This is approximately the way my brain works.
Eugene:
I have always thought of this as a way of limiting the length of a break in with a password. An attacker can have one month of access, but to go further they need to leave in a Trojan. Trojans are often more easy to detect than the fact that a different person is using an account from the one who’s supposed to.
April 25th, 2006 at 3:06 am
1st: Changing password does not protect against guessing: Just assume for a moment that we have 10000 codes available (for example the 4 digit pin), one has been chosen.
If an intruder is bruteforcing/guessing the code, changing the code will only provide protection if we change it to one that the intruder have tried and discarded.
Otherwise, we have no knowledge of whether the new code is closer in his row of guessing or not.
There is no difference whether we have available a code space of 10000 or more, it’s just easier to picture the restricted case.
Changing the password does not make it less probable that it will be guessed unless you monitor the ongoing cracking attempts, so you can choose the new password cleverly.
Obviously this leads to the contradiction since the intruder then only needs to get hold of the list of “trusted passwords” and hence reduces the guesswork - and such a list is easy to get, because he made the list himself!
In short: You do not change the probability of someone guessing/cracking the password by changing it. Hence, regardless of what technology the intruder may have at hand, changing password does not encrease protection against cracking. period.
Choosing good passwords does protect against guessing and cracking.
Furhter, if you have ongoing cracking attempts then you have a whole different problem to deal with and this is not solved by changing passwords.
Changing passwords only have effect if that password have been disclosed and hence cannot be trusted. A policy of changing passwords regularly limits the window of oportunity, but it also assumes that users disclose their passwords.
But the real solution to this problem is to educate users on how to handle their passwords. Inform them that passwords must be changed immediately if accidentially disclosed, and that there is no such thing as authorized sharing of passwords.
Obviously, systems must be designed such that people can access what they need to access without sharing passwords.
Password based authentication is not in itself insecure, bad passwords and irresponsible password handling by users is the real problem.
Further, imposing regular password change may result in decreased security: Simply in order to remember the passwords, the more often you require a change, the worse passwords users will choose. The will be more likely to choose mothers maiden name password types, with a posible integer to itterate when changing.
A good password policy instructs and enforces users to choose good passwords, and educates users on how to protect them.
April 25th, 2006 at 3:09 am
There some simple steps that can be taken to detect password disclosure on web sites - looking for overlapped web requests from different IP’s with the same login is very effective for internal apps that are used all day.
Password escrow is also important, particularly accounts where password recovery or change is non trivial. All my passwords are written down and placed in a sealed envelope in my home safe so that if I get hit by a bus my wife can get access as needed.
That said I’ll be very happy when inexpensive two factor authentication becomes more common.
April 25th, 2006 at 3:11 am
P.S. you just got slashdoted.
April 25th, 2006 at 5:22 am
I suspect I could guess 90% of passwords at the company where I used to work in a few minutes. Why? Because a couple of years ago they instated a policy where passwords have to be changed every month or so.
Wow, a great security improvement! Because instead of using passwords that were difficult to guess, people who are forced to change on a regular basis use the same password with an incrementing number at the end.
Humans are the weak link in security. It’s all very well to tell people they must use a thirty character random password which changes every hour, but almost no-one can remember that. If you force them to change passwords, you end up making the system less secure because when you have to remember passwords for thirty web sites, six bank accounts and credit cards and several PCs, you sure don’t want the hassle of having them vastly different on every one and changing one every few days.
IMHO forced password changing is simply retarded. The real problem is that passwords themselves are not very secure, and forced changes just make them less secure because people choose a system which is simple to remember.
April 25th, 2006 at 5:26 am
The thing that irritates me most about being required to change my password every 30 days is that I’ve got about 2000 machines to change it on. For one reason or another, they’re mostly not using any kind of centralized password system, such as NIS, so I have to login on each machine to change my password. I’ve tried telling management that, assuming 1 minute per password, their change policy wastes nearly an entire working week of my time every month, but so far they haven’t listened.
April 25th, 2006 at 5:40 am
[...] CERIAS Weblogs » Security Myths and Passwords [...]
April 25th, 2006 at 6:04 am
Personally i am of the opinion that monthly pasword changes, especially if you disalow repeated passwords for any great length of time are actaully less secure. If you change the password infrequently or never then user remeber their passwords. If you require frequent password changes then users tend to forget them so they start writing them down on post it notes, on bits of paper selotaped to the underside of their keyboard etc. I beleive this kind of thing to be miuch worse than the risk that John may tell Jane his password so she can pick up his email when he is on holiday etc. The most important element of pasword security is user education combined with enforced complex passwords.
April 25th, 2006 at 6:08 am
Though I agree with almost all of spaff’s view (surprise, surprise!), account sharing is made less prevaliant by forcing periodic changes.
The flipside is that it may encourage publishing/storing passwords in shared areas.
In my experience if you switch to a periodic password change policy, and you make it easy enough for [the right] people to get accounts, it becomes more trouble to share an account than to manage your own - and users nearly always follow the easiest path through a problem.
Dom
April 25th, 2006 at 6:13 am
[...] I must admit I don’t know who Eugene Spafford is. I also failed Network Security. Perhaps the two are related, I’m not sure. According to his blog, ‘Eugene H. Spafford is one of the most senior and recognized leaders in the field of computing.’ I’m not so sold on the recognisable issue but his blog entry on Security Myths and Passwords is interesting reading. Why is it a good idea to change your password regularly? The typically insightful Slashdot commentary as well. [...]
April 25th, 2006 at 6:16 am
Greetings Spaf, I totally agree with your views on goofball password policies. I, for one, am “guilty” of not changing passwords for more than a couple of years now.
The password strength enforcement system I have put in place consists of a dual P3 system running John the Ripper with permuted multi-lingual dictionary words, hindu christian and muslim names, popular Bollywood actresses, initials of catch phrases and all old passwords cracked so far. A user does not need to change their password as long as my cracker system hasn’t cracked it. The minute someone’s password gets cracked, they are forced to reset it. You are free to choose weak passwords or strong passwords. Depends on the annoyance level you want to live with.
Do you think this will ever grace a policy guideline or a “best practices” note?
April 25th, 2006 at 6:41 am
Our passwords expire every 2 months. We cannot reuse any of the previous 3 passwords. However, there is no minimum time that you have to maintain a password, so every 2 months, I change my password 4 times within a couple of minutes and end up with the same old password.
April 25th, 2006 at 7:00 am
A very well written piece on the topic. In my experience people (management) doesn’t really care too much about what a risk assesment says (same goes for a CBA or TCO study) unless it says what they want to hear — and often unless an Auditor or similar group agrees.
Consider SSO (single sign on) which everyone seems to be burning lots of energy chasing. Consider the security risks associated with it and the benefits. Fewer passwords to change/remember less chance of loss, etc. — but once it is lost, all is lost. So the same security is applied to salary maintenance as is to entering an online sports bracket.
April 25th, 2006 at 7:17 am
welcome slashdotters!
April 25th, 2006 at 7:24 am
Now I’ve worked both sides of this fence - the side that does the security implementations and the side that comes in and tells people to enforce “best practices” and I’d have to agree with the article.
So many people here jumped to the defence of so called best practice… just what is best practice anyway? No one in this industry seems to have the same answer and most of the people i’ve come across who spout such terminology use it because, as the article says, they have no deep concept of what to do.
So instead we enforce a series of quasi-meaningless bullet points and call it best practice. What’s much worse than this however is the static nature of these “insights”. Consulting / management practice books release a set of best practices, which are in turn read and perhaps even used in short-course (or uni course) testing, to teach people who really have a low level of understanding of the topic material how to pass of pretend-knowledge to people who have even less knowledge. This is called “big picture thinking” or “high level”. Even worse again is that such consultants tend to glorify themselves on the fact that “you don’t need a deep understanding of a subject matter to consult on it”.
So now you have a group of people enforcing 3 year old “best practices”, which by definition cannot be “best practice” because there can only be one “best” and as mentioned above, I’m yet to meet two people with the same answer to “best practice”.
Perhaps we should just call it “what I do coz it’s worked so far” instead of “best practice”.
April 25th, 2006 at 7:35 am
- password is rendered inactive after a defined number of tries
Consider carefully the implications of such a policy. It allows someone totally without access to mount a denial-of-service attack against any legitimate user, simply by attempting to login as that user. I’d contend that this idea is another “best practice” that has become meaningless over time.
April 25th, 2006 at 8:52 am
Two-factor is certainly turning into a must where it can be enacted practically. The problem arises when some subsystems cannot accomodate ACE/RADIUS (for example) or when you have a role/shared account for which indirect access (sudo/Run-As) cannot be used — system/network health monitoring program that needs to log in.
In this day of SarbOx, you must demonstrate adequate control over who has access and why. With a role or shared account you can only control that by routinely changing the password to limit who might know the password and to exclude those who knew it previously but no longer have a demonstrated need. Passwords get shared over time — it happens. Policy can be written to “prevent” it, but you still need to assume that people will violate policy.
April 25th, 2006 at 9:05 am
The auditor as a driving force shouldn’t be underestimated. We get dinged every year for “only” requiring password changes every 180 days. However, we require a longer minimum password length than they ask for. We’ve been able to defend the policy every time (so far). I’m fairly sure that if we went to anything less freqent, though, we’d lose the argument and end up with a far less rational policy.
April 25th, 2006 at 9:14 am
It seems to me that everyone is missing something stunningly important. In a well designed environment, there is no external access to the internal system. Therefore, authentication systems are only for folks on the inside. Now if you have someone on the inside that is hacking, you have a much greater problem: YOU HAVE SOMEONE WITH PHYSICAL ACCESS that means you no good. You can have all the password complexity that you want. If I can look over someone’s shoulder or look in their desk drawers for password papers, etc.
Secondly, there are a number of password schemes out there that check the new password against previous passwords and if there is insufficient difference, it rejects the new password. This means that the passwords are stored somewhere in plain text or decryptable form. If I can get at that data, nobody’s password is safe. Heck, at that point, I only need one password to get everyone else’s.
I have never been a fan of default password changing. In one place that I worked, password changes were required and complex, multiple character class passwords that had no dictionary words as part of them were the only ones acceptable. The help desk spent most of it’s time doing password resets, people weren’t getting work done and sticky notes started apprearing on monitors with passwords on them. I typically choose darn difficult to crack passwords. I have accounts on several systems. I can’t remember which password is on which system and after three tries, it locks me out. So I’m not getting work done, I have to get someone to unlock my account, keeping them from work that they’re supposed to be doing, and I have to make yet another password because it’s remembered my last 5 passwords and won’t let me reuse them. SHEESH!
April 25th, 2006 at 10:37 am
[...] http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/ [...]
April 25th, 2006 at 1:53 pm
Best practices are a baseline, not meant to be the end all of security. I consider them when doing evaluations, but I believe they are mostly there for execs who really do not understand security to get a little insight into what needs to be done. You, or myself, as a security guru, is who it is generally left to, to decide who, and what actaully works for us in a given situation.
April 25th, 2006 at 2:30 pm
Hello from a former student!
Excellent article. Now if only I could get my organization’s management to understand it.
In my 7 years of experience in healthcare IT, account and password sharing is rampant to the point of being commonplace. Not only that, but management facilitates this problem by creating (or mandating the creation of) “generic” accounts (shudder!) to enable users to log in easier because of the user’s lack of education or the organization’s lack of investment in education.
On the flip side, the company for which I work ( a large IT outsourcing company) requires passwords with such a degree of complexity that they’re nearly impossible to remember. Throw in the 50 or so systems that I access on a regular basis, and there’s no way to remember every password at any point in time and have them be sufficiently random. I finally resorted to writing these down and storing them in my wallet.
With HIPAA in the healthcare world and the threat of privacy related lawsuits, better access administration for the purposes of auditing on high value systems is becoming increasingly more important. Unfortunately, security on the vendor side is, in most cases, lacking to say the least.
Fortunately, biometric (facial and fingerprint recognition) and 2-factor authentication systems are becoming more common, but I’ve yet to see them implemented or even offered as part of patient critical systems.
April 25th, 2006 at 3:20 pm
Spaf, you missed two big ones here!
First, as Court said previously, mandated password changes combined with automated password expiration serves as an essential check on the effectiveness of your account removal process. Does your system somehow guarantee that accounts are removed when they should be removed? How do you really know that? If you get a regular report (daily/weekly/monthly) of password expirations, you have a consistent audit of how well your personnel manager (HR department in Dilbert-speak) is dealing with “employee terminations” (another Dilbertism). If you consistently see accounts expiring, you know that your *humans* (not your computers) are failing, and presumably you will deal with that issue so that disgruntled ex-employees don’t have a valid account.
This also catches embezzlers, on occasion - a user is left on the payroll by a crooked clerk, who gets a cut of each paycheck, but the expired user account raises a red flag and the crook is revealed. I’ve caught embezzlers twice this way in my own career, completely by accident. If you don’t do expirations, and simply rely on auditing against a user list supplied by payroll or HR, you will never catch an embezzler. This type of criminal controls the employee lists you receive, and you can’t prevent that.
The second point (perhaps not so obvious, but based on a quarter-century of experience) is that users eventually run out of incredibly bad passwords and have to use better ones. What do I mean? Well, if you use a history mechanism and regular password changes, the end user quickly cycles through his favorites (which are the same as everyone else’s favorites) and then has to come up with something more intelligent. At that point they may actually (gasp) click the button that gives them help in selecting a good password!
Your main point - that security nostrums should be taken with a grain of salt, and constantly re-evaluated in the light of real-world requirements - is valid. But mandatory password changes for end-users are still a good idea, as long as they interval is not ludicrously short (like, less than 60 days).
My personal backdoor passwords don’t expire… but they are usually around 64 characters long and not in any dictionary, so it’s no big deal.
April 25th, 2006 at 5:45 pm
One major point missing from the post is that a user may be completely unaware that the password has been disclosed. Your analysis seems to suppose that the user may be aware of disclosure. Changing the password limits the damage.
Another data point is that as a hacker/pen tester, if I gain access to a domain, I will attempt to crack all of the passwords, but be careful to only use one account. If the admins do not force a complete password change, I’ll get back in repeatedly. If the passwords change, my information degrades over time.
With respect to iterated passwords, it seems that around 1/4 to 1/3 of all users do this. It is possible to create countermeasures to inhibit this behavior.
Speaking of re-evaluating in light of real-world requirements - it might be a good thing to run some of these academic analyses past some people who have had to deal with operational security breaches. They may offer some additional perspective so that we could deal with engineering practices as opposed to theoretical practices.
Overall, and interesting article, and good food for thought.
April 25th, 2006 at 6:20 pm
[...] CERIAS Weblogs » Security Myths and Passwords (tags: security password toread) [...]
April 25th, 2006 at 6:39 pm
I would agree that 30 days for changing a password is excessive, however, periodically changing passwords does provide benefits others listed above (addressing already compromized accounts, prevent sharing of accounts, making generic accounts more secure) as well as ensuring passwords meet complexity requirements. When used in conjunction with other controls, such as innactive account reviews, this policy will help to highlight accounts that may be innactive and should be disabled or removed.
I like the idea of forcing a password change when someone leaves the company. This would fit well with many small companies.
A properly designed access control system provides for lost password services allowing an individual to recover his/her password based on a set of personal questions. This reduces help desk costs and can prevent users from writing down passwords if they know they can recover a forgotten one.
jps - While it is true SSO presents the risk that once the password is compromized all is lost. However, properly implemented access control systems will require some other type of authentication (password, token, biometric) for more sensitive systems or higher levels of access than a person would normally use.
Additionally, SSO makes it so that users only need to remember one password for multiple systems, less chances they will write them down.
Kevin Kenny - which is more important, preventing someone DOSing a user’s account or preventing someone from brute-force guessing a password?
Also, many account lockouts allow for a reset after a specific amount of time therefore not “permanently locking a user out”
April 25th, 2006 at 9:52 pm
[...] Several recommendations today. First of all you know that bad data can propogate in databases for years - my personal example is the first few letters of my last name that got enshrined in some company HR system as MC space C and others as McC, along with some systems requiring leading zeros on the employee number to pad to eight characters in some field, and others being satisfied with the employee number of whatever length. It’s the same with best practices that become enshrined long after the need is gone. The article from Gene Stafford at Purdue speaks exactly to that issue ” [...]
April 25th, 2006 at 11:00 pm
If your accounts are usable from the internet, you’d better think about rotating passwords at least a couple times a year (I like 100 days). Why?
1) How many websites do you visit these days where you must register a username/password?
Do you think your employees aren’t using the same username/password they use on your network to register on these other sites? They likely registered using your company issued e-mail address — now anyone with access to those account records has all the info they need to find your webserver and impersonate that employee. Expiring passwords periodically mitigates this issue.
2) The prevalance of botnets and other malware that capture and transmit keystrokes is a big risk. Even if your users follow policies to the letter, there’s a risk that the password might be compromised. Expiring passwords limits the possible damage. I’ve personally investigated incidents where the fact that a user had to change their password exposed an unauthorized user (due to the resultant unexpected login failures, which were noted in a security review)
April 26th, 2006 at 2:58 am
Nowadays beside these well known issues, we have to deal with an additional parameter which is the mobility. Many of us are travelling, using more than one computer from different locations. In the same way, we need to access our application and web sites from everywhere, from every computer. This is why, I opted for an online password manager.
I’m using the revolutionary service PWMGR (www.pwmgr.com) for different reasons.
I store there my passwords, PINs but also any kind of number I need to access from everywhere. I don’t need to be bothered with the selection of a new password since I can use the integrated password generator. When a new password is requested I simply asked PWMGR.COM to generate one for me based on my defined policy. I even don’t know some of my secrets. I just go on-line, select the related entry and copy it to the application. Furthermore, I don’t have to be concerned by the availability of my data in case of disk crash as this service is provided by the PWMGR. It also allows me to align the required level of authentication ( simple or strong authentication) to the sensitivity of the data contained in each individual vault. It is so useful and it saved me so many times that I keep convincing my friends to use it.
For all these reasons I strongly recommand this service. It makes our live easier and our password more secured.
April 26th, 2006 at 3:03 am
Nowadays beside these well known issues, we have to deal with an additional parameter which is the mobility. Many of us are travelling, using more than one computer from different locations. In the same way, we need to access our application and web sites from everywhere, from every computer. This is why, I opted for an online password manager.
I’m using the revolutionary service PWMGR (www.pwmgr.com) for different reasons. I store there my passwords, PINs but also any kind of number I need to access from everywhere. I don’t need to be bothered with the selection of a new password since I can use the integrated password generator. When a new password is requested I simply asked PWMGR.COM to generate one for me based on my defined policy. I even don’t know some of my secrets. I just go on-line, select the related entry and copy it to the application. Furthermore, I don’t have to be concerned by the availability of my data in case of disk crash as this service is provided by the PWMGR. It also allows me to align the required level of authentication ( simple or strong authentication) to the sensitivity of the data contained in each individual vault. It is so useful and it saved me so many times that I keep convincing my friends to use it.
April 26th, 2006 at 5:14 am
the biggest problem i have encountered, is people are at the beginning very eager to create extreme secure passwords.
but after the 3rd months or so they start to use extreme insecure passwords, or if it it not possible to do so… post-it is your friend o_O
something i am unsure of are big lists of words and letter-combos that are not allowed in the password. i alwas have the feeling such things will make a (non lexica) brute force attack easier because there are much less posibilities (but i never calculated it i must admit)
April 26th, 2006 at 6:57 am
Assume a password policy that requires changing
the password every 6 months, requires a certain
complexity from the password itself, doesn’t allow increasing counter passwords (pass12, pass13, etc) and is coupled with proper auditing, and policies and systems that deny
the ability to do online password guessing or
to get the list of users/pass coupled with two
(and sometimes three) factor auth for sensitive
systems and data.
Assume that the password policy is backed up
by active and passive security systems that
either do on-line monitoring and stopping
(smart IPS) of attempts to do malice, or
offline daily churning of log files on central
logging servers and look for anomalies, report
and act on it.
The password change policy (6 months in this
case) is just one brick in the security design
and the attempt to portray it either as the
goal of security, or the pivot of it, is wrong
and misleading.
In is known that passwords in general are a
weak means of authentication, both due to the
digital possibilities to crack them, but also
and more so due to the social engineering based
problems. Until that time that a personalized
authentication based on a few factors will be
easy and cheap, passwords will remain prevalant
in organizations that do not have monster
budgets and/or are required to do so by
legislation.
(I am talking about a university with 50,000
users).
regards,
–Ariel
April 26th, 2006 at 7:30 am
Security myths and passwords (as reported by Prof. Eugene Spafford)…
Blog post: http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/Slashdot comments: [URL=http://it.slashdot.org/article.pl?sid=06/04/25/0033238&from= ……
April 26th, 2006 at 8:07 am
“Assume that the password policy is backed up by active and passive security systems that either do on-line monitoring and stopping (smart IPS) of attempts to do malice, or offline daily churning of log files on central logging servers and look for anomalies, report and act on it.”
Those are a *lot* of assumptions, Ariel. And unfortunately, folks who institute things like 30-day password change policies frequently do seem to treat that as the “pivot” of security… even when the problems that prompted it had little to do with password theft.
April 26th, 2006 at 8:48 am
“…which is more secure or at least better from a security perspective: changing passwords every month (or regularly) or do as you do, keep them the same for years?…”
Being forced to change a handful of passwords on varying schedules, one every couple of weeks, has brought me to the point of hardly ever knowning what the password for any one system happens to be that week. The only solution to that is an encrypted ODF document on my disk: Several times a week I need to bring up that document on my screen with ALL those logins, passwords, and security questions in plain sight on my screen to be able to log into one of those bloody systems here at work. Yes, I could keep multiple documents to lessen the exposure but with a system that’s grown into a road block I feel less and less inclined to invest my caring. That’s what it has come down to.
April 26th, 2006 at 11:53 am
I’m surprised only one feedback has mentioned the next step in authentication: hardware-based authentication. Chevron has completely converted over from a myriad of password databases to a singe sign-on based on smartcards. The details of the project can be found at http://www.networkworld.com/news/2005/103105-chevron.html.
April 26th, 2006 at 1:27 pm
[...] read more | digg story [...]
April 26th, 2006 at 4:38 pm
[...] [ More ] [...]
April 27th, 2006 at 1:23 pm
There’s one crucial flaw in the dismissal of password changing being a useful security measure against anything but cracking.
Attackers who manage to steal credentials don’t always use them immediately. In addition, they aren’t always able to (or interested in) promoting their stolen user level access to some kind of privileged access.
For example, we regularly see login attempts using the original password against accounts compromised years ago, even though the original compromise wasn’t detected for months.
Changing passwords puts an upper bound on the use of any given stolen password. That’s still useful even when the password is grabbed by a keylogger or a MITM at a wireless access point.
April 27th, 2006 at 1:46 pm
While I’m not against changing passwords per se…
The heart of the issue here is complexity relating to the human who is interacting with the system.
As the complexity of authentication increases, so does the likelyhood of a user resorting to a secondary means to remember his password, be that a slip of paper in his desk or an algorithm that can generate permutations of a base password, different enough to fool the security system into accepting it.
Most people can remember three passwords without too much difficulty, provided there are multiple neural pathways to the data. The pathways, in addition to the actual password itself, could be things such as an attribute of your pet, people you know, places you’ve been, or even a story weaved around the password.
As password complexity increases (such as requiring numbers or, even worse, punctuation), the likelyhood of multiple pathways diminishes, until you have only one way to remember it.
The less pathways you have, the more likely you will forget, and the more likely you will resort to a secondary means to remember the password.
When designing a security system, think about the PEOPLE who will be using it. Think about what they’re likely to do to cope with the complexity of your password authentication system.
And PLEASE, don’t try to change the people, because they won’t.
April 27th, 2006 at 2:42 pm
I think the core of the argument is that the act of too frequent required password changes results in a greater exposure to compromise than allowing an otherwise strong and uncompromised password to remain in place.
The two risks are undetected disclosure and cracking against the password hash. Undetected disclosure may require a longer window of time to take advantage of than the permited lifetime of the password, but then it may not.
With cracking the security of the hash and the use of strong passwords are the key factors here, dictionary attacks do not take long and users tend to think simple if they have to make frequent changes.
If the data is critical then you need to add another factor to the authentication method.
April 27th, 2006 at 3:21 pm
I agree. My home Linux system rarely gets the password changed. I only use that password on that system, I never enter it into a terminal I don’t trust, and it is never sent accross a network in the clear.
Whenever I set it, it is always at least 10 characters based on the first leter of every word in some sentence, with some of the cases shifted….
April 27th, 2006 at 10:32 pm
[...] Security Myths and Passwords Published April 28th, 2006 Tags: Asides, bestpractices, passwords, security. Security Myths and Passwords is a well written essay on the realities of forcing password changes every 30 days. Makes some very valid points however I do not believe that “best practices” should be disregarded as easily as being advocated here. (0) [...]
April 28th, 2006 at 4:53 am
The management of our multiple passwords is a well known issue and one must admit that their replacement by a centralized authentication token is unfortunately not for tomorrow.
Besides overloading administrators with requests of creation, destruction, locking or unlocking accounts, adding, assigning or withdrawing access rights, the anarchistic multiplication of passwords, generates another more serious problem, namely a decrease of security level.
For the sake of simplicity, we circumvent the recommended or imposed security rules. This chaotic situation constitutes an obstacle to our protection and the protection of our enterprise data and removes any reason of being for the use of passwords.
According to a study carried out on the behavior of the users, 50,8% of respondents are aware of the good practices in terms of passwords management BUT do not apply them.
Beside these well known issues, we have to deal with an additional parameter which is the mobility. Many of us are travelling, using more than one computer from different locations. In the same way, we need to access our application and web sites from everywhere, from every computer. This is why, I opted for an online password manager.
I’m using the online password manager PWMGR (www.pwmgr.com) for different reasons. I store there my passwords, PINs but also any kind of number I need to access from everywhere. I don’t need to be bothered with the selection of a new password since I can use the integrated password generator. When a new password is requested I simply asked PWMGR.COM to generate one based on my defined policy. I even don’t know some of my secrets anymore. I just go on-line, select the related entry and copy it to the application. Furthermore, I don’t have to be concerned by the backup of my data in case of disk crash as this service is provided by the PWMGR. It also allows me to align the required level of authentication ( simple or strong authentication) to the sensitivity of the data contained in each individual vault. It sends me a random PIN code on my mobilephone.
I would be interrested to know what other people thinks about PWMGR.
Cheers
D.
April 28th, 2006 at 6:44 am
[...] Excellent article by Gene Spafford about threads regarding password policies. Best article on the topic I’ve seen yet - and lots of wisdom to use for your own security related discussions. “From a high-level perspective, let me observe that one problem with any widespread change policy is that it fails to take into account the various threats and other defenses that may be in place. Policies should always be based on a sound understanding of risks, vulnerabilities, and defenses. “Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment.” [...]
April 28th, 2006 at 9:04 am
[...] Security Myths and Passwords [...]
April 28th, 2006 at 3:51 pm
Mitos y contraseñas…
Interesante texto sobre políticas de cambio de contraseñas , en inglés.Visto en barrapunto : http://barrapunto.com/article.pl?sid=06/04/28/1523213...
April 28th, 2006 at 7:01 pm
This premise seems plausible mainly because it discusses passwords in terms of shell login access, but I do not believe it holds in the modern networking world, where passwords control access to many types of resources.
Where a password is being used for shell or desktop access, there is usually a way for an intruder to establish a long-lasting foothold. Other types of systems, where shell access is not allowed, do not provide many such opportunities. For example, on a properly configured IMAP server, there is little chance for an intruder to establish a foothold that will last once the password is changed out from under him. Likewise for most web apps, VPN access, fileshares, etc. These are all services which see enhanced protection from frequently changed passwords, as it limits their temporal window of vulnerability. Most of the passwords in my life only control access to these no-foothold systems.
The points about frequent changes weakening password strength and leading to unsafe storage are well taken. The period of password change obviously needs to be chosen carefully to balance its benefits against such effects.
April 28th, 2006 at 9:03 pm
Best practice on password management…
This morning I read a good essay named "Security Myths and Passwords" by Prof. Eugene Spafford. Prof. Eugene told us his doubt on those best practices on password management policy, like "monthyly change", based on the i…
April 28th, 2006 at 9:05 pm
The defects and even failures in most of enterprise security defense systems can be root caused into problems in “security execution”, ie. the discrepancy between the policy and the real environment. The security manager just book those best practices into their “policy”, while not considering their staff, their skills, the data to protect, the threats to contain/mitigate…
April 29th, 2006 at 12:59 am
I’d always assumed that the password rotation meme came to us from things like military checkpoint passwords, where lots of people would have to know the same password. It can be assumed that the password will leak, given time; but it can also be assumed that Mallory/Eve can’t use the leaked password immediately, but must wait until other factors have come into alignment. Changing the password periodically does seem like it would help in that scenario.
April 29th, 2006 at 6:11 am
[...] En Security Myths and Passwords se habla de la política de cambio de contraseñas cada cierto periodo de tiempo. En: Seguridad — Abril 29, 2006 [...]
April 29th, 2006 at 3:22 pm
[...] Security Myths and Passwords: An excellent article discussing why changing passwords all the time isn’t security. If you read the “safe book”, read this. [...]
April 29th, 2006 at 10:43 pm
[...] One of my favourite topics is security mythology - that
April 30th, 2006 at 11:09 am
[...] Security myths and passwords I like this a lot. http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/ In the practice of security we have accumulated a number of “rules of thumb” that many people accept without careful consideration. Some of these get included in policies, and thus may get propagated to environments they were not meant to address. It is also the case that as technology changes, the underlying (and unstated) assumptions underlying these bits of conventional wisdom also change. The result is a stale policy that may no longer be effective…or possibly even dangerous. Policies requiring regular password changes (e.g., monthly) are an example of exactly this form of infosec folk wisdom. From a high-level perspective, let me observe that one problem with any widespread change policy is that it fails to take into account the various threats and other defenses that may be in place. Policies should always be based on a sound understanding of risks, vulnerabilities, and defenses. “Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment. Published Sunday, April 30, 2006 9:07 AM by steriley [...]
May 1st, 2006 at 12:49 am
[...] Password policies This was already written up earlier today on another TechNet blog but I wanted to make note anyway in case subscribers don’t digest the entire TechNet feed. Prof. Eugene Stafford posted an interesting write-up on password policy myths. Especially relevant to HE where passwords very often span longer periods of time. http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/ [...]
May 1st, 2006 at 11:47 am
How many people do I know who write down their password so they won’t forget it, as they rotate through the “change every x months” changes?
Well, let’s just say that the number is greater than the number of fingers and toes that I have. And that number does include me. So is it really more secure, or did we just socially engineer a security hole?
Additionally, the more random the password and the longer it is, the more secure it is. But who can reliably remember a 26-character alpha-numeric and symbol password?
May 2nd, 2006 at 7:11 am
[...] http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/ [...]
May 2nd, 2006 at 11:31 am
[...] A great article from Eugene Spafford on “best practices” regarding passwords. As I’ve stated a million times, passwords and the policies surrounding their use are nearly useless. OTP, biometrics, proximity, etc should be the standard we drives ourselves too rather than constantly thinking passwords are a safe form of authentication. Changing a password every 30 days does not make it secure! Check out Dr. Spafford’s article when you get a chance. Published in: [...]
May 4th, 2006 at 1:20 am
[...] CERIAS Weblogs » Security Myths and Passwords (tags: password security sysadmin) [...]
May 4th, 2006 at 5:41 am
Murphy was an optimist: It is never so bad that it cannot get worse.
May 4th, 2006 at 8:46 am
[...] Last week Bruce Schneier and others blogged about the Security Myths and Passwords paper written by Professor Eugene H. Spafford concerning the best practices or “rules of thumb” that many people accept without careful consideration, particularly policies requiring regular password changes (e.g., monthly). As someone developing a password policy requiring regular password changes, in my case 90 days, I understand his logic but also disagree to some degree. Until we can move folks to using, and also requiring, long passwords as a norm, requiring period password changes, not 30 days mind you, will still be necessary. [...]
May 4th, 2006 at 9:33 am
[...] Security Myths and Passwords …In the practice of security we have accumulated a number of “rules of thumb” that many people accept without careful consideration. Some of these get included in policies, and thus may get propagated to environments they were not meant to address. It is also the case that as technology changes, the underlying (and unstated) assumptions underlying these bits of conventional wisdom also change. The result is a stale policy that may no longer be effective…or possibly even dangerous. http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/ Urs [...]
May 11th, 2006 at 12:09 am
[...] Passwords and MythSecurity Myths and PasswordsWhat is Secure Software Engineering?ID Theft Resource [...]
May 11th, 2006 at 11:24 am
[...] Professor Spafford expounds on his previous article we talked about to say that we should examine all best practices to see which ones make since for a given application. My favorite example of this: [...]
May 15th, 2006 at 5:49 am
Thanks for bringing this up.
This whole area of ‘best practice’ for passwords disgusts me, because it is ‘our’ (IT inc’s) failure to provide a safe environment for passwords that requires users to jump through all these password hoops! The majority of the “…must be 12 characters long, with upper and lower case, etc, etc” requirement is because we haven’t been very successful in preventing attackers from managing to sniff comms, hijack protocols and snatch stored copies of the password. The other types of attacks, for instance, keystroke sniffers, social engineering, etc, are barely affected by doubling the size of the passwords or whether they get changed every month. Just because an admin (who has unrestricted access to the SAM/Shadow file) can break a password in ten minutes shouldn’t mean squat if the system has appropriate controls around that file to stop others getting direct acces to it plus a limit on the number of failed attempts through the legitimate interface.
In short, I think the policies we keep pushing are solving the wrong problem and, as you rightly pointed out, end up causing our ’solutions’ to break in another place.
Bank ATMs are an example of this working. With a 4 digit PIN they still are still effective at blocking an impersonater, even if the attacker has managed to copy or steal the card, since they still don’t have a means to brute force the PIN (all bets are off if they are skimming, shoulder surfing, or torturing for the PIN regardless of whether its a 4 or 40 digit PIN. That’s a different problem).
May 15th, 2006 at 6:00 am
I have my own password rules: http://softwarenerd.blogspot.com/2005/08/safeguarding-passwords.html
May 15th, 2006 at 10:59 am
I would just add a note about all the passwords we have to create and memorize that have nothing to do with security - at least, not OUR security. My password to the NY Times web site protects THEIR economic interest - either through ensuring all users have paid some fee or subscribed to some other paid service (the actual newspaper) - or theu targeted marketing based on my demographics - why I probably lied about anyway.
May 15th, 2006 at 9:07 pm
My thoughts exacly, The policy setting that forces passwords to contain at least 3 of 4 types of characters in windows at best only adds 3 bits of added entropy against a brute force attack assuming that only one character in each of the three categories is used. while simply increasing the minimum password length by 1 character will increase the entropy by 6 bits.
One can argue that it helps prevent a dictionary attack, as well as obfuscate the password a bit more for sholder surfers.
I contend that the added security of requiring shift modified characters in the password, does not equate the added keystrokes needed when typing it compare to lengthening a password by the same number of keystrokes.
Exo
June 6th, 2006 at 9:00 am
[...] A blog post by Eugene Spafford which examines password security, and the way that detrimental security practices sometimes get propagated because they’re considered by many to be “best practices.” http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/ [...]
June 6th, 2006 at 4:43 pm
In an organisation with a variety of applications and data security classification levels but a single Windows domain login and single AD authentication backend I have recommended policies that require strong passwords and regular (90 day) change.
However I believe that a primary issue is not password change per se but the quality of passwords. I am working on a plan to educate users on a largish (1000+) scale on ways of creating passwords that are memorable and that result in high quality passwords. Pass phrases combined with letter substitution give a password that is easily created, easily remembered, easily modified and not easily guessed or cracked.
User education is the key and trumps just about any technology or draconian policy any time.
June 19th, 2006 at 6:58 pm
I agree that changing your password once a month does not decrease the chance that a brute-froce algorithm would find it in a give amount of time. However, if, for example, an attacker gains access to your list of password hashes (I have seen these traded on IRC in the past) and it takes more than two weeks to crack these on his PC, then there is a better than 50:50 chance that the passwords he cracked are no longer valid.
The big problem is that it’s not going to take an attacker two weeks to crack your passwords, especially if you have unsalted hashes (rainbow attacks) or do not enforce minimal password complexity/length. Changing your password every day or two is just not an option.
There are essentially three ways to authenticate a person. Either by what they know, what they have, or what they are. Passwords are something persons “know”. A good authentication mechanism should use two or maybe even three of those methods. SecureID for example is something you have (the key fob) and something you know (your PIN) combined. Biometrics are an example of “what you are”. Since all these can be circumvented (with the possible exception of some biometrics), combining at least two methods gives you better protection. An attacker might crack a user’s password, but can they also steal that user’s key fob or irises?
I know this isn’t practical in most environments, but for highly sensitive data, a combination of methods should be considered.
By the way - passwords that can be entered on a standard keyboard (not counting Windows ALT combinations) are pretty limited in their keyspace. There are only about 90-ish characters on a keyboard. Not a huge amount of entropy for a 8-character password.
July 13th, 2006 at 11:03 am
[...] Security Myths and Passwords. This should be a must-read for all IT managers… that “change your password every 30 days” policy could well lead to less secure passwords and more time spent resetting lost ones — so why do it? [...]
August 1st, 2006 at 10:52 am
[...] Good blog posting on password rules, with an interesting speculation on how one of them came about: In summary, forcing periodic password changes given today’s resources is unlikely to significantly reduce the overall threat - unless the password is immediately changed after each use. This is precisely the nature of one-time passwords or tokens, and these are clearly the better method to use for authentication, although they do introduce additional cost and, in some cases, increase the chance of certain forms of lost “password.” [...]
August 15th, 2006 at 12:09 pm
Guys, try out Securepass from http://www.securenez.com. Been using it for about a month. Seems the program acts upon all the recommendations of security experts and what is mentioned in this blog regarding password policies.
These guys stress a lot on replacing exisiting password with system generated password for enhanced security. Also say that they never store passwords anywhere, making them undetectable. Also support one click login on Internet Explorer (too bad this feature does not work with Mozilla - called them, the company said it is coming soon)
Can someone else also try the product out and write about it for benefit of others.
August 21st, 2006 at 12:04 am
FirstEuropa.com - tu corredor de seguro en l
August 21st, 2006 at 3:28 am
I disagree that this is a *good* essay. I think the subject is an important one that should be treated, but this essay did a poor job.
The author stated his premise at the beginning, then wandered off to survey ways that passwords can be compromised. Finally, in the last few paragraphs he came back to his premise, but didn’t really present any hard evidence to support it.
IMHO this is just the start to a treatment of this subject. It is an important subject, though, because so many who don’t thoroughly understand security DO rely on ‘best practices.’
I think once before you advised (paraphrasing) “Use secure (i.e., non-trivial) passwords, then write them down somewhere–this is better than using more memorable ones that are easily guessed.” This, to me, is the most practical advice I have heard in a long time. I think it may apply here; change your passwords occasionally (not necessarily every month) and if you have to, write them down somewhere secure.
September 1st, 2006 at 2:59 am
[...] A blog post by Eugene Spafford which examines password security, and the way that detrimental security practices sometimes get propagated because they’re considered by many to be “best practices.”read more | digg story [...]
October 3rd, 2006 at 6:02 pm
[...] Security myths and passwords I like this a lot. http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/ In the practice of security we have accumulated a number of “rules of thumb” that many people accept without careful consideration. Some of these get included in policies, and thus may get propagated to environments they were not meant to address. It is also the case that as technology changes, the underlying (and unstated) assumptions underlying these bits of conventional wisdom also change. The result is a stale policy that may no longer be effective…or possibly even dangerous. Policies requiring regular password changes (e.g., monthly) are an example of exactly this form of infosec folk wisdom. From a high-level perspective, let me observe that one problem with any widespread change policy is that it fails to take into account the various threats and other defenses that may be in place. Policies should always be based on a sound understanding of risks, vulnerabilities, and defenses. “Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment. Published Sunday, April 30, 2006 9:07 AM by steriley Filed under: identity, authentication, security policies, passwords, security myths [...]
October 18th, 2006 at 12:37 pm
I have a question that I would like someone to address:
Single username/password for a 600 family online church directory vs 600 individual username/passwords generated by church members.
A church directory is a public directory but can be limited to the congregation.
I recommended a single username/password to be distributed to the membership through a letter to each family.
There are others that feel that a single username/password is not sufficient and propose individual username/passwords to each of the 600 familys.
My contention is that with one username/password I can make it a strong password. With 600 individual username/passwords allowing each to reset their passwords I know there will be weak passwords.
I contend that it is like a door with a combination lock which has one combination to allow ingress as compared to one door with a combination lock with 600 combinations that will ingress into the same room. Which is the most secure???? With more username/password combinations the security goes down. Admittedly, neither is high security because all one has to do is place their membership and they will be given the access code.
I certainly would appreciate some outside comments and or suggestions where I might find more information.
Thank you,
Orvis Pigg
October 19th, 2006 at 7:07 pm
Orvis,
Having multiple accounts is definitely better from a management point of view. If one is compromised or abused, you can deal with it individually rather than shutting off access to everyone (as would be the case with a single account).
–spaf
October 24th, 2006 at 4:25 am
I quite agree with the author’s thoughts about passwords. I think it is necessary to change it, to increase the number of characters in a password and allow using not only letters or numbers or symbols, but to use all of them at once, by mixing them. Of course the most sensitive data should be more protected and the password should be changed in shorter periods of time.
I would like very much to have something new to protect my data as soon as posiible.
October 24th, 2006 at 4:25 pm
[...] Helen: I quite agree with theSpaf: Orvis, Having multiple accounts is definitelyOrvis Pigg: I have a question thatElizabeth: Nice site… Cool guestbook…I [...]