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 password. 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 change 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 way, 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 haven’t 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 crypting mechanism in the case you don’t trust the implementations delivered by Sun.

::: center
+———————+—————————+——————————————————————————————————————————————————————————————————+
| [Short]{.smallcaps} | [Algorithm]{.smallcaps} | [Description]{.smallcaps} |
+:====================+:==========================+:=====================================================================================================================================================================================================+
| | 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 support passwords with up to 255 characters. It’s important to know, that the different hashing algorithm can coexist in your password databases. The password hashing for a password will be changed when user change his or her password.

Changing the default hash mechanism

Let’s use the md5[^11] algorithm in our example. But before that, we should look into the actual /etc/shadow

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

It’s simple to enable a different encryption algorithm for password. You have just to change one lines 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 slighly 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::::::

Not 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

User have the habit to break any security policy. At least as long you don’t enforce it. One of the most annoying habit from the view of the security people is the tendency to choose weak passwords, the name of the boy or girl friend, the prefered brand of cars, birthdays ... you name it. This passwords are everything but secure. But you can configure Solaris to check the new passwords.

Specifing a password policy

There is a central file in Solaris controling 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 in the actual file of a standard solaris system. You have to log into your system as root [^12]:

# 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 it and set a reasonable value to the line. 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.

::: center
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 settings 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 buffer is useful in conjunction with this parameter. There is a trick to circumvent this buffer and to get you old password back. Just change it as often as the length of the buffer plus one time. The MINWEEK 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 use root would be denied by this setting. The default, by the way is, yes.: /etc/default/password: standard checks :::

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

::: center
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 on 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 the 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 password to 2 you, 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 out 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 password you can specify the amount of the numbers in your password. Let’s a assume you specify 2, a password like snafu01 would will 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!: /etc/default/password: complexity checks :::

[]{#default label=”default”}

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 password is capable to compare 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/dicts/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 user tend do choose words from their own language as passwords. So an English wordlist in Germany may be not that effective.[^13] Now you have to tell Solaris to use this lists.

::: center
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/password: Dictionaries :::

When none of the both 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 word 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-choosen 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.