[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070624013939.GA3538@openwall.com>
Date: Sun, 24 Jun 2007 05:39:39 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: pam_passwdqc and history
Vincent - thank you for asking this question on owl-users rather than
via private e-mail to me (like some others did).
On Sat, Jun 23, 2007 at 11:01:04AM -0600, Vincent Danen wrote:
> Quick question. Does pam_passwdqc support password history? Not just
> comparing the current password to the new password, but seeing if it's
> similar to, say, any of the last 3 passwords a user used? Apparently
> some government/company legislation/policies require history checking of
> current-N passwords, and I'm wondering if passwdqc does this.
No, pam_passwdqc doesn't currently have this questionable feature.
Also, it is non-obvious whether pam_passwdqc is the right place to have
this feature (if at all). It is common to have it in pam_unix instead
(this would be pam_tcb on Owl) and there are good reasons for that: it's
pam_unix or equivalent which knows whether a password update actually
succeeds or not and the password hashing method in use (so it can store
and check old password hashes in the same way).
I find password histories questionable primarily because they place old
passwords at extra risk. Those passwords may be the same or similar to
passwords still in use (or to passwords that will be used in the future)
on other accounts of the same person (including on other machines) or of
other related people.
If old passwords are stored in hashed form, then it may be impractical
(too computationally expensive) to check for and reject "similar" new
passwords. So only exactly the same passwords will be rejected. On the
other hand, if old passwords are stored in plaintext or in an easily
reversible form, such a password history poses an even higher risk (it's
an excellent "wordlist" for John the Ripper to be applied to password
files of the same organization, with word mangling rules enabled).
These two (fully hashed or plaintext-equivalent storage) are not the
only possibilities - there can be variations, such as storage of hashes
of "unified" rather than original passwords - but those are "somewhere
in the middle" in terms of risk vs. potential benefit.
Overall, password histories likely have a negative impact on systems'
security.
I was asked to add this functionality specifically to pam_passwdqc a few
times. Some people were willing to have their organizations pay for it.
On such occasions, I would explain why it is likely a bad idea - and I
was successful at that. Maybe next time someone approaches me with
such a request and is willing to have their organization compensate for
my time, I will just add this as an optional feature (including ability
to disable it at compile time to not have extra required dependencies
for building pam_passwdqc and not have to bundle password hashing code
with pam_passwdqc itself). If/when I make such a version of
pam_passwdqc public, I will add the appropriate disclaimer (similar to
this posting) to the documentation.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe, e-mail owl-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
