Security Myths and Passwords

Page Content

Share:

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

Comments

[...] http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/ [...]

Posted by Nothing here » Blog Archive » Spaf on on Tuesday, April 25, 2006 at 05:37 AM

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.

Posted by Scott on Tuesday, April 25, 2006 at 08:53 AM

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.

Posted by Mike L. on Tuesday, April 25, 2006 at 09:30 AM

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.

Posted by Medievalist on Tuesday, April 25, 2006 at 10:20 AM

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.

Posted by David LeBlanc on Tuesday, April 25, 2006 at 12:45 PM

[...] CERIAS Weblogs » Security Myths and Passwords (tags: security password toread) [...]

Posted by dEOS » links for 2006-04-25 on Tuesday, April 25, 2006 at 01:20 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”

Posted by Lupes on Tuesday, April 25, 2006 at 01:39 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 ” [...]

Posted by Slashdot Review » Blog Archive » SDR P on Tuesday, April 25, 2006 at 04:52 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)

Posted by MB on Tuesday, April 25, 2006 at 06:00 PM

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.

Posted by Didier Godart on Tuesday, April 25, 2006 at 09:58 PM

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.

Posted by Kev. on Tuesday, April 25, 2006 at 10:03 PM

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)

Posted by Elvis on Wednesday, April 26, 2006 at 12:14 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

Posted by ArielIL on Wednesday, April 26, 2006 at 01:57 AM

<strong>Security myths and passwords (as reported by Prof. Eugene Spafford)...</strong>

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

Posted by Digital identity links on Wednesday, April 26, 2006 at 02:30 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.

Posted by Ed Finkler on Wednesday, April 26, 2006 at 03:07 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. :(

Posted by anonmous on Wednesday, April 26, 2006 at 03:48 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.

Posted by Dario Alcocer on Wednesday, April 26, 2006 at 06:53 AM

[...] read more | digg story [...]

Posted by PurpleSlog » Blog Archive » Security M on Wednesday, April 26, 2006 at 08:27 AM

[...] [ More ] [...]

Posted by Passguard Blog » Blog Archive » Securi on Wednesday, April 26, 2006 at 11:38 AM

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.

Posted by Richard Johnson on Thursday, April 27, 2006 at 08:23 AM

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.

Posted by Somebody on Thursday, April 27, 2006 at 08:46 AM

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.

Posted by arl on Thursday, April 27, 2006 at 09:42 AM

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

Posted by Phillip on Thursday, April 27, 2006 at 10:21 AM

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

Posted by Security Myths and Passwords at jarkolicious on Thursday, April 27, 2006 at 05:32 PM

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.

Posted by Kev. on Thursday, April 27, 2006 at 11:53 PM

Leave a comment

Commenting is not available in this section entry.