Security Myths and Passwords

Page Content


(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. grin

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.]


I suggest this be discussed further in sci.aquaria.passwords.

Posted by rich@gryphon on Monday, April 24, 2006 at 07:46 PM

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.

Posted by moof on Monday, April 24, 2006 at 08:35 PM

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.

Posted by Lance on Monday, April 24, 2006 at 08:51 PM

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.

Posted by Actual User on Monday, April 24, 2006 at 08:57 PM

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 <i>don’t</i> know about.  And may never know about.  But you can still limit their damage.

Posted by Wade Tregaskis on Monday, April 24, 2006 at 09:24 PM

I wonder how many people deploy the “change passwords once a month” as an audit checkbox to be ticked?

Posted by Jake on Monday, April 24, 2006 at 09:31 PM

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. 


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.

Posted by Aze on Monday, April 24, 2006 at 09:31 PM

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.

Posted by Erik N on Monday, April 24, 2006 at 10:06 PM

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.

Posted by JPP on Monday, April 24, 2006 at 10:09 PM

P.S. you just got slashdoted.

Posted by JPP on Monday, April 24, 2006 at 10:11 PM

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.

Posted by Movieman on Tuesday, April 25, 2006 at 12:22 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.

Posted by Disgruntled on Tuesday, April 25, 2006 at 12:26 AM

[...] CERIAS Weblogs » Security Myths and Passwords [...]

Posted by Deep Codes » Spafford on Security on Tuesday, April 25, 2006 at 12:40 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.

Posted by Ben Robinson on Tuesday, April 25, 2006 at 01:04 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.


Posted by Dom De Vitto on Tuesday, April 25, 2006 at 01:08 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. [...]

Posted by · Don’t Change Your Password on Tuesday, April 25, 2006 at 01:13 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?

Posted by Saumil Shah on Tuesday, April 25, 2006 at 01:16 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.

Posted by jfd on Tuesday, April 25, 2006 at 01:41 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.

Posted by jps on Tuesday, April 25, 2006 at 02:00 AM

welcome slashdotters!

Posted by slashdotter on Tuesday, April 25, 2006 at 02:17 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”.

Posted by Rodney on Tuesday, April 25, 2006 at 02:24 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.

Posted by Kevin Kenny on Tuesday, April 25, 2006 at 02:35 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.

Posted by Chris on Tuesday, April 25, 2006 at 03:52 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.

Posted by Paul Coen on Tuesday, April 25, 2006 at 04:05 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!

Posted by Robert Meyer on Tuesday, April 25, 2006 at 04:14 AM

Leave a comment

Commenting is not available in this section entry.