Section 2.4 Advanced Password Techniques | Real World Linux Security Prentice Hall Ptr Open Source Technology Series

2.4 Advanced Password Techniques

Some advanced password techniques are discussed here. These techniques are important to resist persistent crackers who may try "real hard" to break your passwords. Failing to use these techniques puts you at risk even if all your accounts use the best passwords. This is because modern computers can crack DES passwords stored in /etc/passwd in a few days. Almost all popular distributions can support these advanced techniques but they may not be enabled by default.

2.4.1 Shadowed MD5 Passwords for Good Security

As mentioned elsewhere, if a cracker manages to see your encrypted passwords, cracking them becomes much easier. Because of this, modern Linux (and UNIX) systems offer shadowed passwords. Instead of storing the passwords in /etc/passwd, which is readable by everyone, they are stored only in /etc/shadow. This file is readable only by root. Slackware has been using shadow passwords by default at least since version 3.4. All major distributions use shadowed passwords automatically now.

Commonly, the transformed password that is the result of the DES or MD5 algorithm is referred to as encrypted because someone looking at it will not know what the original password was. To be precise, encrypted means that a nonbrute force method can be used to determine from it what the original phrase was.

The DES or MD5 algorithm that is used to transform a user's entered password into what is stored on disk more properly is called a hash. Similar to the hash tables used in compilers and databases, it is a one-way algorithm. This prevents someone from determining the original password easily but if someone subsequently enters the "plain text" password, the system can run the algorithm on this and see if it results in the same hash. If it does, the person entered the correct password.

An additional feature on Linux and UNIX is the availability of MD5 password "encryption" (hashes). MD5 passwords solve the weaknesses of DES passwords. DES passwords are limited to 8 significant characters and it uses only 56-bit encryption, which is easy to crack with recent computers. DES also only uses 4096 different salt possibilities; MD5 uses 2**128.

Salt causes the hashed passwords of two different users (or the same user on two different systems) to be different, even if they enter the same password. It prevents a cracker from hashing a list of common passwords and simply checking this against each user's hashed password. Salt is also discussed in "Avoiding Weak and Default Passwords" on page 42.

The "double DES" hashes that are available on some systems actually are less secure than the standard DES hashes. MD5 is a much more complex algorithm which takes about 20 times the CPU time to hash a password than DES. Although a cracker might be able to crack all your DES-based passwords in two days, it might take 40 days to crack your MD5 passwords if he could even get them; he probably will go bother someone else instead. MD5 allows an unlimited number of significant characters in the password, giving your users more flexibility in choosing passwords.

Shadowed MD5 passwords are much harder to crack than nonshadowed or DES passwords; it is important to convert to shadowed MD5 passwords for good security.

2.4.2 Reprompting for the Password

The only things worse than an interloper taking over a user's account is being allowed to "keep it" for a long time. This is the reason that the password program prompts for a user's old password before accepting the requestor's new password.

Thus, if it is an interloper trying to change the password (while the user has taken a walk) he will be unable to and will have access only until the user comes back or the terminal is locked for inactivity, etc. The inactivity timer should be short, typically 2 10 minutes. Another technique for X-based programs is to make use of X's Secure keyboard feature that a program might use to ensure that it has exclusive access to read the keyboard while the user is keying confidential data, such as passwords and credit card numbers. (Certainly, the interloper could create a set-UID shell but he would not be able to access it without first getting "on" the system via another account.)

This limits the interloper's access to a short time. Why should you care? It is important to understand this reason for prompting for the password even though the "user" is already logged in.

Passwords are requested by Web servers and ordinary application programs. If someone sneaks onto your terminal and orders some CDs with the latest tunes, they will end up shipped to your address, and e-mail notification (in time to stop the order) will be sent to your e-mail account. The interloper might be able to delete your e-mail but she probably does not have a key to your apartment and so you will be able to return the merchandise for a credit.

The security-conscious Web sites will ask that you enter your password into the form used for changing or accessing critical user data such as shipping or billing addresses, credit card numbers, e-mail addresses, or phone numbers. They will use https to protect all confidential data, especially passwords and credit card numbers. Make sure that your browser is indicating that SSL is being used. Recent versions of Netscape 4.* show a closed padlock to indicate this.

I used a site last night that went through all of the trouble of having me connect through https to set up my account and pick my password. Then when I ordered merchandise I noticed that it was using http, not https, to accept my password. Thus, this second time my password was transmitted in clear text, available for the sniffing. They really should have known better. I am choosing not to mention the site because it is a nonprofit organization that does good work.

These sites also should e-mail notification saying which items have changed, for example, "We changed your credit card number at your request," without actually including the new credit card number in the e-mail in case someone else reads the e-mail, possibly by sniffing. If the e-mail address is changed, notification including the new e-mail address should be sent to the old e-mail address too.

Most financial institutions and investment firms follow a similar procedure regarding postal addresses. They will send a letter to the old address announcing that the address of record has been changed to the new address. If the letter is returned as undeliverable, the address change is probably legitimate. If the firm instead receives a surprised or angry letter from the investor, a theft may have been prevented.

This is to prevent a criminal from first changing an account's address to the criminal's post office box and then proceeding to close the account with a check sent to this new address. The owner might not notice this theft for months because he never sees this statement and does not miss it among the normal deluge of mail.

You will want to ensure that your Web applications follow these good practices. You may not want to do business with Web sites that do not use https to protect confidential data or which do other boneheaded things to compromise your credit card. Remember, you will be the one that must hassle with your credit card company if a fraud is perpetrated, not the Web site.

In many applications the customer service people must "log in" to the application after logging in to their Linux account. This application account and password frequently is independent from the Linux account and a particular application account may be started from any Linux account. It is imperative that the same update procedure be used for changing the application password and other critical information as you considered for Web sites and changing the Linux password.

2.4.3 Should Passwords Be Aged?

Many SysAdmins get a false sense of security by forcing their users to change their passwords (password aging) regularly. A well-picked password could be used for years because a user can remember it and not need to write it down. Forcing a user to give up a well-chosen password can be demoralizing and cause a user deliberately to pick a less secure but more easily guessed password. Forcing users to think up subsequent passwords every 1 to 12 months will, with each iteration, typically cause less secure passwords to be used and the increasing likelihood that they will be written down in an insecure place.

Special note: When passwords must be changed, do not e-mail the new password. If an account is compromised this would give the new password to the intruder. If the intruder had been in through means other than the old password, you just gave her an additional path in. For an entertaining account of this see "Confessions of a Berkeley System Mole" on page 373.

What are the disadvantages of using the same passwords indefinitely?

A cracker might discover someone's password, especially root's, and lie quietly in wait for months or even years and then strike at a most inopportune time.
Users will tend to use the same password everywhere. Thus, if the password is compromised on one system, possibly due to sniffing or a Trojan in login, telnetd, or even sshd, all the user's systems could be at risk.
With many people having systems at home and cable modems and DSL becoming so popular, expect your users' home systems to become compromised. These compromised systems probably contain enough information about the office systems to allow the cracker to then penetrate the office systems.

At some companies the root password is not changed even when someone who knows it leaves the company. Be sure to change any password that a departing employee or consultant knows, regardless of how amicable the departure is.

When I have left some consulting assignments, I have had to plead with the system administrators to change any password that I know. This is not just for proper security. Additionally, it protects my reputation if there is a security breach later.

2.4.4 Account Names

You have just examined issues with passwords. However, before a cracker can "crack" a password he needs to know the name of an account. It is much more difficult to guess both an account name and a password at the same time than it is to guess the password for a known account. This is why on Linux and UNIX if you enter the account name correctly but enter the wrong password, the error message is exactly the same as if the account name does not exist. This is true for the login, telnetd, and ftpd programs. Thus, they will not allow a cracker to discover which account names are valid.

This is part of the "Rings of Security" policy. You can contribute still further by not allowing crackers to discover the valid names and by not using likely ones. For this reason common first names such as "joe" or "cindy" should not be used. Nor should "sales" or "hr." Using a person's last name or last name combined with first initial is a good solution.

The truly cautious might want to have e-mail names not correspond with account names. This would be overkill for some. However, it could be done by editing the /etc/aliases file to map convenient e-mail addresses such as sales to the actual account name for incoming e-mail. For outgoing mail, the genericstable can be used to map the actual account name back to the externally visible e-mail address, such as "sales." This could be done for individual accounts too. Thus, Sam Spade might have e-mail at sspade@pentacorp.com and have account gum on shoe.pentacorp.com.

For additional security, many sites use separate systems for separate services. Typically e-mail, Netscape, and Usenet News clients would be on one set of systems, the Web server and related operations on another, and internal accounting and operations on others. The cost per megabyte and per computron is so low that this is very practical. (A computron is a term meaning unit of computation in a computer. I cannot recall what engineer I first heard using the term; I believe that it was at Stratus Computer.)

This is addressed in several other chapters including "Intracompany Firewalls to Contain Fires" on page 84, "Special Techniques for Web Servers" on page 284, and "United We Fall, Divided We Stand" on page 115.

Some installations already have the host name for all e-mail addresses be that of the domain, for example,

 sales@pentacorp.com

This makes it easy to move people's accounts between actual systems without the difficulty of everyone needing to update their e-mail addresses.

Top