GeodSoft logo   GeodSoft

Good and Bad Passwords How-To

Basics of Password Encryption and Storage; Definitions of Terms

Password Encryption and Storage

Until the late 1980's UNIX systems stored user's encrypted passwords, usually referred to as hashes in the file /etc/passwd. These hashes are generated by using the user supplied plain text password as a key to an encryption algorithm that encrypts a constant and creates a resulting gibberish string (hash) which is saved. When the user next logs in, their password is passed through the same encryption process and if the result equals the saved hash, the user is allowed entry since they provided the correct password.

Though encryption algorithms have changed over time and may differ from one operating system to the next and the resulting hash is stored in different locations for different operating systems, the basic approach is pretty much universal.

The encryption algorithms are one way. There is no known way to take the hash and reverse the algorithm to derive the password. Passwords can be guessed though. If a test password is passed through the encryption algorithm and the resulting hash is the same as the stored hash, then the password has been successfully guessed.

UNIX systems' /etc/passwd file is world readable. Anyone who gains any kind of access to a machine can copy the passwd file and move it off the system by any means that might be available to them including e-mail, FTP, NFS or floppy disk. The attacker can then attempt to crack (systematically guess) passwords at their leisure; the methods will be discussed latter.

In the late 1980's Sun began using a shadow password file which was not world readable. The password hashes were no longer placed in /etc/passwd but the shadow password file, often /etc/shadow, which should be readable only by root. The /etc/passwd file was retained with the other less sensitive information so that programs that needed the other non password information could continue to run without modification or special privileges. The few programs such as login and passwd that actually need the password hash, have special privileges so that ordinary users can run them. Today virtually all UNIX systems use or can use shadow password files, though they may not be called shadow. Any system that doesn't, should be configured to do so, upgraded or replaced.

Windows NT systems never had the specific vulnerability of a world readable password file. NT passwords are stored in part of the registry known as the SAM. Windows 2000 passwords may be stored in the SAM or the directory if Active Directory is enabled. These are in continuous use, i.e. held open, by the operating system as long as it's up, so the SAM or directory can never be accessed as an ordinary file. They must be accessed through an appropriate API, which is implemented in various utility programs. Access to security sensitive information typically requires system or administrator level access.

Security of the Password Hashes

Though the current situation is much better than the early UNIXs, it's naive to think that the password files are secure just because they can't be read by every user as an ordinary file. On UNIX, anyone with root access can read the shadow password file as an ordinary file and on NT regback from the NT Resource Kit will make a perfect copy of the SAM while it's open by the system. Also pwdump, a small free utility, can copy the account and password hashes from the SAM to a text file that can be fed to cracking programs. NT system recovery disks provide another simple way to export the SAM data.

Thus staff with adminstrative access, who are not honest, can easily provide the necessary account names and password hashes to a potential intruder who has provided an appropriate inducement. A departing administrator can take or transmit this information and subsequently use it to crack passwords they would not normally have had access to; passwords on all administrative accounts should be changed whenever there is adminstrative staff turnover.

Generally, unless they are misconfigured, modern systems require that a user or process already have root or administrative access before the user account and password hash information can be obtained. The following examples show, this does not necessarily mean possession of a valid root or administrator password and the ability to log on.

Most sites have some form of off-site backup storage. The backups will have the necessary information, which is rarely protected by anything other than the physical security of the backup media. Thus off-site backups are as protected or vulnerable as the honesty and procedures of the off-site storage company and its employees make them.

Backups kept on-site will be as secure as the physical storage of the media. A locked computer room loses much of its value if an employee can pocket a DAT tape from an unsecured area. Backup media should not be stored in immediate proximity of the machines they backup, lest an event that compromises the machines also compromises the backups. Backup media should be stored in a physically separate but secured area.

Anyone with physical access to the hardware can obtain the accounts and password hashes. UNIX systems can be booted to single user mode and NT / Windows 2000 systems can be booted via a Linux floppy that understands the NTFS file system and containing tools for copying or updating the SAM.

There are at least two classes of remote exploits that apply to both UNIX and Windows systems. These are buffer overflows that allow the execution of arbitrary commands and application level errors in services; the specifics are system dependent.

Various services, usually running as root or system have had buffer overflow bugs on both UNIX and NT. Prior to 2001, there were more of these on UNIX systems than on NT. In 2001, several worms and viruses affected hundreds of thousands of windows systems, exposing them to remote administrative compromise. Wherever words like the "execution of arbitrary code" appear associated with buffer overflows, obtaining the password hash information, either directly or indirectly, is at least a theoretical possibility.

A good example of an application level bug is one that allowed a remote user to send commands to sendmail that caused sendmail to e-mail the /etc/passwd file to the remote user. Today the most frequent application level errors are with poorly configured web servers running buggy web applications. Most often these result is defaced web sites but depending on the specifics of the misconfiguration and the bug, just about anything is possible, including root level compromises and exporting password hash data. NT has had many more problems of this nature but UNIX enough that UNIX administrators have no reason to feel smug or secure.

Having a backup tape or system recovery disk gives an attacker access to data but not direct access to a system. A buffer overflow is likely to provide a means of entry, but not necessarily ongoing access. An intruder will normally want to obtain passwords to root or administrator accounts. This is likely to ensure that an intruder who is in a position to obtain the password hashes will have full access to the compromised system for some time.

Good, bad, weak, strong defined

A weak password is any password that can easily be guessed or cracked. A strong password is difficult to crack or guess. These are relative and unless the password was created in a defective manner, the strength of a password can be calculated mathematically. A password can be so weak it can be cracked in a fraction of a second or so strong that billions of millennia of CPU time should be required. Most of what follows examines the deficiencies that make a superficially strong password, weak. All relate to how humans think and select or create passwords.

A bad password is one that is too weak for the resources it's supposed to defend or that is too difficult for users to use and remember. A good password is a strong password that's reasonably easy to remember. Identifying specific characteristics that make a good password is more difficult than those that make a bad password. Since there is a significant degree of mutual exclusivity between these goals, part of defining good passwords is figuring out what if anything can make a password both easy to remember and hard to guess or crack. Some of the characteristics that make a password easy or hard to remember will be discussed.

Password relativity

How good or bad a password is, depends to a significant degree on what it's protecting and who is using it. People have varying memory capabilities so what may be easy for one person may be difficult for another.

More important is the variability of the value of the resource a password protects. On any computer system, the adminstrative or root password is of much greater value than that of an unprivileged user account. Different computers and systems have greatly varying values. Computers that manage financial information such as at banks and brokerage houses and very sensitive information such as patient records at hospitals are more valuable and require a greater degree of protection than for example, the mailing lists of a mass marketer or the sales records of a local retail store. Most users are likely to consider their Amazon or other online retail account that includes credit card numbers more important and sensitive than the password to a Hotmail or other disposable web based e-mail account. The password to a site such as a portal, that the user has spent much time customizing may be somewhere in between in sensitivity.

Cracking defined

Cracking means running a program that guesses large numbers of passwords against a file containing account names and password hashes. The file is a UNIX passwd or a shadow password file or extracted from the SAM on NT. The program repeats the encryption algorithm that was used to encrypt the user's plain text password. It uses a dictionary or other list of plain text passwords such as list of common passwords and encrypts these. If the result matches the hash stored in the password file, then the password has been cracked. The cracking program may also make permutations of the dictionary list such as appending or prepending digits. It may also extract the user's account, name or title from the password file and make combinations and permutations of this data to guess passwords. Cracking programs normally have a brute force method that generates potential passwords.

Guessing defined

Guessing is an interactive or automated attempt to logon at a terminal or via telnet or other remote access method. Users tend to pick easy to remember passwords which will often be as short as the system permits. Easy to remember often means things that relate to the user in some fashion as listed later. Also there are some very common passwords such as pass, password, admin, and the company's name or acronym.

Guessing is likely to be more successful if the attacker knows something about the users whose accounts they are trying to get into. Some of the information commonly used to create poor passwords is in public records such as phone books. Sometimes the company's web site has an employee list that provides some of this information. That which isn't listed somewhere publicly accessible, can often be gathered with a social engineering attack. The classic example was a "survey" passed out in a company's lobby that yielded a number of user accounts and passwords.

More than a hundred pieces of information useful in forming passwords can be personally related to a single individual. A number of these can be broken into pieces and or formated multiple ways. Combinations of pieces may result in thousands of combinations per person. One author1 has identified over three hundred thousand permutations per two word combination and these are not exhaustive. Systematic transformations and permutations of all combinations will result in millions or billions of possibilities per person.

Interactive guessing is likely to be limited to a few dozen attempts. Only the most obvious personal information with a few simple variations is likely to be tried. It's very likely these attempts will be logged. If there is any attempt to automate the guessing, the likelihood of the attempts being noticed in log files increases significantly. Guessing should not be discounted because it remains a method by which improper access to systems is gained, due to the abysmal passwords some users and even administrators select.

Guessing has one advantage over cracking. Guessing merely requires physical access or an open network path to a machine running a suitable service. It does not require any other access to the target machine. Cracking assumes some level of access to the target machine since the account names and password hashes must be in the cracker's possession. Any discussion of cracking where the cracker does not have these in his or her possession, is of academic interest only.

Generally, if passwords that are difficult to crack are selected, they will also be difficult or impossible to guess. Thus, the remainder of this discussion will focus on cracking.

transparent spacer

Top of Page - Site Map

Copyright © 2000 - 2006 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth on http://GeodSoft.com/terms.htm. These terms are subject to change. Distribution is subject to the then current terms, or at the choice of the distributor, those defined in a verifiably dated printout or electronic copy of http://GeodSoft.com/terms.htm at the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit 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 permission is obtained from George Shaffer. Distribution in accordance with these terms, for private, unrestricted and uncompensated public access, non profit, or internal company use is allowed.

 
Home >
How-To >
Good Passwords >
password_basics.htm


What's New
How-To
Opinion
Book
                                       
Email address

Copyright © 2000-2006, George Shaffer. Terms and Conditions of Use.