Solaris 10 Password History

Today's topic is short and sweet: password history. For those who are not aware, the concept of password history is to prevent users from repeatedly selecting the same (set) of passwords over and over again (within some fixed time window). The actual time window will depend on the configuration of the system.

Often, password history is used in combination with password composition rules and password aging. For example, an organization may prohibit user's from selecting a password that is defined in some dictionary list or one that does not meet some minimum set of composition requirements. Further, the same organization may also mandate that user's must change their password every ninety days (but no sooner than one week after the last successful change). The goal here is to require users to select strong passwords, change them regularly and limit their future reuse. Without password history, what would stop a user from repeatedly selecting the same password (or small set of passwords - or even just rotating between two valid passwords) at each password expiration event?

Password history helps to solve this issue by enforcing a policy that says that a user may not reuse any of the last n passwords (where n is defined by the organization). So, for example, by setting both password history and aging settings appropriately, an organization could prevent the reuse of passwords for a significant period of time.

So, let's talk about specifics. New to Solaris 10 is the HISTORY parameter in the /etc/default/passwd file. This new parameter specifies the number of passwords that will be remembered - and consequently compared against a user's new password to see if it had been used before. By default, password history is disabled. If you want to enable password history then you must uncomment the HISTORY parameter and assign it a value. This value will indicate the number of passwords that the system should remember. This parameter can take values ranging from 0 to 26. For example:

# grep "\^HISTORY=" /etc/default/passwd
HISTORY=10

In this example, password history has been enabled and a user's last ten passwords will be remembered. So, if I user attempts to re-use a password that is in their history, the change will be denied and the user will be presented with the following message:

$ passwd gmb
Enter existing login password:
New Password:
passwd: Password in history list.

Please try again
New Password:

Once password aging has been enabled, it can be disabled by setting the HISTORY parameter to 0 or by commenting it out in the /etc/default/passwd file. Once this is done, all users' prior password history will be discarded at the next password change by any user. Note that this is a very important point. When password history is disabled, the entire password history database will be discarded upon the next password change event by any user on the system.

In my previous posts I have tried to highlight global changes versus settings that can be applied to individual users. In the case of password history, it can only be defined on a global basis. There are no per-user settings for this feature.

Now that I have covered the basics of enabling, configuring and disabling password history, one last question may still be nagging at you - where is the password history database kept? The password history database is stored in the /etc/security/passhistory file. This file is an implementation artifact of the password history feature and is not meant to be modified by end users. This file has the following ownership and permissions:

-r--------   1 root     root          47 Sep 28 22:21 /etc/security/passhistory

Those curious enough to poke around this file will find that it contains a list of users (one per line) as well as their last n password hashes separated by a colon. For example, the above file has the following contents:

# cat /etc/security/passhistory
gmb:TRltRapbB7Eek:l5rXbTq1EJ7bQ:yEB668aaGv5z6:LgbM3LpCsERlA:

What is really cool about how password history is implemented in Solaris 10 is that it will work as you change your default password encryption algorithm using the flexible crypt mechanism (introduced in Solaris 9). For example, after changing my password encryption algorithm from the Solaris default to Blowfish, this is what happens:

# grep "\^HISTORY=" /etc/default/passwd
HISTORY=10

# grep "\^CRYPT_DEFAULT=" /etc/security/policy.conf
CRYPT_DEFAULT=__unix__

# cat /etc/security/passhistory
gmb:aMPK0ug.Syoag:Lp145TNOHmdlM:

# grep "\^CRYPT_DEFAULT=" /etc/security/policy.conf
CRYPT_DEFAULT=2a

# grep "\^2a" /etc/security/crypt.conf
2a      crypt_bsdbf.so.1

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

# cat /etc/security/passhistory
gmb:$2a$04$A.vGapPSCtbmXj3B9hYK..7fkgJqpg3YKXFoOt1T.YLBk0xw5p9E.:aMPK0ug.Syoag:Lp145TNOHmdlM:

First, I verified that I was using the default password encryption algorithm ("__unix__"). I used the passwd(1) command twice (not shown) to define passwords for the gmb account. Those password hashes were recorded in the /etc/security/passhistory file. I then changed the default password encryption algoritm to Blowfish ("2a") and changed the password for the gmb account once more. Each time I changed the password, I used a new, unique password.

Now we are ready for the real test. I will try to select each of the three passwords that are in my password history. Two of the passwords are currently stored in default ("__unix__") format and the other is stored in Blowfish format.

$ passwd gmb
Enter existing login password:
New Password:
passwd: Password in history list.

Please try again
New Password:
passwd: Password in history list.

Please try again New Password:
passwd: Password in history list.
Permission denied

As you can see, in each case, the password was recognized as having been in my password history. So, it doesn't matter if you simply use the default password algorithm or select another. This functionality will still just work. Don't you just love it!

Well, this one ran a little longer than I had originally thought, but I hope that you found it interesting nonetheless. Check back soon for another installment of lesser known and/or publicized security enhancements to the Solaris 10 OS. I still have a bunch lined up for you!

Let me know what you think of this series of articles as well as ideas for future updates. Take care!

Technorati Tag:

Comments:

I think these kinds of articels are great. Small useful hacks that i most certainly wouldnt have known about without attending a sun course.

Posted by Kenneth on September 29, 2004 at 02:55 AM EDT #

Kenneth,

Thank you so much for your kind words and feedback. There are very much appreciated. It is great to know that people are reading these blogs and finding content in them useful. Thanks again!

Glenn

Posted by Glenn Brunette on September 29, 2004 at 03:45 AM EDT #

The article itself is great, but... I have found that aggressive password policies lead to (1) users forgetting their password a lot, and (2) lots of post-it notes with passwords stuck right onto the monitor. So while the technology is great, it might end up creating more problems than it solves. I believe that we are at the point where secondary authentication is needed, such as token cards or biometric checks.

Posted by Kevin on September 29, 2004 at 10:48 AM EDT #

Kevin,

Thank you very much for your feedback. I am very much in agreement with you on the need for more widespread use of stronger authentication mechanisms. Definitely no argument from me.

That said, organizations are unique and have differing security policies, regulatory requirements, and budgets. Some may require passwords (for some reason). Others may not be able to afford an alternative (due to the size of the organization, the purchase, configuration and long-term management costs, etc.). As such, Sun tries to give our customers a choice.

Just like pluggable authentication mechanisms, account lockout, enhanced password composition checks, password aging, and other security controls, password history is just one tool in an organization's arsenal to be applied (or not applied) as the organization sees fit.

It is from this perspective, that I decided to talk about these new features. I want to make sure the people who need them: (1) know they exist, (2) know how to use them and (3) know how to get more information on them if they need it.

Thank you again for your great feedback. It is very much appreciated. Take care.

Glenn

Posted by Glenn Brunette on September 30, 2004 at 03:33 AM EDT #

I discovered this blog from "the clingan zone" blog. You have a good writing style and your examples are useful.

We're not yet running sol10 but it's good to know about the new features. We just installed sol9 on a box a few weeks ago and xdm doesn't work at all-- sol8 still the most stable for us.

Looking forward to more articles.

Posted by luis fernandes on October 17, 2004 at 04:44 PM EDT #

Luis,

Thank you very much for your kind words of support. I have just returned from a little vacation and will hopefully be posting more articles soon!.

Take care!

g

Posted by Glenn Brunette on October 21, 2004 at 03:37 AM EDT #

Post a Comment:
Comments are closed for this entry.
About

gbrunett

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today