PASSWORD HISTORY on Solaris
Rossi Kwan
How can i know if password history is set in Solaris UNIX?
Thanks for your reply.
Rossi Kwan
Paul Archer
> Hi all,
> How can i know if password history is set in Solaris UNIX?
> Thanks for your reply.
If you mean, is there a history of previously used passwords,
then the answer is, no--or at least, not without installing some
third-party software.
Thomas Nau
| Hi all,
|
| How can i know if password history is set in Solaris UNIX?
| Thanks for your reply.
There's at least password history in Soalris Express (s10)
http://www.sun.com/bigadmin/features/articles/solaris_express.html
(search for history)
I also think the latest Solaris9 + latest Sun directory server support this
but I'm not 100% about it
Thomas
-----------------------------------------------------------------
PGP fingerprint: B1 EE D2 39 2C 82 26 DA A5 4D E0 50 35 75 9E ED
Casper H.S. Dik
Or Solaris Express.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Oscar del Rio
>>If you mean, is there a history of previously used passwords,
>>then the answer is, no--or at least, not without installing some
>>third-party software.
>
> Or Solaris Express.
Cool :-)
After adding "HISTORY=3" to /etc/default/passwd
(using Solaris 10 beta 2)
-passwd: Changing password for test
Enter existing login password:
New Password:
passwd: Password in history list.
The history is kept in /etc/security/passhistory
I also noticed that the account-locking-after-repeated-failures
"feature" (which I think is just a DoS-in-waiting but many Windoze
admins have been asking for) was also added to Solaris Express:
"The pam_unix_auth module implements account locking for local users.
Account locking is enabled by the LOCK_AFTER_RETRIES tunable in
/etc/security/policy.conf and the lock_after-retries key in /etc/user_attr."
Casper H.S. Dik
>I also noticed that the account-locking-after-repeated-failures
>"feature" (which I think is just a DoS-in-waiting but many Windoze
>admins have been asking for) was also added to Solaris Express:
>"The pam_unix_auth module implements account locking for local users.
>Account locking is enabled by the LOCK_AFTER_RETRIES tunable in
>/etc/security/policy.conf and the lock_after-retries key in /etc/user_attr."
I think that's just the documentation of that feature.
Alan Hargreaves - Product Technical Support (APAC)
In a previous job, we implemented password history and forced password
changes by using rcs.
We had a NIS environment adn we basically left the password file checked
out for edit. Just before midnight each night we would check it in and
then check it out.
This made it very simple to go back N days and compare encrypted passwords.
This may not be quite what you are after, but maybe it can help.
alan.
--
Alan Hargreaves
Senior Technical Support Specialist/VOSJEC Engineer
Product Technical Support (APAC)
Sun Microsystems
Casper H.S. Dik
>This made it very simple to go back N days and compare encrypted passwords.
But encrypted passwords cannot be properly compared; the same password
encrypts in many different ways.
A password history can consist of encrypted passwords but they
need to be verified all in turn using the cleartext password.
Alan Hargreaves - Product Technical Support (APAC)
> "Alan Hargreaves - Product Technical Support (APAC)" <Alan.Ha...@Sun.COM> writes:
>
>
>>This made it very simple to go back N days and compare encrypted passwords.
>
>
>
> But encrypted passwords cannot be properly compared; the same password
> encrypts in many different ways.
>
> A password history can consist of encrypted passwords but they
> need to be verified all in turn using the cleartext password.
>
> Casper
True, but I would argue (successfully I hope) that changing your
password to a password that encrypts to the same value is effectively no
password change at all. Hence, checking the encrypted value actually is
more useful than checking the clear text.
Alan Hargreaves - Product Technical Support (APAC)
> Casper H.S. Dik wrote:
>
>> "Alan Hargreaves - Product Technical Support (APAC)"
>> <Alan.Ha...@Sun.COM> writes:
>>
>>
>>> This made it very simple to go back N days and compare encrypted
>>> passwords.
>>
>>
>>
>>
>> But encrypted passwords cannot be properly compared; the same password
>> encrypts in many different ways.
>>
>> A password history can consist of encrypted passwords but they
>> need to be verified all in turn using the cleartext password.
>>
>> Casper
>
>
> True, but I would argue (successfully I hope) that changing your
> password to a password that encrypts to the same value is effectively no
> password change at all. Hence, checking the encrypted value actually is
> more useful than checking the clear text.
>
Of course I neglected the salt. What you would have to do is to take the
salt from teh stored encrypted password and use that to encrypt the new
clear text.
alan.
Casper H.S. Dik
>True, but I would argue (successfully I hope) that changing your
>password to a password that encrypts to the same value is effectively no
>password change at all. Hence, checking the encrypted value actually is
>more useful than checking the clear text.
My point is that if you use the exact same password twice, it is
very unlikely that it will encrypt to the same value twice because
passwords are salted. E.g., the password "foobar" can have the
following encryptions:
..Tgnr41TuFZA
./yxbcvc/8IZY
and 4094 more using standard Unix crypt().
(There's only a 1/4096 chance that the same password encrypts to the
same value so that if you do not verify the clear text password but only
look at the encrypted values it is unlikely you will detect any password
reuse)