gmane.linux.openwall.user

Vincent Danen | 23 Jun 18:57

pam_passwdqc and history

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.

Thanks.

--

-- 
Vincent Danen @ http://linsec.ca/

headers

gremlin | 23 Jun 22:53

Re: pam_passwdqc and history

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.

It does NOT and, I hope, never will - all these "password
history policies" require storing plaintext password somewhere,
which is absolutely inacceptable. The only possible check is
whether new password is the same as current - it is the only
which can be verified using the current password hash (in that
case user can switch between two passwords, but it is really
safer to remember them than writing every new password down
somewhere).

-- 
Alexey V. Vissarionov aka Gremlin from Kremlin
<gremlin ПРИ gremlin ТЧК ru>

--

-- 
To unsubscribe, e-mail owl-users-unsubscribe <at> lists.openwall.com and reply
to the automated confirmation request that will be sent to you.

headers

(GalaxyMaster | 23 Jun 23:23

Re: pam_passwdqc and history

Vincent,

Thanks for a good question I was wondering whether it could be done on
Owl too (however, I haven't investigated the issue for real).

On Sun, Jun 24, 2007 at 12:53:51AM +0400, gremlin <at> gremlin.ru wrote:
> 
> It does NOT and, I hope, never will - all these "password
> history policies" require storing plaintext password somewhere,
> which is absolutely inacceptable. The only possible check is

Gremlin, I know at least a couple of techniques how to perform this check
without storing the plain text version of password, so you might be wrong
in your claims.  JFYI.

I'd like to see Solar's opinion on this.  I think that although it's
a little bit complicated since we need to store some additional metadata
per account this option could be implemented and it would have its users
(not only Vincent and me but a broader range of users :) ).

-- 
(GM)

--

-- 
To unsubscribe, e-mail owl-users-unsubscribe <at> lists.openwall.com and reply
to the automated confirmation request that will be sent to you.

headers

Vincent Danen | 24 Jun 04:16

Re: pam_passwdqc and history

* (GalaxyMaster) <galaxy <at> openwall.com> [2007-06-24 01:23:46 +0400]:

>Thanks for a good question I was wondering whether it could be done on
>Owl too (however, I haven't investigated the issue for real).

I had actually never thought of it before, but I'm trying to convince
some of the other folks at Mandriva to use pam_passwdqc and tcb by
default... =)  Makes for some rather stunning arguments.

>On Sun, Jun 24, 2007 at 12:53:51AM +0400, gremlin <at> gremlin.ru wrote:
>> 
>> It does NOT and, I hope, never will - all these "password
>> history policies" require storing plaintext password somewhere,
>> which is absolutely inacceptable. The only possible check is
>
>Gremlin, I know at least a couple of techniques how to perform this check
>without storing the plain text version of password, so you might be wrong
>in your claims.  JFYI.

Yeah, I wouldn't think it needed to be plaintext either, but (and I read
Solar's response to this before replying so I'm also somewhat replying
to that), I agree with his opinion.  For instance, storing it as a hash
means you can't really check to see any deviations from it (how do you
know john12 is too close to john23 without it being reverable?).  Which
means it would either need to reversible or, as stated above, in
plaintext.  Both of which, to me, are bad ideas now that I think about.
And I didn't give it much thought before posing the question as I wanted
the "expert" opinion.

>I'd like to see Solar's opinion on this.  I think that although it's

(Continue reading)

headers

Andrey V Stolyarov | 24 Jun 12:49

Re: pam_passwdqc and history


On Sun, 24 Jun 2007 gremlin <at> gremlin.ru wrote:

> 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.
>
> It does NOT and, I hope, never will - all these "password
> history policies" require storing plaintext password somewhere,
> which is absolutely inacceptable.

I'd say it is still possible to store older hashes rather than
passwords theirselves.  This will not allow to check passwords
for 'similarity' but obviously will allow to check is the new
password is exacly the same as one in the history.  And it is not
that inacceptable as storing plaintext passwords.

--
Croco

--

-- 
To unsubscribe, e-mail owl-users-unsubscribe <at> lists.openwall.com and reply
to the automated confirmation request that will be sent to you.

(Continue reading)

headers

Solar Designer | 24 Jun 03:39

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

(Continue reading)

headers

Vincent Danen | 24 Jun 04:22

Re: pam_passwdqc and history

* Solar Designer <solar <at> openwall.com> [2007-06-24 05:39:39 +0400]:

>Vincent - thank you for asking this question on owl-users rather than
>via private e-mail to me (like some others did).

You're welcome.  I wanted a "public" answer since I wanted to forward
whatever I got back to the Mandriva guys.  =)

I think it's also something that might be useful to see via mailing list
archives and such.

BTW, very good answer and made me think of some things I hadn't thought
of before.  I'm in complete agreement with you.

Of course, that doesn't stop legislaters from specifying they want or
need something like this, so if something like this were to make it's
way into pam_passwdqc (as, from my understanding, pam_cracklib is what
would be doing this, not pam_unix), I think it might make it more
palatable to some people (with the appropriate warnings/compile-time
disablers, etc.).

Thanks for the answer.  I've forwarded it off to the Mandriva
maintainers.  If nothing else, I'd like to get pam_passwdqc to replace
pam_cracklib there (not sure if I can pull off getting them to use tcb,
but we'll see).

--

-- 
Vincent Danen @ http://linsec.ca/

headers

Solar Designer | 24 Jun 05:59

Re: pam_passwdqc and history

On Sat, Jun 23, 2007 at 08:22:19PM -0600, Vincent Danen wrote:
> Of course, that doesn't stop legislaters from specifying they want or
> need something like this, so if something like this were to make it's
> way into pam_passwdqc (as, from my understanding, pam_cracklib is what
> would be doing this, not pam_unix), I think it might make it more
> palatable to some people (with the appropriate warnings/compile-time
> disablers, etc.).

I agree, except for one thing:

Of the bundled Linux-PAM modules, pam_unix both consults and updates the
password history file, whereas pam_cracklib merely consults the file (in
fact, there's some duplicate code between pam_unix and pam_cracklib).
So I think that the password history would work with Linux-PAM's
pam_unix alone and no pam_cracklib.  You might want to give this a try.
If so, replacing pam_cracklib with pam_passwdqc will not prevent the
password history from working.  (However, replacing pam_unix with
pam_tcb will.)  This might make it easier for you to get pam_passwdqc
into Mandriva.

Neither pam_unix nor pam_cracklib are a part of Owl, so this discussion
is getting somewhat off-topic for owl-users.  The aspect that is on
topic is that wider adoption of components from Owl (such as our PAM
modules) by other distributions makes our development efforts more
worthwhile and indirectly helps Owl development.

--

-- 
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

(Continue reading)

headers

Vincent Danen | 24 Jun 21:52

Re: pam_passwdqc and history

* Solar Designer <solar <at> openwall.com> [2007-06-24 07:59:12 +0400]:

>> Of course, that doesn't stop legislaters from specifying they want or
>> need something like this, so if something like this were to make it's
>> way into pam_passwdqc (as, from my understanding, pam_cracklib is what
>> would be doing this, not pam_unix), I think it might make it more
>> palatable to some people (with the appropriate warnings/compile-time
>> disablers, etc.).
>
>I agree, except for one thing:
>
>Of the bundled Linux-PAM modules, pam_unix both consults and updates the
>password history file, whereas pam_cracklib merely consults the file (in
>fact, there's some duplicate code between pam_unix and pam_cracklib).
>So I think that the password history would work with Linux-PAM's
>pam_unix alone and no pam_cracklib.  You might want to give this a try.
>If so, replacing pam_cracklib with pam_passwdqc will not prevent the
>password history from working.  (However, replacing pam_unix with
>pam_tcb will.)  This might make it easier for you to get pam_passwdqc
>into Mandriva.

Ahhhh... ok, I'll play around with this and will see what happens.  If
this does work, then pam_passwdqc can definitely replace cracklib
(although I suspect I could make it happen regardless).

>Neither pam_unix nor pam_cracklib are a part of Owl, so this discussion
>is getting somewhat off-topic for owl-users.  The aspect that is on
>topic is that wider adoption of components from Owl (such as our PAM
>modules) by other distributions makes our development efforts more
>worthwhile and indirectly helps Owl development.

(Continue reading)