Welcome to docker.ru hosting provider linux mirror located at Moscow, Russian Federation.
Server configuration: Linux with OpenZFS, 2 x E5-2670v2, 128 GB ECC memory, 12 x 4 TB raidz2 + 1 TB SSD for L2ARC.
Network: 20 gbps uplink, IPv4 (185.253.23.31), IPv6 (2a04:8580:ffff:fffe::2).
My hostname is mirror.docker.ru Password Security

4.3. Password Security

Passwords are the primary method Red Hat Enterprise Linux uses to verify a user's identity. This is why password security is enormously important for protection of the user, the workstation, and the network.

For security purposes, the installation program configures the system to use Message-Digest Algorithm (MD5) and shadow passwords. It is highly recommended that you do not alter these settings.

If MD5 passwords are deselected during installation, the older Data Encryption Standard (DES) format is used. This format limits passwords to eight alphanumeric character passwords (disallowing punctuation and other special characters) and provides a modest 56-bit level of encryption.

If shadow passwords are deselected during installation, all passwords are stored as a one-way hash in the world-readable /etc/passwd file, which makes the system vulnerable to offline password cracking attacks. If an intruder can gain access to the machine as a regular user, he can copy the /etc/passwd file to his own machine and run any number of password cracking programs against it. If there is an insecure password in the file, it is only a matter of time before the password cracker discovers it.

Shadow passwords eliminate this type of attack by storing the password hashes in the file /etc/shadow, which is readable only by the root user.

This forces a potential attacker to attempt password cracking remotely by logging into a network service on the machine, such as SSH or FTP. This sort of brute-force attack is much slower and leaves an obvious trail as hundreds of failed login attempts are written to system files. Of course, if the cracker starts an attack in the middle of the night on a system with weak passwords, the cracker may have gained access before dawn and edited the log files to cover his tracks.

Beyond matters of format and storage is the issue of content. The single most important thing a user can do to protect his account against a password cracking attack is create a strong password.

4.3.1. Creating Strong Passwords

When creating a secure password, it is a good idea to follow these guidelines:

Do Not Do the Following:

  • Do Not Use Only Words or Numbers — Never use only numbers or words in a password.

    Some insecure examples include the following:

    • 8675309

    • juan

    • hackme

  • Do Not Use Recognizable Words — Words such as proper names, dictionary words, or even terms from television shows or novels should be avoided, even if they are bookended with numbers.

    Some insecure examples include the following:

    • john1

    • DS-9

    • mentat123

  • Do Not Use Words in Foreign Languages — Password cracking programs often check against word lists that encompass dictionaries of many languages. Relying on foreign languages for secure passwords is not secure.

    Some insecure examples include the following:

    • cheguevara

    • bienvenido1

    • 1dumbKopf

  • Do Not Use Hacker Terminology — If you think you are elite because you use hacker terminology — also called l337 (LEET) speak — in your password, think again. Many word lists include LEET speak.

    Some insecure examples include the following:

    • H4X0R

    • 1337

  • Do Not Use Personal Information — Steer clear of personal information. If the attacker knows your identity, the task of deducing your password becomes easier. The following is a list of the types of information to avoid when creating a password:

    Some insecure examples include the following:

    • Your name

    • The names of pets

    • The names of family members

    • Any birth dates

    • Your phone number or zip code

  • Do Not Invert Recognizable Words — Good password checkers always reverse common words, so inverting a bad password does not make it any more secure.

    Some insecure examples include the following:

    • R0X4H

    • nauj

    • 9-DS

  • Do Not Write Down Your Password — Never store a password on paper. It is much safer to memorize it.

  • Do Not Use the Same Password For All Machines — It is important to make separate passwords for each machine. This way if one system is compromised, all of your machines are not immediately at risk.

Do the Following:

  • Make the Password At Least Eight Characters Long — The longer the password, the better. If using MD5 passwords, it should be 15 characters or longer. With DES passwords, use the maximum length (eight characters).

  • Mix Upper and Lower Case Letters — Red Hat Enterprise Linux is case sensitive, so mix cases to enhance the strength of the password.

  • Mix Letters and Numbers — Adding numbers to passwords, especially when added to the middle (not just at the beginning or the end), can enhance password strength.

  • Include Non-Alphanumeric Characters — Special characters such as &, $, and > can greatly improve the strength of a password (this is not possible if using DES passwords).

  • Pick a Password You Can Remember — The best password in the world does little good if you cannot remember it; use acronyms or other mnemonic devices to aid in memorizing passwords.

With all these rules, it may seem difficult to create a password meeting all of the criteria for good passwords while avoiding the traits of a bad one. Fortunately, there are some steps one can take to generate a memorable, secure password.

4.3.1.1. Secure Password Creation Methodology

There are many methods people use to create secure passwords. One of the more popular methods involves acronyms. For example:

  • Think of a memorable phrase, such as:

    "over the river and through the woods, to grandmother's house we go."

  • Next, turn it into an acronym (including the punctuation).

    otrattw,tghwg.

  • Add complexity by substituting numbers and symbols for letters in the acronym. For example, substitute 7 for t and the at symbol (@) for a:

    o7r@77w,7ghwg.

  • Add more complexity by capitalizing at least one letter, such as H.

    o7r@77w,7gHwg.

  • Finally, do not use the example password above for any systems, ever.

While creating secure passwords is imperative, managing them properly is also important, especially for system administrators within larger organizations. The following section details good practices for creating and managing user passwords within an organization.

4.3.2. Creating User Passwords Within an Organization

If there are a significant number of users within an organization, the system administrators have two basic options available to force the use of good passwords. They can create passwords for the user, or they can let users create their own passwords, while verifying the passwords are of acceptable quality.

Creating the passwords for the users ensures that the passwords are good, but it becomes a daunting task as the organization grows. It also increases the risk of users writing their passwords down.

For these reasons, most system administrators prefer to have the users create their own passwords, but actively verify that the passwords are good and, in some cases, force users to change their passwords periodically through password aging.

4.3.2.1. Forcing Strong Passwords

To protect the network from intrusion it is a good idea for system administrators to verify that the passwords used within an organization are strong ones. When users are asked to create or change passwords, they can use the command line application passwd, which is Pluggable Authentication Manager (PAM) aware and therefore checks to see if the password is easy to crack or too short in length via the pam_cracklib.so PAM module. Since PAM is customizable, it is possible to add further password integrity checkers, such as pam_passwdqc (available from http://www.openwall.com/passwdqc/) or to write a new module. For a list of available PAM modules, refer to http://www.kernel.org/pub/linux/libs/pam/modules.html. For more information about PAM, refer to the chapter titled Pluggable Authentication Modules (PAM) in the Red Hat Enterprise Linux Reference Guide.

It should be noted, however, that the check performed on passwords at the time of their creation does not discover bad passwords as effectively as running a password cracking program against the passwords within the organization.

There are many password cracking programs that run under Red Hat Enterprise Linux although none ship with the operating system. Below is a brief list of some of the more popular password cracking programs:

NoteNote
 

None of these tools are supplied with Red Hat Enterprise Linux and are therefore not supported by Red Hat, Inc. in any way.

  • John The Ripper — A fast and flexible password cracking program. It allows the use of multiple word lists and is capable of brute-force password cracking. It is available online at http://www.openwall.com/john/.

  • Crack — Perhaps the most well known password cracking software, Crack is also very fast, though not as easy to use as John The Ripper. It can be found online at http://www.crypticide.com/users/alecm/.

  • SlurpieSlurpie is similar to John The Ripper and Crack, but it is designed to run on multiple computers simultaneously, creating a distributed password cracking attack. It can be found along with a number of other distributed attack security evaluation tools online at http://www.ussrback.com/distributed.htm.

WarningWarning
 

Always get authorization in writing before attempting to crack passwords within an organization.

4.3.2.2. Password Aging

Password aging is another technique used by system administrators to defend against bad passwords within an organization. Password aging means that after a set amount of time (usually 90 days) the user is prompted to create a new password. The theory behind this is that if a user is forced to change his password periodically, a cracked password is only useful to an intruder for a limited amount of time. The downside to password aging, however, is that users are more likely to write their passwords down.

There are two primary programs used to specify password aging under Red Hat Enterprise Linux: the chage command or the graphical User Manager (system-config-users) application.

The -M option of the chage command specifies the maximum number of days the password is valid. So, for instance, to set a user's password to expire in 90 days, type the following command:

chage -M 90 <username>

In the above command, replace <username> with the name of the user. To disable password expiration, it is traditional to use a value of 99999 after the -M option (this equates to a little over 273 years).

The graphical User Manager application may also be used to create password aging policies. To access this application, go to the Main Menu button (on the Panel) => System Settings => Users & Groups or type the command system-config-users at a shell prompt (for example, in an XTerm or a GNOME terminal). Click on the Users tab, select the user from the user list, and click Properties from the button menu (or choose File => Properties from the pull-down menu).

Then click the Password Info tab and enter the number of days before the password expires, as shown in Figure 4-1.

Figure 4-1. Password Info Pane

For more information about user and group configuration (including instructions on forcing first time passwords), refer to the chapter titled User and Group Configuration in the Red Hat Enterprise Linux System Administration Guide. For an overview of user and resource management, refer to the chapter titled Managing User Accounts and Resource Access in the Red Hat Enterprise Linux Introduction to System Administration.

powered by nginx