[keycloak-dev] Reset Password changes complete needs review

[Bill Burke]

On 8/19/2015 9:10 PM, Bill Burke wrote:
>
>
> 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.
>

Furthermore, I don't like Verify Email either.  It also should be 
changed from link clicking to code entry.  Like Reset Email, a new tab 
is opened if you click the link.  Like Reset Email, Verify email 
requires you to completely relogin if the link is clicked in a different 
browser.


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