minimum number of days between password change
Lukas Baxa
I created an account guest to test password aging.
The aging info of this account is following:
> chage -l guest
Last password change : Nov 01, 2010
Password expires : Jan 30, 2011
Password inactive : never
Account expires : never
Minimum number of days between password change : 76
Maximum number of days between password change : 90
Number of days of warning before password expires : 14
However, I'm able to change my password when logged in as guest
as many times I want the same day, even if minimum number of days
between password change is set to a non-zero value.
Does anybody know where the problem can be? I'm using an up-to-date
debian lenny (5.0.6 nowadays) and I'm using PAM.
The file /etc/pam.d/passwd looks as follows:
> cd /etc/pam.d
> cat passwd
@include common-password
> cat common-password
password required pam_cracklib.so retry=3 difok=3 minlen=12
lcredit=0 ocredit=2 minclass=3
password required pam_unix.so use_authtok md5 remember=6
The pam_cracklib module works fine and I suposse that password aging
info should be checked by pam_unix. However, it doesn't work properly
when using passwd from the command line.
On the other hand, the maximum number of days between password change
works fine and if the user guest logs in after the timeout expires,
guest is forced to change his password before login.
Can anybody give me a clue where the problem can be?
Thanks,
Lukas
--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4CCEEABA...@seznam.cz
Ron Johnson
> Hi,
>
> I created an account guest to test password aging.
> The aging info of this account is following:
>
>> chage -l guest
> Last password change : Nov 01, 2010
> Password expires : Jan 30, 2011
> Password inactive : never
> Account expires : never
> Minimum number of days between password change : 76
> Maximum number of days between password change : 90
> Number of days of warning before password expires : 14
>
> However, I'm able to change my password when logged in as guest
> as many times I want the same day, even if minimum number of days
> between password change is set to a non-zero value.
>
If someone learns my password on day 2, they have full access to my
account for 74 days, or I must beg for SysAdmin help?
"Minimum number of days" isn't a very bright idea.
--
Seek truth from facts.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bonno Bloksma
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/DCD311C5C867409E...@staf.tio.nl
Jesús M. Navarro
On Monday 01 November 2010 18:49:01 Ron Johnson wrote:
[...]
> If someone learns my password on day 2, they have full access to my
> account for 74 days, or I must beg for SysAdmin help?
>
> "Minimum number of days" isn't a very bright idea.
It is, for a low minimum number.
The rationale is to avoid the user reusing passwords: Ok, so my password is
12345678 and I must change it now? Let's do it: 87654321; but immediately I
change back again.
So if the minimum change time is about a week, it takes about the same effort
to learn the new password than to change it back.
Cheers.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201011012245.383...@undominio.net
Wolodja Wentland
> On 11/01/2010 11:28 AM, Lukas Baxa wrote:
>> Minimum number of days between password change : 76
>> Maximum number of days between password change : 90
>> Number of days of warning before password expires : 14
>> However, I'm able to change my password when logged in as guest as
>> many times I want the same day
> If someone learns my password on day 2, they have full access to my
> account for 74 days, or I must beg for SysAdmin help?
> "Minimum number of days" isn't a very bright idea.
I completely agree¹, but this policy should still be enforced or it
has to be made clear that this setting is deprecated and no longer
enforced.
--- chage manpage ---
-m, --mindays MIN_DAYS
Set the minimum number of days between password changes to MIN_DAYS. A
value of zero for this field indicates that the user may change his/her
password at any time.
--- snip ---
… which is clearly not working in the way it is described. I have not
reproduced this bug myself, but it is exactly that and should therefore
be reported - not by posting to d-d - but rather by executing "reportbug
passwd".
Regards
Wolodja
¹ There might be use cases though ?-)
--
.''`. Wolodja Wentland <wolodja....@ed.ac.uk>
: :' :
`. `'` 4096R/CAF14EFC
`- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
Ron Johnson
> Hi, Ron:
>
> On Monday 01 November 2010 18:49:01 Ron Johnson wrote:
> [...]
>> If someone learns my password on day 2, they have full access to my
>> account for 74 days, or I must beg for SysAdmin help?
>>
>> "Minimum number of days" isn't a very bright idea.
>
> It is, for a low minimum number.
>
> The rationale is to avoid the user reusing passwords: Ok, so my password is
> 12345678 and I must change it now? Let's do it: 87654321; but immediately I
> change back again.
>
The way to do it is to have a record in your password db of the
hashes of each user's last N passwords.
> So if the minimum change time is about a week, it takes about the same effort
> to learn the new password than to change it back.
>
You're Doing It Wrong if you use "minimum days" to avoid password reuse.
--
Seek truth from facts.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jesús M. Navarro
On Tuesday 02 November 2010 00:29:03 Ron Johnson wrote:
> On 11/01/2010 04:45 PM, Jesús M. Navarro wrote:
> > Hi, Ron:
> >
> > On Monday 01 November 2010 18:49:01 Ron Johnson wrote:
> > [...]
> >
> >> If someone learns my password on day 2, they have full access to my
> >> account for 74 days, or I must beg for SysAdmin help?
> >>
> >> "Minimum number of days" isn't a very bright idea.
> >
> > It is, for a low minimum number.
> >
> > The rationale is to avoid the user reusing passwords: Ok, so my password
> > is 12345678 and I must change it now? Let's do it: 87654321; but
> > immediately I change back again.
>
> The way to do it is to have a record in your password db of the
> hashes of each user's last N passwords.
>
> > So if the minimum change time is about a week, it takes about the same
> > effort to learn the new password than to change it back.
>
> You're Doing It Wrong if you use "minimum days" to avoid password reuse.
I didn't imply minimum password age was either the only or the best way to
avoid password reuse, only that it can apropriately used for that.
On Linux, in order for you to retain last n passwords you will need at least
another "device" (file, database field...) to store them you'll have to take
care of (at least under the assumption that old passwords will show a trend
that could be exploited after brute-force attack).
Cheers.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201011020344.000...@undominio.net
lee
> On 11/01/2010 04:45 PM, Jes�s M. Navarro wrote:
> >Hi, Ron:
> >
> >On Monday 01 November 2010 18:49:01 Ron Johnson wrote:
> >[...]
> >>If someone learns my password on day 2, they have full access to my
> >>account for 74 days, or I must beg for SysAdmin help?
> >>
> >>"Minimum number of days" isn't a very bright idea.
> >
> >It is, for a low minimum number.
> >
> >The rationale is to avoid the user reusing passwords: Ok, so my password is
> >12345678 and I must change it now? Let's do it: 87654321; but immediately I
> >change back again.
> >
>
> The way to do it is to have a record in your password db of the
> hashes of each user's last N passwords.
BTW, how do you do that?
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20101102202...@yun.yagibdah.de
Ron Johnson
> On Mon, Nov 01, 2010 at 06:29:03PM -0500, Ron Johnson wrote:
>> On 11/01/2010 04:45 PM, Jes�s M. Navarro wrote:
>>> Hi, Ron:
>>>
>>> On Monday 01 November 2010 18:49:01 Ron Johnson wrote:
>>> [...]
>>>> If someone learns my password on day 2, they have full access to my
>>>> account for 74 days, or I must beg for SysAdmin help?
>>>>
>>>> "Minimum number of days" isn't a very bright idea.
>>>
>>> It is, for a low minimum number.
>>>
>>> The rationale is to avoid the user reusing passwords: Ok, so my password is
>>> 12345678 and I must change it now? Let's do it: 87654321; but immediately I
>>> change back again.
>>>
>>
>> The way to do it is to have a record in your password db of the
>> hashes of each user's last N passwords.
>
> BTW, how do you do that?
>
OpenVMS does that for you. Don't know about Linux.
--
Seek truth from facts.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
> On Mon, Nov 01, 2010 at 12:49 -0500, Ron Johnson wrote:
>>> However, I'm able to change my password when logged in as guest as
>>> many times I want the same day
>
>> If someone learns my password on day 2, they have full access to my
>> account for 74 days, or I must beg for SysAdmin help?
>
>> "Minimum number of days" isn't a very bright idea.
>
> I completely agree¹, but this policy should still be enforced or it has
> to be made clear that this setting is deprecated and no longer enforced.
+1 for the enforcement.
> --- chage manpage ---
> -m, --mindays MIN_DAYS
(...)
> … which is clearly not working in the way it is described. I have not
> reproduced this bug myself, but it is exactly that and should therefore
> be reported - not by posting to d-d - but rather by executing "reportbug
> passwd".
I've tried in a lenny box and faced the same behaviour than the OP. Maybe
the new policy is to be applied _a day after_ the change or it should be
enforced _as soon as_ changed? Is a "passwd" error (not reading/applying
"/etc/shadow" mandate) or a "chage" one? :-?
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jesús M. Navarro
On Tuesday 02 November 2010 21:26:54 lee wrote:
> On Mon, Nov 01, 2010 at 06:29:03PM -0500, Ron Johnson wrote:
> > On 11/01/2010 04:45 PM, Jesús M. Navarro wrote:
> > >Hi, Ron:
> > >
> > >On Monday 01 November 2010 18:49:01 Ron Johnson wrote:
> > >[...]
> > >
> > >>If someone learns my password on day 2, they have full access to my
> > >>account for 74 days, or I must beg for SysAdmin help?
> > >>
> > >>"Minimum number of days" isn't a very bright idea.
> > >
> > >It is, for a low minimum number.
> > >
> > >The rationale is to avoid the user reusing passwords: Ok, so my password
> > > is 12345678 and I must change it now? Let's do it: 87654321; but
> > > immediately I change back again.
> >
> > The way to do it is to have a record in your password db of the
> > hashes of each user's last N passwords.
>
> BTW, how do you do that?
AFAIK you can't, at least with files backend (but that's a different issue).
Cheers.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201011030340.454...@undominio.net
Mark Allums
> Hi, lee:
>
> On Tuesday 02 November 2010 21:26:54 lee wrote:
>> On Mon, Nov 01, 2010 at 06:29:03PM -0500, Ron Johnson wrote:
>>> On 11/01/2010 04:45 PM, Jesús M. Navarro wrote:
>>>> Hi, Ron:
>>>>
>>>> On Monday 01 November 2010 18:49:01 Ron Johnson wrote:
>>>> [...]
>>>>
>>>>> If someone learns my password on day 2, they have full access to my
>>>>> account for 74 days, or I must beg for SysAdmin help?
>>>>>
>>>>> "Minimum number of days" isn't a very bright idea.
>>>>
>>>> It is, for a low minimum number.
>>>>
>>>> The rationale is to avoid the user reusing passwords: Ok, so my password
>>>> is 12345678 and I must change it now? Let's do it: 87654321; but
>>>> immediately I change back again.
>>>
>>> The way to do it is to have a record in your password db of the
>>> hashes of each user's last N passwords.
Not a serious expert, but: Bad policy? (Keeping unnecessary histories
of *anything* would tend to weaken security. Wouldn't it?)
>> BTW, how do you do that?
>
> AFAIK you can't, at least with files backend (but that's a different issue).
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ron Johnson
> On 11/2/2010 9:40 PM, Jesús M. Navarro wrote:
>> Hi, lee:
>>
>> On Tuesday 02 November 2010 21:26:54 lee wrote:
>>> On Mon, Nov 01, 2010 at 06:29:03PM -0500, Ron Johnson wrote:
>>>>
>>>> The way to do it is to have a record in your password db of the
>>>> hashes of each user's last N passwords.
>
> Not a serious expert, but: Bad policy? (Keeping unnecessary
> histories of *anything* would tend to weaken security. Wouldn't it?)
>
The key words are "unnecessary" and "history".
a) Yes, it's necessary.
b) You do *not* keep a history of the *passwords*. You keep a
history of the one-way *hashes*.
--
Seek truth from facts.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mark Allums
> On 11/02/2010 09:58 PM, Mark Allums wrote:
>>> Hi, lee:
>>>
>>> On Tuesday 02 November 2010 21:26:54 lee wrote:
>>>> On Mon, Nov 01, 2010 at 06:29:03PM -0500, Ron Johnson wrote:
> [snip]
>>>>>
>>>>> The way to do it is to have a record in your password db of the
>>>>> hashes of each user's last N passwords.
>>
>> Not a serious expert, but: Bad policy? (Keeping unnecessary
>> histories of *anything* would tend to weaken security. Wouldn't it?)
>>
>
> The key words are "unnecessary" and "history".
>
> a) Yes, it's necessary.
> b) You do *not* keep a history of the *passwords*. You keep a
> history of the one-way *hashes*.
I know it is the hashes. Everything leaves tracks. It's not the
passwords that might be compromised, it's the privacy. I expect this is
an example of extreme paranoia, but still...
An unrelated example: Incognito mode (AKA, porn mode) of Google Chrome.
Forensic researchers have published articles about how much they found
out about the user even after they used the "secure" mode.
You can't reverse the hash, but a pattern in the history file might tell
someone something you don't want them to know. Granted, you could keep
the history with root as owner and if you are rooted, well, you already
have big problems, but isn't one of the first things the black hats do
when they gain access is look for information, for further compromises?
No system is perfect, but I like simplicity. Less to go wrong.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Robert Brockway
> I know it is the hashes. Everything leaves tracks. It's not the passwords
> that might be compromised, it's the privacy. I expect this is an example of
> extreme paranoia, but still...
>
> An unrelated example: Incognito mode (AKA, porn mode) of Google Chrome.
> Forensic researchers have published articles about how much they found out
> about the user even after they used the "secure" mode.
>
> You can't reverse the hash, but a pattern in the history file might tell
> someone something you don't want them to know. Granted, you could keep the
If the hash algorithm is worth its salt (pun intended) then there
shouldn't be a pattern in the hashes even if there is in the passwords.
If the file keeps timestamp information in plaintxt that may reveal
information like when the user tends to change their password which may or
may not be useful to an attacker.
I think on balance the risk is low though.
The hash log could be subject to a brute force attack. /etc/shadow is
also subject to a brute force if someone can get root on the box. This is
useful as passwords are often resued across systems, so they could use
this to break into other systems. /etc/shadow would deliver current
rather than old passwords so it is far more valuable too.
Personally I don't think much of keeping a record of old password hashes
but for a different reason: they are easily circumvented by the user
changing their password several times until they can reuse the old one
again. Some organisations have tried to prevent this by limiting how
quickly passwords can be changed - the problem with this approach should
be obvious :)
Cheers,
Rob
--
Email: rob...@timetraveller.org Linux counter ID #16440
IRC: Solver (OFTC & Freenode)
Web: http://www.practicalsysadmin.com
Contributing member of Software in the Public Interest (http://spi-inc.org/)
Open Source: The revolution that silently changed the world
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/alpine.DEB.1.10.1...@castor.opentrend.net
Lukas Baxa
> On Mon, 01 Nov 2010 21:35:20 +0000, Wolodja Wentland wrote:
>
>> On Mon, Nov 01, 2010 at 12:49 -0500, Ron Johnson wrote:
>
>>>> However, I'm able to change my password when logged in as guest as
>>>> many times I want the same day
>>> If someone learns my password on day 2, they have full access to my
>>> account for 74 days, or I must beg for SysAdmin help?
>>> "Minimum number of days" isn't a very bright idea.
>> I completely agree¹, but this policy should still be enforced or it has
>> to be made clear that this setting is deprecated and no longer enforced.
>
> +1 for the enforcement.
>
>> --- chage manpage ---
>> -m, --mindays MIN_DAYS
>
> (...)
>
>> … which is clearly not working in the way it is described. I have not
>> reproduced this bug myself, but it is exactly that and should therefore
>> be reported - not by posting to d-d - but rather by executing "reportbug
>> passwd".
>
> I've tried in a lenny box and faced the same behaviour than the OP. Maybe
> the new policy is to be applied _a day after_ the change or it should be
> enforced _as soon as_ changed? Is a "passwd" error (not reading/applying
> "/etc/shadow" mandate) or a "chage" one? :-?
>
> Greetings,
>
Even if the discussion to this topic shows that the mindays option of
chage might not be very useful in most cases, it doesn't work as it should.
I would like to file a new bug report, but I'm not sure against which
package. I'm considering either passwd or libpam-modules. I think
that I should choose the libpam-modules package, because my passwd
command uses PAM and is configured as follows:
> cat /etc/pam.d/passwd
@include common-password
> cat /etc/pam.d/common-password
password required pam_cracklib.so retry=3 difok=3 minlen=12
lcredit=0 ocredit=2 minclass=3
password required pam_unix.so use_authtok md5 remember=6
I suppose that the pam_unix.so library/module should check the aging
information in /etc/shadow before changing the password in this file.
Am I right?
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mark Allums
> On Wed, 3 Nov 2010, Mark Allums wrote:
>> You can't reverse the hash, but a pattern in the history file might
>> tell someone something you don't want them to know. Granted, you could
>> keep the
>
> If the hash algorithm is worth its salt (pun intended) then there
> shouldn't be a pattern in the hashes even if there is in the passwords.
Not a pattern in the hashes. A pattern in the history.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
John Hasler
> Not a pattern in the hashes. A pattern in the history.
What history? There is no need to save anything but the last N hashes.
--
John Hasler
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87bp65z...@thumper.dhh.gt.org
Ron Johnson
[snip]
>
> Personally I don't think much of keeping a record of old password
> hashes but for a different reason: they are easily circumvented by
> the user changing their password several times until they can reuse
> the old one again.
Then, instead of retaining N number of hashes, you keep N number of
days/months of hashes.
> Some organisations have tried to prevent this by
> limiting how quickly passwords can be changed - the problem with
> this approach should be obvious :)
>
--
Seek truth from facts.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
> Camaleón wrote:
>> On Mon, 01 Nov 2010 21:35:20 +0000, Wolodja Wentland wrote:
>> (...)
>>
>>> … which is clearly not working in the way it is described. I have not
>>> reproduced this bug myself, but it is exactly that and should
>>> therefore be reported - not by posting to d-d - but rather by
>>> executing "reportbug passwd".
>>
>> I've tried in a lenny box and faced the same behaviour than the OP.
>> Maybe the new policy is to be applied _a day after_ the change or it
>> should be enforced _as soon as_ changed? Is a "passwd" error (not
>> reading/applying "/etc/shadow" mandate) or a "chage" one? :-?
>>
>>
>>
> Even if the discussion to this topic shows that the mindays option of
> chage might not be very useful in most cases, it doesn't work as it
> should.
I agree.
> I would like to file a new bug report, but I'm not sure against which
> package. I'm considering either passwd or libpam-modules.
(...)
"passwd" (as Wolodja suggested) should not allow the user to change his
password if "/etc/shadow" states so. Anyway, I would not worry about the
"correctness" of the package against you are to report the bug as devels
will change it if they estimate it convenient.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Wolodja Wentland
> On Wed, 03 Nov 2010 20:40:15 +0100, Lukas Baxa wrote:
> > Camaleón wrote:
> > I would like to file a new bug report, but I'm not sure against which
> > package. I'm considering either passwd or libpam-modules.
> "passwd" (as Wolodja suggested) should not allow the user to change his
> password if "/etc/shadow" states so. Anyway, I would not worry about the
> "correctness" of the package against you are to report the bug as devels
> will change it if they estimate it convenient.
Exactly. Given that we do not know what causes this bug, we have no way
to assign it to the correct package. I would therefore file a bug
against the package that ships the program that exhibits the buggy
behaviour.
Kind Regards
Lukas Baxa
> On Thu, Nov 04, 2010 at 10:55 +0000, Camaleón wrote:
>> On Wed, 03 Nov 2010 20:40:15 +0100, Lukas Baxa wrote:
>>> Camaleón wrote:
>
>>> I would like to file a new bug report, but I'm not sure against which
>>> package. I'm considering either passwd or libpam-modules.
>
>> "passwd" (as Wolodja suggested) should not allow the user to change his
>> password if "/etc/shadow" states so. Anyway, I would not worry about the
>> "correctness" of the package against you are to report the bug as devels
>> will change it if they estimate it convenient.
>
> Exactly. Given that we do not know what causes this bug, we have no way
> to assign it to the correct package. I would therefore file a bug
> against the package that ships the program that exhibits the buggy
> behaviour.
OK, good to know that the developers can change the package :-)
Thanks. I've changed my meaning and I'm going to file the bug
against the package passwd.
> Kind Regards
>
>
> ------------------------------------------------------------------------
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Robert Brockway
> Not a pattern in the hashes. A pattern in the history.
Hi Mark. That's what I meant. The history is made up of hashes and
possibly additional information.
Cheers,
Rob
--
Email: rob...@timetraveller.org Linux counter ID #16440
IRC: Solver (OFTC & Freenode)
Web: http://www.practicalsysadmin.com
Contributing member of Software in the Public Interest (http://spi-inc.org/)
Open Source: The revolution that silently changed the world
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/alpine.DEB.1.10.1...@castor.opentrend.net