On passwords

LKSF › Solaris Security › On passwords

The password is the key to the system. When you know the username and the password, you can use the system. If not … well … go away. You can’t overemphasize the value of good passwords. There is something you can do as the admin at the system level to ensure such passwords. At first you can use stronger mechanisms to hash the passwords. And you can force the users of your system to use good passwords. This tutorial will explain both tasks.

Using stronger password hashing

Many people are unaware of the fact that only the first eight characters of a password are used in the default configuration. Don’t believe it? Let’s try it.

Okay, I’ve logged into my test machine and changed my password:

bash-3.2$ passwd jmoekamp
Enter existing login password: oldpassword
New Password: aa3456789
Re-enter new Password: aa3456789
passwd: password successfully changed for jmoekamp
bash-3.2$ 

Now let’s try a password that’s different at the ninth character by logging into the Solaris system from remote:

mymac:~ joergmoellenkamp$ ssh jmoekamp@10.211.55.200
Password: aa3456780
Last login: Wed May 28 11:24:05 2008 from 10.211.55.2
Sun Microsystems Inc.   SunOS 5.11      snv_84  January 2008

I’ve told you … only the first eight characters are relevant. But it’s not that Solaris can’t do better than that. It’s just the binary compatibility guarantee again. You can’t simply change the mechanism encrypting the password. There may be scripts that still need the old unix crypt variant. But in case you are sure that you don’t have such an application you can change it, and it’s really simple to do:

When you look into the file /etc/security/crypt.conf you will find the additional modules for password encryption.

# The algorithm name __unix__ is reserved.

1       crypt_bsdmd5.so.1
2a      crypt_bsdbf.so.1
md5     crypt_sunmd5.so.1

The hashing mechanisms are loaded as libraries in the so-called Solaris Pluggable Crypt Framework. It’s even possible to develop your own hashing mechanism in case you don’t trust the implementations delivered by Sun.

Short	Algorithm	Description
1	BSD alike, md5 based	The `crypt_bsdmd5` module is a one-way password hashing module for use with `crypt(3C)` that uses the MD5 message hash algorithm. The output is compatible with `md5crypt` on BSD and Linux systems.
2a	BSD alike, blowfish based	The `crypt_bsdbf` module is a one-way password hashing module for use with `crypt(3C)` that uses the Blowfish cryptographic algorithm.
md5	Sun, md5 based	The `crypt_sunmd5` module is a one-way password hashing module for use with `crypt(3C)` that uses the MD5 message hash algorithm. This module is designed to make it difficult to crack passwords that use brute force attacks based on high speed MD5 implementations that use code inlining, unrolled loops, and table lookup.

Cryptographic mechanisms for password encryption

Each of the three mechanisms supports passwords with up to 255 characters. It’s important to know that the different hashing algorithms can coexist in your password databases. The password hashing for a password will be changed when a user changes his or her password.

Changing the default hash mechanism

Let’s use the md5 algorithm in our example. But before that, we should look into the current /etc/shadow:

# grep "jmoekamp" /etc/shadow
jmoekamp:nM2/fPrCTe3F6:14027::::::

It’s simple to enable a different encryption algorithm for passwords. You just have to change one line in /etc/security/policy.conf. To edit this file you have to login as root:

CRYPT_DEFAULT=md5

Okay, now let’s change the password.

# passwd jmoekamp
New Password: aa1234567890
Re-enter new Password:  aa1234567890
passwd: password successfully changed for jmoekamp

When you look in the /etc/shadow for the user, you will see a slightly modified password field. It’s much longer and between the first and the second $ you see the used encryption mechanism:

# grep "jmoekamp" /etc/shadow      
jmoekamp:$md5$vyy8.OVF$$FY4TWzuauRl4.VQNobqMY.:14027::::::

Now let’s try the login:

mymac:~ joergmoellenkamp$ ssh jmoekamp@10.211.55.200
Password: aa1234567890
Last login: Wed May 28 11:38:24 2008 from 10.211.55.2
Sun Microsystems Inc.   SunOS 5.11      snv_84  January 2008
$ exit
Connection to 10.211.55.200 closed.
mymac:~ joergmoellenkamp$ ssh jmoekamp@10.211.55.200
Password: aa1234567891
Password: aa1234567892
Password: aa1234567893
Permission denied (gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive).
mymac:~ joergmoellenkamp$

You see, the correctness of the complete password is tested, not just the first 8 characters.

Password policies

Users have the habit of breaking any security policy. At least as long as you don’t enforce it. One of the most annoying habits from the view of the security people is the tendency to choose weak passwords, the name of the boyfriend or girlfriend, the preferred brand of cars, birthdays … you name it. These passwords are everything but secure. But you can configure Solaris to check the new passwords.

Specifying a password policy

There is a central file in Solaris controlling the password policy. In /etc/default/passwd you define what requirements a password must fulfill before Solaris allows the user to set this password. Let’s have a look at the current file of a standard Solaris system. You have to log into your system as root:

# cat passwd 
[... omitted CDDL header ...]
#
MAXWEEKS=
MINWEEKS=
PASSLENGTH=6
#NAMECHECK=NO
#HISTORY=0
#MINDIFF=3
#MINALPHA=2
#MINNONALPHA=1
#MINUPPER=0
#MINLOWER=0
#MAXREPEATS=0
#MINSPECIAL=0
#MINDIGIT=0
#WHITESPACE=YES
#DICTIONLIST=
#DICTIONDBDIR=/var/passwd

You enable the checks by uncommenting them and setting a reasonable value. When you enable all the checks, it’s actually harder to find a valid password than a non-valid one. Whenever thinking about a really hard password policy you should take into consideration that people tend to make notes about their password when they can’t remember it. And a strong password under the keyboard is obviously less secure than a weak password in the head of the user.

Parameter	Description
MAXWEEKS	This variable specifies the maximum age for a password.
MINWEEKS	This variable specifies the minimum age for a password. The rationale for this setting gets clearer when I talk about the `HISTORY` setting.
PASSLENGTH	The minimum length for a password.
HISTORY	This variable specifies the length of a history buffer. You can specify a length of up to 26 passwords in the buffer. The `MINWEEKS` parameter is useful in conjunction with this parameter. There is a trick to circumvent this buffer and to get your old password back. Just change it as often as the length of the buffer plus one time. The `MINWEEKS` parameter prevents this.
WHITESPACE	This variable defines if you are allowed to use a whitespace in your password.
NAMECHECK	When you set this variable to `YES`, the system checks if the password and login name are identical. So using the password `root` for the user `root` would be denied by this setting. The default, by the way, is `yes`.

/etc/default/passwd: standard checks

Besides these basic checks you can use /etc/default/passwd to enforce checks for the complexity of passwords. So you can prevent the user from setting too simple passwords.

Parameter	Description
MINDIFF	Let’s assume you’ve used 3 here. If your old password was `batou001`, a new password would be denied if you try to use `batou002` as only one character was changed. `batou432` would be a valid password.
MINUPPER	With this variable you can force the usage of upper case characters. Let’s assume you’ve specified 3 here, a password like `wasabi` isn’t an allowed choice, but you could use `WaSaBi`.
MINLOWER	With this variable you enable the check for the amount of lower case characters in your password. In case you’ve specified 2 here, a password like `WASABI` isn’t allowed, but you can use `WaSaBI`.
MAXREPEATS	Okay, some users try to use passwords like `aaaaaa2`. Obviously this isn’t really a strong password. When you set this parameter to 2, it checks if at most 2 consecutive characters are identical. A password like `waasabi` would be allowed, but not a password like `waaasabi`.
MINSPECIAL	The class `SPECIAL` consists of characters like !=$%$=. Let’s assume you’ve specified 2, a password like `!ns!st` would be fine, but the password `insist` is not a valid choice.
MINDIGIT	With this variable you can specify the amount of numbers in your password. Let’s assume you specify 2, a password like `snafu01` would be allowed. A password like `snafu1` will be denied.
MINALPHA	You can check with this variable for a minimum amount of alpha chars (a-z and A-Z). When you set a value of 2 on this variable, a password like `aa23213` would be allowed, a password like `0923323` would be denied.
MINNONALPHA	This checks for the amount of non-alpha characters (0-9 and special chars). A value of 2 would lead to the denial of `wasabi`, but a password like `w2sab!` would be allowed.

/etc/default/passwd: complexity checks

Using wordlists

There is another way to force stronger passwords. You can deny every password that is located in a list of words. The program for changing passwords is capable of comparing the new password against a list of words. With this function you can deny the most obvious choices of passwords. But you should initialize the dictionary with a list of words before you can use this feature.

# mkpwdict -s /usr/share/lib/dict/words 
mkpwdict: using default database location: /var/passwd.

The file /usr/share/lib/dict/words is a file in the Solaris Operating System containing a list of words. It’s normally used by spell checking tools. Obviously you should use a wordlist in your own language, as users tend to choose words from their own language as passwords. So an English wordlist in Germany may not be that effective. Now you have to tell Solaris to use these lists.

Parameter	Description
DICTIONLIST	This variable can contain a list of dictionary files separated by a comma. You must specify full pathnames. The words from these files are merged into a database that is used to determine whether a password is based on a dictionary word.
DICTIONDBDIR	The directory where the generated dictionary databases reside.

/etc/default/passwd: Dictionaries

When neither of the two variables is specified in the /etc/default/passwd then no dictionary check is performed.

Let’s try it. I’ve uncommented the DICTIONDBDIR line of the /etc/default/passwd file and used the standard value /var/passwd. One of the words in the dictionary I imported is the word airplane:

$ passwd
passwd: Changing password for jmoekamp
Enter existing login password: chohw!2
New Password: airplane
passwd: password is based on a dictionary word.

Conclusion

These are some simple tricks to make your system more secure, just by ensuring that the keys to your server are well-chosen and not simple ones. But as I stated before there is something you should keep in mind. Don’t make the passwords too hard to remember.