[keycloak-dev] Reset Password changes complete needs review

[Bill Burke]

On 8/19/2015 2:01 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 18 August, 2015 4:53:44 PM
>> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
>>
>>
>>
>> On 8/18/2015 9:04 AM, Stian Thorgersen wrote:
>>> Can you elaborate on what the benefits are of these changes? It seems to me
>>> that we had something that was working just fine..
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Sunday, 16 August, 2015 11:26:54 PM
>>>> Subject: [keycloak-dev] Reset Password changes complete needs review
>>>>
>>>> Here's what I did, I can change things based on questions I asked in
>>>> other emails, but here's how it works.
>>>>
>>>> There's now the concept of "reset password" and a different one "change
>>>> password".
>>>>
>>>> * Reset password is something the user initiates.  This will start an
>>>> Authentication Flow and success will login the user and bring them to
>>>> their application
>>>
>>> I assume this is still through email - if so it's important that users are
>>> only logged-in if the reset password link is opened in the same user
>>> session as they initiated the reset password flow
>>>
>>
>> With the previous impl, if somebody as able to hack your email account,
>> then they could bypass OTP entirely.  Also previous implementation
>> wasn't really compatible with auth SPI.  There may be additional steps
>> to reseting credentials beyond an email, i.e. entering in a code from an
>> SMS message.  We may also be reseting both OTP and Password.  Finally,
>> the update password required action had reset-password specific logic
>> within it.
>>
>> Honestly, I'd prefer to switch exclusively to a temporary code as it
>> makes everything much simpler to support:  for us and for users wanting
>> to write extensiosn.  I don't think this is a big usability issue as
>> Google requires entering a temporary code from an SMS message.  Also,
>> with the way it worked in 1.4, out-of-band email password reset would
>> require relogging in which is actually more steps.  Finally, links can
>> be messed up by email readers sometimes if they are long enough, making
>> them error prone.
>
> -100 We should stick with link in email (and only link, not confuse users by having multiple options), but why can't the link just include the same code?
>

I also don't want multiple options.  I want to get rid of the link entirely.

I'm repeating myself, but, This is about your requirement of out-of-band 
link-clicks not logging in the user.  That kind of flow is not 
compatible with the current Auth SPI and it requires hacks to required 
actions like Update Password to even work (which already exist).  We're 
also going to have to make users aware of it and explain how to code for 
it if they are writing their own extension.  It just makes things a lot 
more complicated if you are extending things.

Finally, I don't like the link because at least for me, it opens a brand 
new tab and leaves the original still active.  I also don't think the 
link is more user-friendly when the link is clicked in another browser. 
  It is also possible the user is obtaining the link on a phone and that 
our update password screen will be a bit cramped there.  Also, typing in 
a password from a phone is quite awkward and time consuming.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com