[keycloak-dev] Reset Password changes complete needs review

[Bill Burke]

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.




>> * Change password is something initiated by an admin.  This just sends
>> an email to the user to reset their password and does not start an
>> authentcation flow.
>
> I don't understand why there's two different names/concepts here.
>

The messages would be different:

Reset password: Somebody reset your password, click the link or enter in 
the code on the web page from the email

Change password:  Your adminstrator has requested you change your 
credentials.  Please click the link to reset them.


Reset password could potentially log the user in.  Change password would 
not log the user in and just display a "Credentials Reset" message.

> Yes, we should never make it possible to guess/check usernames/emails.
>

That's what I assumed and that's what I implemented.

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