Temporary Passwords

[Lucas Theisen <lu...@pastdev.com>]

I have need for a temporary password feature that will allow a password
reset by an admin to have a short term expiration.  After a recent short
conversation with Emmanuel, it sounds like this is going to be a rather
large undertaking that will require some in depth knowledge of the
AuthenticationInterceptor's password policy logic, as well as some likely
deviation from the password policy draft.  I will attach the content of our
conversation at the end of this email for posterity.

Anyway, if I understood correctly, it sounds like this might be best
accomplished by having a tempPwdPolicySubentry AT that gets added to the
person entry when the temporary policy should be in effect.  Then the
interceptor would have to check for that attribute before checking the
normal password policy delegation path.  If found, that password policy
would be used, and as soon as the password is reset by the person himself,
the tempPwdPolicySubentry would get removed.

There are still 2 more questions:
1) What triggers the attachment of the temporary password policy?  Perhaps,
a new control could be used to specify that the current modify should be
considered temporary?  Perhaps, any time a password is reset by an admin
(not self)?  Perhaps a new interceptor?
2) How is this temporary password policy configured?  Perhaps it is just a
clone of the current password policy with the expiration length tweaked
(and maybe some of the other attributes)?  Even if that, how would you
configure the temporary password expiration time?

There are probably other solutions as well.  Any suggestions?

Lucas

------------------------- ORIGINAL CONVERSATION ------------------
[09:23] <lucastheisen> any suggestions on the best way to have a temporary
password that expires on a much shorter interval than regular expiration?  I
need to allow admin to reset to a temp pwd and if not reset in 5 days, the
account gets locked...
[09:24] <lucastheisen> could add a second pwd policy to the user that gets
removed when they reset i guess...
[09:44] <elecharny> not simple, lucastheisen
[09:44] <elecharny> an entry is subject to a single PP
[09:45] <elecharny> if the tmp password is complex, that should be OK, but
the thing is that this pwd is probably sent using an unsecure channel
[09:46] <elecharny> it would be so convenient to have a tmp password that
expires on a different rule than the standard password
[09:47] <elecharny> ideally, we would add a new AttributeType to the PP :
tempPassword
[09:47] <elecharny> that would be used as a marker
[09:47] <elecharny> that can be an extension to the PP draft
[09:48] <lucastheisen> yeah, so the second pwdPolicy would be a duplicate
of the first only the expriation woudl be MUCH shorter...  then on admin
pwd reset, the user gets the short term pwdPolicy and on user reset, that
pwdPolicy gets cleared out...
[09:48] <lucastheisen> are we up for extensions to the draft?
[09:48] <elecharny> this is a draft
[09:48] <lucastheisen> (no clue how to accomplish something like that)
[09:49] <elecharny> we can do whatever we want
[09:49] <elecharny> it never made it to a RFC anyway
[09:49] <lucastheisen> how would something like that get proposed back to
the draft writer(s)?
[09:49] <elecharny> it won't be accepted.
[09:49] <elecharny> The reason it remained a draft is that the major
players never agreed on many of the semantics
[09:50] <lucastheisen> ah
[09:50] <lucastheisen> well then.
[09:50] <lucastheisen> should I go about trying to add a new ppolicy
attribute then?
[09:50] <elecharny> now, considering teh tmpPassword AT, it's a bit more
complex.
[09:50] <elecharny> (yes)
[09:51] <elecharny> the tmpPassword should, in fact, be tmpPasswordPolicy
[09:51] <elecharny> that poijnts to another PP
[09:51] <elecharny> let me check something
[09:51] <lucastheisen> k
[09:56] <elecharny> actually, everything is ruled by the pwdPolicySubentry
attribute which is a single value AT
[09:56] <elecharny> it's present in every user's entry
[09:57] <elecharny> enough to add a new one : tempPwdPlicySubentry to point
to the other PP
[09:57] <elecharny> then you have to change the logic of the PP interceptor
[09:57] <lucastheisen> authentication intercepter that is....  right?
[09:57] <elecharny> yes
[09:58] <elecharny> Kiran wrote it, I think you can safely ask him for
directions
[09:58] <lucastheisen> sounds good.
[09:59] <lucastheisen> we also need to figure out how to enable/disable
this...
[09:59] <elecharny> you mean, globally ?
[10:00] <lucastheisen> is it a new control that says the pwd reset should
enable the temp policy, or is it system wide config that whenever the admin
sets a pwd it gets the temp pwd policy (which is probably bad)
[10:00] <lucastheisen> in other words, should EVERY admin pwd reset trigger
this behavior (other than self of course)?
[10:00] <elecharny> I think it should be enough to simply update the entry
by adding the tmpPasswordPolicySubentry
[10:01] <elecharny> but this should only be done by an admin
[10:01] <elecharny> so make it a DSA operational attribute
[10:01] <lucastheisen> well, how do you know that the last pwd reset was
temp?
[10:01] <elecharny> because you don't set the last reset
[10:01] <elecharny> hmmmm
[10:01] <elecharny> interesting idea :
[10:02] <elecharny> actually, when you reset the password and want to user
to reset it in a certain delay,
[10:02] <elecharny> what you can do is *just* to change the
pwdPolicySubentry to point to the short-time one
[10:02] <elecharny> then when the user changes it, you switch back to the
long one
[10:03] <lucastheisen> thats what i was initially thinking...
[10:03] <elecharny> you just have to detect that the PP subentry is a temp
one or or lon-term one
[10:04] <lucastheisen> but still need to decide how to trigger the initial
switch...
[10:04] <lucastheisen> switching back is a simple decision... if a self pwd
reset and is temp, then switch to long term...
[10:04] <elecharny> yeah, you need to know that you were depending on a
temp PP
[10:04] <lucastheisen> but what should trigger the switch from long term to
short?
[10:05] <elecharny> maybe adding a AT in the PP subentry that says "hey,
I'm a temp PP"
[10:05] <elecharny> like tempPasswordPolicy AT, a Boolean one.
[10:06] <elecharny> but you also need to have an other additional PP, to
know which permanent PP you want to switch to
[10:06] <elecharny> in any case, this is not something you can do without
changing the spec
[10:07] <lucastheisen> could be done at the client level... just switch the
pwdPolicySubentry along with the userPassword in the modify request (or
more likely 2 separate requests)
[10:07] <elecharny> that would mean the client is aware of the PP
[10:08] <elecharny> all the PP AT are operational, because they are not
expected to be updated by the client : that would be a security breach
[10:10] <lucastheisen> that much is certainly true...
[10:18] <elecharny> I suggest you write a proposal based on this convo and
post it on the ML so that Kiran can see it

Re: Temporary Passwords

[Kiran Ayyagari <ka...@apache.org>]

Hi Lucas,

On Fri, Aug 7, 2015 at 11:00 PM, Lucas Theisen <lu...@pastdev.com>
wrote:

> I have need for a temporary password feature that will allow a password
> reset by an admin to have a short term expiration.  After a recent short
> conversation with Emmanuel, it sounds like this is going to be a rather
> large undertaking that will require some in depth knowledge of the
> AuthenticationInterceptor's password policy logic, as well as some likely
> deviation from the password policy draft.  I will attach the content of our
> conversation at the end of this email for posterity.
>
> Anyway, if I understood correctly, it sounds like this might be best
> accomplished by having a tempPwdPolicySubentry AT that gets added to the
> person entry when the temporary policy should be in effect.  Then the
> interceptor would have to check for that attribute before checking the
> normal password policy delegation path.  If found, that password policy
> would be used, and as soon as the password is reset by the person himself,
> the tempPwdPolicySubentry would get removed.
>
> There are still 2 more questions:
> 1) What triggers the attachment of the temporary password policy?
> Perhaps, a new control could be used to specify that the current modify
> should be considered temporary?  Perhaps, any time a password is reset by
> an admin (not self)?  Perhaps a new interceptor?
> 2) How is this temporary password policy configured?  Perhaps it is just a
> clone of the current password policy with the expiration length tweaked
> (and maybe some of the other attributes)?  Even if that, how would you
> configure the temporary password expiration time?
>
> There are probably other solutions as well.  Any suggestions?
>
I would take the route of extending the draft, with new attributes to
support the above
mentioned functionality instead of defining a new subentry attribute.
At the end the code needs to be modified to understand the new attribute(s)
subentry or otherwise,
so it is better to add additional features to the draft rather than
switching ppolicy configurations.

The attribute can be named something like 'tmpPwdResetTime' and when this
attribute is present
AuthenticationIntereceptor can handle it with the defined rule set.

Does it makes sense? Will it cover the use case you have in mind?


>
> Lucas
>
> ------------------------- ORIGINAL CONVERSATION ------------------
> [09:23] <lucastheisen> any suggestions on the best way to have a
> temporary password that expires on a much shorter interval than regular
> expiration?  I need to allow admin to reset to a temp pwd and if not
> reset in 5 days, the account gets locked...
> [09:24] <lucastheisen> could add a second pwd policy to the user that
> gets removed when they reset i guess...
> [09:44] <elecharny> not simple, lucastheisen
> [09:44] <elecharny> an entry is subject to a single PP
> [09:45] <elecharny> if the tmp password is complex, that should be OK,
> but the thing is that this pwd is probably sent using an unsecure channel
> [09:46] <elecharny> it would be so convenient to have a tmp password that
> expires on a different rule than the standard password
> [09:47] <elecharny> ideally, we would add a new AttributeType to the PP :
> tempPassword
> [09:47] <elecharny> that would be used as a marker
> [09:47] <elecharny> that can be an extension to the PP draft
> [09:48] <lucastheisen> yeah, so the second pwdPolicy would be a duplicate
> of the first only the expriation woudl be MUCH shorter...  then on admin
> pwd reset, the user gets the short term pwdPolicy and on user reset, that
> pwdPolicy gets cleared out...
> [09:48] <lucastheisen> are we up for extensions to the draft?
> [09:48] <elecharny> this is a draft
> [09:48] <lucastheisen> (no clue how to accomplish something like that)
> [09:49] <elecharny> we can do whatever we want
> [09:49] <elecharny> it never made it to a RFC anyway
> [09:49] <lucastheisen> how would something like that get proposed back to
> the draft writer(s)?
> [09:49] <elecharny> it won't be accepted.
> [09:49] <elecharny> The reason it remained a draft is that the major
> players never agreed on many of the semantics
> [09:50] <lucastheisen> ah
> [09:50] <lucastheisen> well then.
> [09:50] <lucastheisen> should I go about trying to add a new ppolicy
> attribute then?
> [09:50] <elecharny> now, considering teh tmpPassword AT, it's a bit more
> complex.
> [09:50] <elecharny> (yes)
> [09:51] <elecharny> the tmpPassword should, in fact, be tmpPasswordPolicy
> [09:51] <elecharny> that poijnts to another PP
> [09:51] <elecharny> let me check something
> [09:51] <lucastheisen> k
> [09:56] <elecharny> actually, everything is ruled by the
> pwdPolicySubentry attribute which is a single value AT
> [09:56] <elecharny> it's present in every user's entry
> [09:57] <elecharny> enough to add a new one : tempPwdPlicySubentry to
> point to the other PP
> [09:57] <elecharny> then you have to change the logic of the PP
> interceptor
> [09:57] <lucastheisen> authentication intercepter that is....  right?
> [09:57] <elecharny> yes
> [09:58] <elecharny> Kiran wrote it, I think you can safely ask him for
> directions
> [09:58] <lucastheisen> sounds good.
> [09:59] <lucastheisen> we also need to figure out how to enable/disable
> this...
> [09:59] <elecharny> you mean, globally ?
> [10:00] <lucastheisen> is it a new control that says the pwd reset should
> enable the temp policy, or is it system wide config that whenever the admin
> sets a pwd it gets the temp pwd policy (which is probably bad)
> [10:00] <lucastheisen> in other words, should EVERY admin pwd reset
> trigger this behavior (other than self of course)?
> [10:00] <elecharny> I think it should be enough to simply update the
> entry by adding the tmpPasswordPolicySubentry
> [10:01] <elecharny> but this should only be done by an admin
> [10:01] <elecharny> so make it a DSA operational attribute
> [10:01] <lucastheisen> well, how do you know that the last pwd reset was
> temp?
> [10:01] <elecharny> because you don't set the last reset
> [10:01] <elecharny> hmmmm
> [10:01] <elecharny> interesting idea :
> [10:02] <elecharny> actually, when you reset the password and want to
> user to reset it in a certain delay,
> [10:02] <elecharny> what you can do is *just* to change the
> pwdPolicySubentry to point to the short-time one
> [10:02] <elecharny> then when the user changes it, you switch back to the
> long one
> [10:03] <lucastheisen> thats what i was initially thinking...
> [10:03] <elecharny> you just have to detect that the PP subentry is a
> temp one or or lon-term one
> [10:04] <lucastheisen> but still need to decide how to trigger the
> initial switch...
> [10:04] <lucastheisen> switching back is a simple decision... if a self
> pwd reset and is temp, then switch to long term...
> [10:04] <elecharny> yeah, you need to know that you were depending on a
> temp PP
> [10:04] <lucastheisen> but what should trigger the switch from long term
> to short?
> [10:05] <elecharny> maybe adding a AT in the PP subentry that says "hey,
> I'm a temp PP"
> [10:05] <elecharny> like tempPasswordPolicy AT, a Boolean one.
> [10:06] <elecharny> but you also need to have an other additional PP, to
> know which permanent PP you want to switch to
> [10:06] <elecharny> in any case, this is not something you can do without
> changing the spec
> [10:07] <lucastheisen> could be done at the client level... just switch
> the pwdPolicySubentry along with the userPassword in the modify request (or
> more likely 2 separate requests)
> [10:07] <elecharny> that would mean the client is aware of the PP
> [10:08] <elecharny> all the PP AT are operational, because they are not
> expected to be updated by the client : that would be a security breach
> [10:10] <lucastheisen> that much is certainly true...
> [10:18] <elecharny> I suggest you write a proposal based on this convo
> and post it on the ML so that Kiran can see it
>
>


-- 
Kiran Ayyagari
http://keydap.com