[keycloak-dev] Reset Password changes complete needs review
Stian Thorgersen
stian at redhat.com
Thu Aug 20 02:44:12 EDT 2015
-1000 Clicking a link is a lot simpler for most users - especially mobile/tablet users. Have you ever tried to copy/paste on a mobile!
Do not change this to requiring copy/pasting a code!
----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 August, 2015 4:04:31 AM
> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
>
>
>
> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
More information about the keycloak-dev
mailing list