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
• Encryption Options
• Filters and Administrator Assigned Passwords
• Cracking Your Own Passwords
• Distributed Password Cracking
• Cracking Flaw
• Pluggable Authentication Modules
• Reverse Transformation

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."⁴ 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.