Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Sign up!
EnGarde Community
What is the most important Linux security technology?
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Latest Newsletters
Linux Security Week: March 23rd, 2015
Linux Advisory Watch: March 20th, 2015
LinuxSecurity Newsletters
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

Password Security and Encryption

6. Password Security and Encryption

One of the most important security features used today are passwords. It is important for both you and all your users to have secure, unguessable passwords. Most of the more recent Linux distributions include passwd programs that do not allow you to set a easily guessable password. Make sure your passwd program is up to date and has these features.

In-depth discussion of encryption is beyond the scope of this document, but an introduction is in order. Encryption is very useful, possibly even necessary in this day and age. There are all sorts of methods of encrypting data, each with its own set of characteristics.

Most Unicies (and Linux is no exception) primarily use a one-way encryption algorithm, called DES (Data Encryption Standard) to encrypt your passwords. This encrypted password is then stored in (typically) /etc/passwd (or less commonly) /etc/shadow. When you attempt to login, the password you type in is encrypted again and compared with the entry in the file that stores your passwords. If they match, it must be the same password, and you are allowed access. Although DES is a two-way encryption algorithm (you can code and then decode a message, given the right keys), the variant that most Unixes use is one-way. This means that it should not be possible to reverse the encryption to get the password from the contents of /etc/passwd (or /etc/shadow).

Brute force attacks, such as "Crack" or "John the Ripper" (see section Section 6.9) can often guess passwords unless your password is sufficiently random. PAM modules (see below) allow you to use a different encryption routine with your passwords (MD5 or the like). You can use Crack to your advantage, as well. Consider periodically running Crack against your own password database, to find insecure passwords. Then contact the offending user, and instruct him to change his password.

You can go to for information on how to choose a good password.

6.1. PGP and Public-Key Cryptography

Public-key cryptography, such as that used for PGP, uses one key for encryption, and one key for decryption. Traditional cryptography, however, uses the same key for encryption and decryption; this key must be known to both parties, and thus somehow transferred from one to the other securely.

To alleviate the need to securely transmit the encryption key, public-key encryption uses two separate keys: a public key and a private key. Each person's public key is available by anyone to do the encryption, while at the same time each person keeps his or her private key to decrypt messages encrypted with the correct public key.

There are advantages to both public key and private key cryptography, and you can read about those differences in the RSA Cryptography FAQ, listed at the end of this section.

PGP (Pretty Good Privacy) is well-supported on Linux. Versions 2.6.2 and 5.0 are known to work well. For a good primer on PGP and how to use it, take a look at the PGP FAQ.

Be sure to use the version that is applicable to your country. Due to export restrictions by the US Government, strong-encryption is prohibited from being transferred in electronic form outside the country.

US export controls are now managed by EAR (Export Administration Regulations). They are no longer governed by ITAR.

There is also a step-by-step guide for configuring PGP on Linux available at It was written for the international version of PGP, but is easily adaptable to the United States version. You may also need a patch for some of the latest versions of Linux; the patch is available at

There is a project maintaining a free re-implementation of pgp with open source. GnuPG is a complete and free replacement for PGP. Because it does not use IDEA or RSA it can be used without any restrictions. GnuPG is in compliance with OpenPGP. See the GNU Privacy Guard web page for more information.

More information on cryptography can be found in the RSA Cryptography FAQ. Here you will find information on such terms as "Diffie-Hellman", "public-key cryptography", "digital certificates", etc.

6.2. SSL, S-HTTP and S/MIME

Often users ask about the differences between the various security and encryption protocols, and how to use them. While this isn't an encryption document, it is a good idea to explain briefly what each protocol is, and where to find more information.

  • SSL: - SSL, or Secure Sockets Layer, is an encryption method developed by Netscape to provide security over the Internet. It supports several different encryption protocols, and provides client and server authentication. SSL operates at the transport layer, creates a secure encrypted channel of data, and thus can seamlessly encrypt data of many types. This is most commonly seen when going to a secure site to view a secure online document with Communicator, and serves as the basis for secure communications with Communicator, as well as many other Netscape Communications data encryption. More information can be found at the SSL Talk Mailing List FAQ. Information on Netscape's other security implementations, and a good starting point for these protocols is available at The SSL Protocol. It's also worth noting that the SSL protocol can be used to pass many other common protocols, "wrapping" them for security. See

  • S-HTTP: - S-HTTP is another protocol that provides security services across the Internet. It was designed to provide confidentiality, authentication, integrity, and non-repudiability [cannot be mistaken for someone else] while supporting multiple key-management mechanisms and cryptographic algorithms via option negotiation between the parties involved in each transaction. S-HTTP is limited to the specific software that is implementing it, and encrypts each message individually. [ From RSA Cryptography FAQ, page 138]

  • S/MIME: - S/MIME, or Secure Multipurpose Internet Mail Extension, is an encryption standard used to encrypt electronic mail and other types of messages on the Internet. It is an open standard developed by RSA, so it is likely we will see it on Linux one day soon. More information on S/MIME can be found at the Mozilla Open Source Crypto Libraries list.

6.3. Linux IPsec Implementations

IPsec is a suite of protocols designed to provide secure communications over insecure networks. As defined by Wikipedia:

IPsec (IP security) is a standard for securing Internet Protocol (IP) communications by encrypting and/or authenticating all IP packets. IPsec provides security at the network layer. IPsec is a set of cryptographic protocols for (1) securing packet flows and (2) key exchange. Of the former, there are two: Encapsulating Security Payload (ESP) provides authentication, data confidentiality and message integrity; Authentication Header (AH) provides authentication and message integrity, but does not offer confidentiality. Originally AH was only used for integrity and ESP was used only for encryption; authentication functionality was added subsequently to ESP. Currently only one key exchange protocol is defined, the IKE (Internet Key Exchange) protocol.

Probably the most common IPsec implementation for Linux is FreeS/WAN although it has recently been replaced with OpenS/WAN. Installing an IPsec implementation on Linux is easier than it used to be, but configuring it still requires a pretty thorough understanding of the technology and is beyond the scope of this HOWTO. Most applications calling for some sort of encrypted tunnel can usually implement OpenSSH instead, as it's much easier to configure, and recent versions include real tunneling where previously only port forwarding was possible.

6.4. Secure Shell

OpenSSH, the most common and most developed implementation of the Secure Shell (ssh) protocol for Linux, is a suite of programs that allow you to login over unsecured links (like the Internet) to remote systems using an encrypted connection. Most Linux users now know that using telnet is simply unacceptible, but ensuring ssh is configured properly is also equally important. The EnGarde Secure Linux platform doesn't even include a telnet daemon, and includes an easy way to configure properly an ssh daemon.

openssh is a suite of programs used as a secure replacement for rlogin, rsh and rcp. It uses public-key cryptography to encrypt communications between two hosts, as well as to authenticate users. It can be used to securely login to a remote host or copy data between hosts, while preventing man-in-the-middle attacks (session hijacking) and DNS spoofing. It will perform data compression on your connections, and secure X11 communications between hosts.

The excellent Openssh implementation is based on a early version of the datafellows ssh and has been totally reworked to not include any patented or proprietary pieces. It is free and under a BSD license. It can be found at the OpenSSH Home Page. Read a near-complete list of features on the OpenSSH Features List page.

You can also use ssh from your Windows workstation to your Linux ssh server. There are several freely available Windows client implementations, including PuTTY, probably the most common one.

6.5. Pluggable Authentication Modules (PAM)

Newer versions of the Red Hat Linux and Debian Linux distributions ship with a unified authentication scheme called "PAM". PAM allows you to change your authentication methods and requirements on the fly, and encapsulate all local authentication methods without recompiling any of your binaries. Configuration of PAM is beyond the scope of this document, but be sure to take a look at the PAM web site for more information.

Just a few of the things you can do with PAM:

  • Use encryption other than DES for your passwords. (Making them harder to brute-force decode)

  • Set resource limits on all your users so they can't perform denial-of-service attacks (number of processes, amount of memory, etc)

  • Enable shadow passwords (see below) on the fly

  • Allow specific users to login only at specific times from specific places

Within a few hours of installing and configuring your system, you can prevent many attacks before they even occur. For example, use PAM to disable the system-wide usage of .rhosts files in user's home directories by adding these lines to /etc/pam.d/rlogin:

		# Disable rsh/rlogin/rexec for users
		login auth required no_rhosts

6.6. Cryptographic IP Encapsulation (CIPE)

The primary goal of this software is to provide a facility for secure (against eavesdropping, including traffic analysis, and faked message injection) subnetwork interconnection across an insecure packet network such as the Internet.

Cryptographic IP Encapsulation encrypts the data at the network level. Packets traveling between hosts on the network are encrypted. The encryption engine is placed near the driver which sends and receives packets.

This is unlike SSH, which encrypts the data by connection, at the socket level. A logical connection between programs running on different hosts is encrypted.

CIPE can be used in tunnelling, in order to create a Virtual Private Network. Low-level encryption has the advantage that it can be made to work transparently between the two networks connected in the VPN, without any change to application software.

Summarized from the CIPE documentation:

"The IPsec standards define a set of protocols which can be used (among other things) to build encrypted VPNs. However, IPsec is a rather heavyweight and complicated protocol set with a lot of options, implementations of the full protocol set are still rarely used and some issues (such as key management) are still not fully resolved. CIPE uses a simpler approach, in which many things which can be parameterized (such as the choice of the actual encryption algorithm used) are an install-time fixed choice. This limits flexibility, but allows for a simple (and therefore efficient, easy to debug...) implementation."

CIPE is no longer actively developed and alternatives should first be considered before implementing.

6.7. Kerberos

Kerberos is an authentication system developed by the Athena Project at MIT. When a user logs in, Kerberos authenticates that user (using a password), and provides the user with a way to prove her identity to other servers and hosts scattered around the network.

This authentication is then used by programs such as rlogin to allow the user to login to other hosts without a password (in place of the .rhosts file). This authentication method can also used by the mail system in order to guarantee that mail is delivered to the correct person, as well as to guarantee that the sender is who he claims to be.

Kerberos and the other programs that come with it, prevent users from "spoofing" the system into believing they are someone else. Unfortunately, installing Kerberos is very intrusive, requiring the modification or replacement of numerous standard programs.

You can find more information about kerberos by looking at the kerberos FAQ, and the code can be found at

It is important that you have an understanding of what Kerberos actually is, but in order to implement it requires that the particular application be compiled against the necessary Kerberos libraries. Applications and protocols including OpenSSH, PAM, X11, NIS and others that require advanced authentication typically already have Kerberos support available.

Kerberos should not be your first step in improving security of your host. It is quite involved, and not as widely used as, say, standard password authentication methods available in SSH.

6.8. Shadow Passwords.

Shadow passwords are a means of keeping your encrypted password information secret from normal users. Recent versions of both Red Hat and Debian Linux use shadow passwords by default, but on other systems, encrypted passwords are stored in /etc/passwd file for all to read. Anyone can then run password-guesser programs on them and attempt to determine what they are. Shadow passwords, by contrast, are saved in /etc/shadow, which only privileged users can read. In order to use shadow passwords, you need to make sure all your utilities that need access to password information are recompiled to support them. PAM (above) also allows you to just plug in a shadow module; it doesn't require re-compilation of executables. You can refer to the Shadow-Password HOWTO for further information if necessary. It is rather dated now, and will not be required for distributions supporting PAM.

6.9. "Crack" and "John the Ripper"

If for some reason your passwd program is not enforcing hard-to-guess passwords, you might want to run a password-cracking program and make sure your users' passwords are secure.

Password cracking programs work on a simple idea: they try every word in the dictionary, and then variations on those words, encrypting each one and checking it against your encrypted password. If they get a match they know what your password is.

There are a number of programs out there...the two most notable of which are "Crack" and "John the Ripper" ( . They will take up a lot of your CPU time, but you should be able to tell if an attacker could get in using them by running them first yourself and notifying users with weak passwords. Note that an attacker would have to use some other hole first in order to read your /etc/passwd file, but such holes are more common than you might think.

6.10. Linux Cryptographic Filesystems

Creating an encrypted container to store critcally important files on your Linux machine is quite compelling. Generally this is done in the form of a file that is mounted as a filesystem, only after having been provided a password to decrypt its contents. When unmounted, the filesystem is automatically encrypted again.

In the past, this was done using CFS or TCFS although they have not been maintained in quite some time. The EncFS project is keeping encrypted filesystems alive in Linux, and describes itself as:

EncFS provides an encrypted filesystem in user-space. It runs without any special permissions and uses the FUSE library and Linux kernel module to provide the filesystem interface. You can find links to source and binary releases below. EncFS is open source software, licensed under the GPL.

6.11. X11, SVGA and display security

6.11.1. X11

It's important for you to secure your graphical display to prevent attackers from grabbing your passwords as you type them, reading documents or information you are reading on your screen, or even using a hole to gain root access. Running remote X applications over a network also can be fraught with peril, allowing sniffers to see all your interaction with the remote system.

X has a number of access-control mechanisms. The simplest of them is host-based: you use xhost to specify the hosts that are allowed access to your display. This is not very secure at all, because if someone has access to your machine, they can xhost + their machine and get in easily. Also, if you have to allow access from an untrusted machine, anyone there can compromise your display.

When using xdm (X Display Manager) to log in, you get a much better access method: MIT-MAGIC-COOKIE-1. A 128-bit "cookie" is generated and stored in your .Xauthority file. If you need to allow a remote machine access to your display, you can use the xauth command and the information in your .Xauthority file to provide access to only that connection. See the Remote-X-Apps mini-howto.

You can also use ssh (see Section 6.4, above) to allow secure X connections. This has the advantage of also being transparent to the end user, and means that no unencrypted data flows across the network.

You can also disable any remote connections to your X server by using the '-nolisten tcp' options to your X server. This will prevent any network connections to your server over tcp sockets.

Take a look at the Xsecurity man page for more information on X security. The safe bet is to use xdm to login to your console and then use ssh to go to remote sites on which you wish to run X programs.

6.11.2. SVGA

SVGAlib programs are typically SUID-root in order to access all your Linux machine's video hardware. This makes them very dangerous. If they crash, you typically need to reboot your machine to get a usable console back. Make sure any SVGA programs you are running are authentic, and can at least be somewhat trusted. Even better, don't run them at all.

6.11.3. GGI (Generic Graphics Interface project)

The Linux GGI project is trying to solve several of the problems with video interfaces on Linux. GGI will move a small piece of the video code into the Linux kernel, and then control access to the video system. This means GGI will be able to restore your console at any time to a known good state. They will also allow a secure attention key, so you can be sure that there is no Trojan horse login program running on your console.



Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
Tech Companies, Privacy Advocates Call for NSA Reform
Google warns of unauthorized TLS certificates trusted by almost all OSes
How Kevin Mitnick hacked the audience at CeBIT 2015
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2015 Guardian Digital, Inc. All rights reserved.