Good and Bad Passwords How-To
Review of Practical Steps and Common Recommendations
for Improving Password Security
The steps that a system administrator can take to make it more
difficult for a cracker to obtain password hashes and crack the
passwords they represent are covered. The author does not believe
the widely recommended approach of system administrators cracking
their own password files represents an effective use of limited resources
and explains why. The author believes the most effective future
approach to ensuring that users select strong passwords is the
enhancement of Pluggable Authentication Modules and a more thorough
analysis of plain text passwords before they are encrypted. The
enforcement tool should reverse the transformations that cracking
tools perform and disallow any password that results in a dictionary
word.
Administrator Passwords and Securing the Hashes
An administrator needs to understand passwords well enough to
be sure his or her own account and root or administrative
accounts have truly strong passwords that can't be cracked.
The single most important step an administrator can take on any
system he or she is responsible for is to ensure that strong
passwords are created for root and administrator accounts, using
the knowledge of how password cracking attacks work. Accounts
that can escalate their privilege level to root or administrator
via su or other similar mechanisms, should have comparable
password protection. Provide training and encourage users to use
good passwords within the limits of available resources.
Reduce the exposure to the various ways that the bad guys
can get your password files. If they can't get the hashes, they
can't crack your passwords. Start with physical security.
Secure both your computer room and backup storage. Use a
reputable company with bonded employees for offsite storage.
Keep the number of employees with administrative access to a
minimum, giving such access to employees on a system by system
basis as necessary for each employee to do his or her job.
Review the Ten Practical Security Steps
. In particular unneeded services, buggy services and
services not protected by a well configured firewall are the most
likely routes for outsiders to get administrative access on your
systems. Web servers running with excess privileges and buggy
applications have let outsiders do just about anything and
everything you don't want them to do.
Focus energies on ensuring that systems can only be accessed from
legitimate locations. Then set up systems so that unprivileged
accounts that may have lousy passwords, can't do any real harm to
the system.
Establish a schedule for changing all administrator passwords at
approximately the same time. Change all administrator passwords
when any administrator leaves. Nobody represents a bigger threat
to your systems than an administrator departing under unfavorable
circumstances. If you have to terminate an administrator, while
they're getting the bad news, change all administrator account
passwords and disable all individual accounts for the departing
employee. They should have no access to any computer system by
the time the meeting is over, which may not be very long.
Encryption Options
Some operating systems give the administrator useful options that
are not widely available. On Linux, bigcrypt or MD5 may be
substituted for the old standard, crypt(3). MD5 has been the
default on Red Hat Linux systems for several versions. On
OpenBSD, an administrator can chose between three encryption
algorithms. With the default Blowfish method, a loop count can be
controlled in the passwd.conf file. Each increase in the loop
count, up to 31, approximately doubles the amount of time it
takes to calculate the hash. The default for ordinary users is 6
and for root, 8. These values will give acceptable login
performance on a slow 486. On a P3 500 that's 0.03 second for an
ordinary users and 0.12 seconds for root. If these values are
increased to 11 and 12 respectively an ordinary user will
experience a 1 second delay when logging in and root a 2 second
delay. Someone trying to crack the passwords would need to spend
16 times as long to get the same passwords for ordinary users and
8 times as long for root compared to the default install. This
is just for changing four characters in a config file - and
accepting a small but perceptible delay when logging in. Each
site can decide what an acceptable delay is, then based on the
machine speed, set the loop count accordingly. Periodic changes
to the hashing algorithm, helps compensate for ever increasing
CPU speeds.
Filters and Administrator Assigned Passwords
It can't hurt to use a filter that operates in real time and enforces
some level of length and complexity on the passwords users assign
themselves. Just don't count on it to do much, because it's too easy
to create bad passwords that pass the checks. These filters remind
the more informed and conscientious users that they are supposed to
pick good passwords.
Some sites assign user passwords. Assigning passwords and
disabling the ability for users to change their own passwords
is probably the only way to maintain tight control over user
passwords and insure that all conform to any standards that
may be in place.
Personally, I think this is worse than the problem that's trying
to be solved. It's a major maintenance pain if passwords are
changed on any kind of schedule. The users won't like the
assigned passwords and will write them where they shouldn't.
Most important, it eliminates accountability. If IT staff know
users' passwords, then users can reasonably deny any activity
performed via their accounts because they can legitimately say
others know their password.
Cracking Your Own Passwords
Probably the most common suggestion is to run a cracker
periodically on your own password files and require users with
weak passwords, to change them. Frankly, I think this is a
pointless administrator power trip. It's one thing for a user to
be told by system software their password is not acceptable
because it's too short or simple or similar to their previous
password. It's quite different for the same user to be told by a
system administrator, some time after they have been using the
password, that it is not acceptable and must be changed.
If a user is forced to use a password they don't think they can
remember, you're back to the post-it problem or worse. On systems
where users change their own passwords, it's hard to stop a user from
changing it back to something they like a few days after they are
forced to change it. I hope I'm not the only one that sees something
wrong with threatening such users with disciplinary action. A minimum
time period between changes is required in addition to a maximum time
period passwords are allowed to go unchanged. The system will also
need to keep a meaningful password history (8 or more previous
passwords) to prevent users from toggling between two favorite
passwords.
Cracking your own password files may create a sense of distrust
between users and system administrators and is a labor intensive
process with no end. Also, it will significantly undermine
accountability much like assigned passwords; no one but the
administrators can know whose passwords they know and any dispute over
who used an account to perform some action becomes IT staff's word
against other employees. There is also an issue with lag time, i.e.,
the bad passwords in use between checks.
Even if none of the preceding were true, there is a fundamental
technical problem with administrators cracking their own
password files to find bad passwords. The essence is that no
checking that you can do can possibly tell you that your systems
have strong passwords; it can at best confirm that they do not
have obviously weak passwords.
Cracking passwords is a CPU intensive activity that requires
considerable skill to do well. Computers in business are
purchased to perform needed processes. It's unlikely that
cracking processes can be run for hours or days without
interfering with the computer's real functions. The preceding long
discussion, working from simple to increasingly complex
passwords, should have made it clear that there is a large gray
area between obviously weak passwords and truly strong passwords.
At one end are those that will fall on the first run of a
cracking tool installed with a default dictionary. At the other
are those that will not be cracked with today's technology
because of their length, character diversity and absence of
dictionary derived words.
An administrator is unlikely to have the time to develop
skills to get meaningfully beyond the default install stage. If
they did, they still wouldn't have the necessary computing
resources. A cracker on the other hand will be using larger
dictionaries, more sophisticated rule sets and apply whatever
resources they have available to cracking their target systems.
The cracker may even be able to use resources that aren't theirs.
It's hard to see how a skilled cracker would not get passwords
the administrator could not.
Distributed Password Cracking
A new feature in the Windows NT and 2000 password cracking tool,
LC3, which has replaced l0phtcrack 2, allows multiple computers
to be used on the same password audit. Regardless of any
licensing or technical issues that may exist in the details of
the LC3 implementation, this does suggest an approach that could
fundamentally alter the balance of power between crackers and
their victims. This is to effectively apply the enormous unused
CPU capacity represented by business desktop machines, that are
typically used less than 40% during the work week and less the
30% of the total time, to password cracking.
When I first wrote this section (early June 2001) I focused only on
the technical possibilities of cracking tools with built in
distributed cracking features. Further reflection suggests the costs
of implementing an internal cracking project on the scale suggested
here would significantly outweigh any perceived benefits. A company
improving its security infrastructure, would likely choose alternative
approaches, thus the rest of this discussion is largely academic in
nature. The practical benefit of distributed password cracking tools
is still more likely to go to the intruders than the defenders.
What I said in the previous section was largely based on the
assumption that administrator use of cracking tools would be used
on the machine, typically a server or multi user host that was
being password audited. Though Dan Klien used multiple machines
for his research in 1991 and I've suggested that crackers could
effectively use multiple machines, I was assuming relatively
complicated manual setups such as either splitting the
dictionaries being used or if brute force was being applied,
changing the configuration files that controlled the starting
point in the generated sequences. This is fine for a researcher
or a cracker but not practical for a system administrator who is
not likely to be an expert in the use of the cracking tool.
Distributed password cracking would work best in an NT domain
environment or a centralized directory environment where numerous
computers are authenticating from a centralized authority. It
could be used in a workgroup environment or a traditional UNIX
LAN where individual workstations coexist with servers and multi
user hosts, each using it's own authentication. In such an
environment it would be the server or host password files that
would be checked. The more centralized the password
administration and the larger the ratio between available desktop
computers to password repositories to be checked, the more the
advantage potentially shifts away from crackers and back to their
victims.
Effective use also requires a solid implementation in the
cracking tool that allows flexible scheduling of both starts and
stops on both the controlling machine and any helping machines.
The cracking tool should detect other use of computers on which
it is running and reduce or suspend its demands on the CPU. For
distributed cracking to be practical, the controlling computer
would need to be able to automatically deal with helping
computers of widely varying speeds. It might have a means of
accurately estimating the processing capabilities and handing out
work to keep them busy for the expected duration. This would
create serious problems with how to handle the holes in the
dictionary when any computer failed to return the expected work
due to either a crash or change that consumed resources so that
the helper could not complete its task in the expected time. Handing out
small work units and estimating the ability of helpers to process
them would greatly reduce a problem with any holes in the
dictionary. No helper would get any more work units that could
not easily complete in the remaining time. The smaller the work
units, the greater would be the management overhead.
Distributed password cracking could solve the issue of a server
not having sufficient resources to check its own passwords and
still perform its core functions. It would not solve the
dictionary or administrator skill level issues. To insure that
the real value of the distributed feature could be realized, the
cracking tool would need to include both a large dictionary and
complex rule set. As these would be available to the crackers as
well, the only way to provide a real advantage to most potential
victims would be to include dictionaries and rule sets so large
they could not be processed on a single or a few computers in a
short time. I am assuming that the institutional victims of
crackers will typically have significantly more idle desktops
that could be used than would normally be available to crackers.
For example, the dictionary and ruleset might take 50 days to
process on a single fast contemporary desktop machine. Assuming
that business desktops were used 12 hours a day, week days only,
and that the distribution was entirely efficient so that linear
results are obtained for each machine added to the project, this
would require 100 comparable desktop machines, to process the
entire dictionary and ruleset in one night. A single night would
be optimal, so that users would be informed at the begining of
each business day, of any poorly chosen passwords that they chose
the previous day.
The dictionary and rules would also need to be segmented in some
fashion, so that organizations with different available resources
could, use as much as they could handle without leaving gaps.
Provided that the segmentation was reasonably small, the bigger
the dictionary and ruleset, the better. The more there was to
process, the bigger the advantage an organization with a really
large number of available desktop systems, would have over
potential adversaries. Without sufficiently fine segmentation, a
small organization might not be able to find a suitable size
dictionary and rule set to use.
If all the technical issues can be adequately solved, there remain
some management issues. IT might propose such a project, after
determining the appropriate tools were available. The non IT
staff must not perceive this as coming from IT or it's likely to
create tensions between IT and other staff. Something like this,
has to come from the top and staff must know that management sees
it as an important issue, with IT only being the implementer.
The project would have to include user training, also backed by
management. Generally cracking approaches reveal that passwords
are weak but don't identify why. The users would need to know how
to create passwords likely to not be successfully cracked.
Further, users need to know any policies regarding writing
passwords down and what to do if they forget a password. If they
have good passwords and don't write them down, there will be many
more forgotten passwords and IT will need to deal with these
quickly.
Used frequently, such as daily on an ongoing basis, the
accountability issue, would become self correcting. After a few
days, almost no one would have passwords that were being cracked,
at least if the training were adequate. Those who did would be
responsible for changing them quickly. Failure to do so would
become the user's problem and not IT's.
Cracking Flaw
There is a fundamental logical flaw in all the cracker like
approaches to assuring good passwords, regardless of when they are
done or how thorough they attempt to be. A cracker has password
hashes and tries to get the plain text of the passwords with
computationally intensive methods because that is all that
is available, unless the encryption algorithm is flawed and
can be reversed.
Even if most of the issues can be solved with distributed
cracking as suggested in the previous section, this is obviously
a major task requiring the effective use of a large portion of an
organization's under used computing capacity. Even if the system
can catch moderately strong but not truly strong passwords, it's
not likely able to tell users how to fix them. The simple fact
is, that before the password in accepted and encrypted, we have
the plain text that is the sole objective of the cracker's
methods.
It seems to me, that the correct approach is to analyze the
plain text password, to ensure that the only practical approach to
breaking each potential new password, is brute force. The simple
filters that check if a password has an upper and lower case
letter and a digit or punctuation are conceptually addressing the
correct problem. Their implementation is inadequate
to accomplish much.
In 1991 Daniel Klein recognized the problem and proposed doing
the checking at the time the user
created their password and before it was accepted. He said "Because
this proactive checker will deal with the
pre-encrypted passwords, it will be able to perform more sophisticated
pattern matching on the password, and will be able to test the safety
without having to go through the effort of cracking the encrypted
version. Because the checking will be done automatically, the process of
education can be transferred to the machine, which will instruct the
user _why_ a particular choice of password is
bad."4
This pretty much solves the password problems: it lets the
user's pick their own passwords and ensures that users can
never give themselves a weak password; it is not resource intensive;
it removes the administrator
from resource intensive, police like activities; and it eliminates
the lag between checks,
Unfortunately no one seems to have understood the importance of what
Dan Kline said, at least not well enough to actually include such
mechanisms in a real operating system. I know that I missed the point
when I first read the paper, even though it's quite clear. I wrote
most of this page in 2001 and did not realize until I got an email
from Dan Klien in 2005, that he had made the fundamental point in 1991,
even though I'd read and cited his paper.
Pluggable Authentication Modules
Some systems support password checking that goes well beyond simple
filters. Specifically, systems that support Pluggable Authentication
Modules (PAM) have at least two options for checking the structure of
plain text passwords before they are encrypted. Sun and Linux support
PAM. Pam_cracklib performs a number of tests on a user's intended new
password including length and character diversity and similarity to
the user's previous password. It also does dictionary lookups using
the same dictionary used by Crack 5. Though pam_cracklib checks that
the new password is not the reverse or case variation of the old
password, it's not clear that any other transformations are
performed to determine that the password is not a simple
transformation of a dictionary word. Thus Attack1 might work for one
password change and Barking2 for the next. Pam_passwd+ performs
different checks. It can test against files, contents of the GECOS
field in the /etc/passwd file and has extensive pattern definition
capabilities.
What is needed, is the ability to take a user entered password and to
do a reverse transformation of what Crack and John the Ripper do to
dictionary words; if the reverse transformed password matches a
dictionary word then the result should not be acceptable. It is clear
that pam_passwd+ can take GECOS field information and perform the
checks necessary to prevent user account and name derived information
from being used as passwords and thus deny John the Ripper one of its
strengths. Pam_passwd+ looks like it has some of the necessary
capabilities for transforming dictionary words but it's not clear from
the cryptic and example poor documentation that it has all or even a
useful subset of what is needed.
The checks of pam_cracklib and pam_passwd+ can be stacked so that
an intended new password has to pass all the tests from both
modules before it is accepted. For those who run systems
that support PAM and want to force users to use better passwords,
PAM looks like the best bet currently available.
Reverse Transformation
I've developed a proof of concept Perl script,
password evaluator, that does
the necessary transformations on a supplied password, to see if
any dictionary word or words can be mangled to get the password. So far
it looks feasible but is over 1600 lines and grows each time I
think of a variation that's not been covered. It still has many
rough edges and is not tied into any operating system
password changing mechanism.
Some transformations are computationally intensive such as
reversing the dropping of one or two characters anywhere in a
long word. This results in 702 lookups for each character in the
password plus one. (26 + 26 * 26 before each letter plus following
the last.) There tends to be an inverse relationship
between the ease with which a cracking tool can apply a
transformation to a dictionary and the ease with which that
transformation can be reversed.
Thus, it's almost prohibitive for a cracker to append arbitrary
three character sequences to every word in the dictionary but
trivial to strip any three non alpha characters from a supplied
password. It's very easy for a cracker to drop all the vowels or
consonants from each word as there is one result per dictionary
word. Attempting to reverse this would create (5**3)**(n+1)
possibilities for dropped vowels and at least (21**3)**(n+1)
possibilities for dropped consonants where 'n' is the number of
characters left in the result.
Fortunately individual lookups do not need to be performed as the
same result can be achieved by creating an appropriate regular
expression and sequentially processing the entire dictionary in
the form of a simple text file. For now I've chosen an easy out
and label any password with only vowels or consonants greater
than an allowed number as an error.
It's surprising how some passwords that appear to contain
completely arbitrary character sequences actually contain
reversed and rotated or keyboard shifted dictionary words.
Keyboard shifts in particular require working through a
character at a time to see how a dictionary word can be
transformed into the password result.
I think the best answer to ensuring that user's use strong passwords
is to incorporate logic like that in the
password evaluator into PAM
modules or other programs tied into the password changing
mechanism. With the default settings, I am trying to eliminate
any password that can be created from a dictionary listing or
multiple dictionary words, even with multiple transformations.
A number of 6 and 7 character passwords containing at most 1
dictionary word that is less than 66% of the total password
length will be accepted to satisfy ordinary users. These
have a relative strength rating of 0 and can unquestionably
be cracked with brute force by any cracker who chooses to apply
the necessary resources. Longer passwords may contain one
dictionary word that is less than 66% of the total password
length and still have a respectable strength rating.
Top of Page -
Site Map
Copyright © 2000 - 2014 by George Shaffer. This material may be
distributed only subject to the terms and conditions set forth in
https://geodsoft.com/terms.htm
(or https://geodsoft.com/cgi-bin/terms.pl).
These terms are subject to change. Distribution is subject to
the current terms, or at the choice of the distributor, those
in an earlier, digitally signed electronic copy of
https://geodsoft.com/terms.htm (or cgi-bin/terms.pl) from the
time of the distribution. Distribution of substantively modified
versions of GeodSoft content is prohibited without the explicit written
permission of George Shaffer. Distribution of the work or derivatives
of the work, in whole or in part, for commercial purposes is prohibited
unless prior written permission is obtained from George Shaffer.
Distribution in accordance with these terms, for unrestricted and
uncompensated public access, non profit, or internal company use is
allowed.
|