[keycloak-dev] Reset Password changes complete needs review

[Stian Thorgersen]

----- 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?

> 
> 
> 
> 
> >> * 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
>