[prev in list] [next in list] [prev in thread] [next in thread]
List: forgerock-opendj
Subject: Re: [Opendj] RE : RE : RE : Password policies
From: Ludovic Poitou <ludovic.poitou () forgerock ! com>
Date: 2014-04-16 15:21:15
Message-ID: CAL60-Kgx3joCQfOUQ54Bt3Nz-QmD30OAbBWFz7grqgoRZmd_+w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thanks Vincent for the JIRA issue. Great description and use case.
Regards,
Ludovic.
On Wed, Apr 16, 2014 at 5:13 PM, Belleville-Rioux, Vincent <
rioux.vincent@uqam.ca> wrote:
> n=1 would be great. However, I see a case that would benefit of having
> n>1 : if the user has his password changed by and admin and the user
> changes it again after logging in.
>
> What would then happen :
>
> 1 - User calls help desk because he lost his password. Help desk
> identifies the user and resets his password (one password change).
> 2 - Devices at home generate authentication failures because they have the
> old password stored.
> 3 - The new feature prevents the account from being locked-out because the
> old password is not counting towards the failed login attempts.
> 4 - The user logs in and changes his password himself.
> 5 - Devices at home still have not been updated and they still try to
> authenticate with the first password. This is no longer the n-1 password,
> so they count towards failed login attempts.
> 6 - The user is locked-out.
>
> So, I believe Microsoft's choice of N-2 is exactly for this reason.
>
> In order to prevent leaking any information (like, for instance, "this
> was a valid password, maybe you should try it on this user's other accounts
> on the web"), I'd suggest this feature NOT change anything in the actual
> authentication response from the server. Insofar as the authenticating
> application is concerned, the credentials aren't valid. No need to tell
> them that it was valid before. It is different then a login with an
> expired password that does require the authenticating application to know
> that, after correctly providing the credentials, they will stop working
> soon.
>
> Vincent
>
> ------------------------------
> *De :* opendj-bounces@forgerock.org [opendj-bounces@forgerock.org] de la
> part de Chris Ridd [chris.ridd@forgerock.com]
> *Date d'envoi :* 16 avril 2014 10:39
>
> *À :* OpenDJ discussion list
> *Objet :* Re: [Opendj] RE : RE : Password policies
>
>
> On 16 Apr 2014, at 15:04, Belleville-Rioux, Vincent <
> rioux.vincent@uqam.ca> wrote:
>
> Hi Ayman,
>
> I think there is confusion in the goal and the process of this feature.
>
> Expired passwords are not the cause here. I am talking about user or
> admin-initiated password changes.
>
> Also, I am not suggesting to allow authentication with the previous
> password.
>
> What is suggested is to NOT count the failed authentication request WITH
> the previous password towards the failed authentication count.
>
>
> I think I see now. So we'd need to be able to compare against the last n
> passwords in the history for a period of time. Maybe just for n=1.
>
> Would this return a different value in the password policy response
> control 'warning' field? I'm not sure the field is technically extensible,
> but that may not be important.
>
> Chris
>
>
>
> <http://irmsummit.com/>
>
>
> _______________________________________________
> OpenDJ mailing list
> OpenDJ@forgerock.org
> https://lists.forgerock.org/mailman/listinfo/opendj
>
>
[Attachment #5 (text/html)]
<div dir="ltr">Thanks Vincent for the JIRA issue. Great description and use \
case.<div>Regards,</div><div><br></div><div>Ludovic.</div></div><div \
class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 16, 2014 at 5:13 PM, \
Belleville-Rioux, Vincent <span dir="ltr"><<a href="mailto:rioux.vincent@uqam.ca" \
target="_blank">rioux.vincent@uqam.ca</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div style="direction:ltr;font-size:10pt;font-family:Tahoma">
<div>
<div style="font-family:Tahoma;font-size:13px">
<div>n=1 would be great. However, I see a case that would benefit of having \
n>1 : if the user has his password changed by and admin and the user changes it \
again after logging in. </div> <div><br>
</div>
<div>What would then happen :</div>
<div><br>
</div>
<div>1 - User calls help desk because he lost his password. Help desk \
identifies the user and resets his password (one password change).</div> <div>2 - \
Devices at home generate authentication failures because they have the old password \
stored.</div> <div>3 - The new feature prevents the account from being locked-out \
because the old password is not counting towards the failed login attempts.</div> \
<div>4 - The user logs in and changes his password himself.</div> <div>5 - Devices at \
home still have not been updated and they still try to authenticate with the first \
password. This is no longer the n-1 password, so they count towards failed \
login attempts.</div><div class=""> <div>6 - The user is locked-out.</div>
<div><br>
</div>
</div><div>So, I believe Microsoft's choice of N-2 is exactly for this \
reason.</div> <div><br>
</div>
<div>In order to prevent leaking any information (like, for instance, "this was \
a valid password, maybe you should try it on this user's other accounts on the \
web"), I'd suggest this feature NOT change anything in the actual \
authentication response from the server. Insofar as the authenticating \
application is concerned, the credentials aren't valid. No need to tell \
them that it was valid before. It is different then a login with an expired \
password that does require the authenticating application to know that, after \
correctly providing the credentials, they will stop working soon.</div> <div><br>
</div>
<div>Vincent</div>
<div><br>
</div>
</div>
</div>
<div style="font-size:16px;font-family:Times New Roman">
<hr>
<div style="direction:ltr"><font face="Tahoma" color="#000000"><b>De :</b> <a \
href="mailto:opendj-bounces@forgerock.org" \
target="_blank">opendj-bounces@forgerock.org</a> [<a \
href="mailto:opendj-bounces@forgerock.org" \
target="_blank">opendj-bounces@forgerock.org</a>] de la part de Chris Ridd [<a \
href="mailto:chris.ridd@forgerock.com" \
target="_blank">chris.ridd@forgerock.com</a>]<br>
<b>Date d'envoi :</b> 16 avril 2014 10:39<div class=""><br>
<b>À :</b> OpenDJ discussion list<br>
<b>Objet :</b> Re: [Opendj] RE : RE : Password policies<br>
</div></font><br>
</div><div><div class="h5">
<div></div>
<div><br>
<div>
<div>On 16 Apr 2014, at 15:04, Belleville-Rioux, Vincent <<a \
href="mailto:rioux.vincent@uqam.ca" target="_blank">rioux.vincent@uqam.ca</a>> \
wrote:</div> <br>
<blockquote type="cite">
<div style="font-size:12pt;font-family:Calibri;font-style:normal;font-variant:normal;f \
ont-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div style="direction:ltr;font-family:Tahoma;font-size:10pt">
<div>
<div style="font-family:Tahoma;font-size:13px">
<div>Hi Ayman,</div>
<div><br>
</div>
<div>I think there is confusion in the goal and the process of this feature.</div>
<div><br>
</div>
<div>Expired passwords are not the cause here. I am talking about user or \
admin-initiated password changes.</div> <div><br>
</div>
<div>Also, I am not suggesting to allow authentication with the previous \
password.</div> <div><br>
</div>
<div>What is suggested is to NOT count the failed authentication request WITH the \
previous password towards the failed authentication count.</div> </div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I think I see now. So we’d need to be able to compare against the last n \
passwords in the history for a period of time. Maybe just for n=1.</div> <div><br>
</div>
<div>Would this return a different value in the password policy response control \
‘warning’ field? I’m not sure the field is technically extensible, \
but that may not be important.</div> </div>
<br>
<div>Chris</div>
<div><br>
</div>
<br>
<br>
<div>
<div style="text-indent:0px;letter-spacing:normal;text-align:start;text-transform:none;white-space:normal;word-wrap:break-word;word-spacing:0px">
<div><a href="http://irmsummit.com/" target="_blank"><img \
src="http://forgerock.com/wp-content/uploads/2014/03/IRMEmailGraphic_Phoenix-1.png"></a></div>
</div>
</div>
<br>
</div>
</div></div></div>
</div>
</div>
<br>_______________________________________________<br>
OpenDJ mailing list<br>
<a href="mailto:OpenDJ@forgerock.org">OpenDJ@forgerock.org</a><br>
<a href="https://lists.forgerock.org/mailman/listinfo/opendj" \
target="_blank">https://lists.forgerock.org/mailman/listinfo/opendj</a><br> \
<br></blockquote></div><br></div>
_______________________________________________
OpenDJ mailing list
OpenDJ@forgerock.org
https://lists.forgerock.org/mailman/listinfo/opendj
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic