[keycloak-dev] Reset Password changes complete needs review

Thu Aug 20 10:00:13 EDT 2015

Google sends link as well, see attached screenshot

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 August, 2015 3:54:40 PM
> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> 
> And yet with Google, you enter in a temporary code to reset credentials.
> 
> You talk about this "single argument", but it is more than that...With
> us, a brand new tab is opened when you click the link leaving the old
> one open. Leaving that old window in a stale state where a user may or
> may not get an error message if they try to use that window.  (This
> problem existed prior to the Auth SPI).
> 
> And, if you read my email, its more than just being incompatible, its
> something we'll have to explain in detail in the documentation as well
> as provide "hack" APIs just to support when users want to write
> extensions.  It also forces required actions to be aware of the context
> they are called in.  Its a mess...It as all fine and dandy to hard code
> this stuff before, but now that we have a public API we can't have all
> these special cases as writing extensions becomes a real pain in the ass
> for users and for us as we'll be answering the same questions over and
> over..."Why doesn't this work?"  "Well, did you read section 9.2.1.1 of
> the manual, paragraph 2 where it says you have to call this special API
> call and manage a cookie?"
> 
> 
> On 8/20/2015 3:09 AM, Stian Thorgersen wrote:
> > Attached screenshots of reset password from Facebook, Redhat, Twitter and
> > Microsoft. All, but Microsoft, send a reset password link. Other websites
> > where I've recently changed my password also all send links.
> >
> > It's clearly easier for users to click a link than copy/pasting, which
> > would include finding the original window/tab. If the email is delayed
> > with a few minutes the user may quite likely have moved on to something
> > else and might have closed the original window.
> >
> > This all boils down to a single argument and that is that it's not
> > compatible with the current authentication SPI. That's a problem with the
> > SPI that needs resolving.
> >
> > What would work fine is that we store the required context in an encrypted
> > cookie. Only if the cookie is available would we proceed with loging-in
> > the user. Otherwise the user would only be allowed to reset the password
> > and would then have to go back to the application to re-login with the new
> > password. In that case resetting the password is not an authentication
> > flow, but an action that a user is permitted to do with a special
> > temporary key.
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 20 August, 2015 8:46:15 AM
> >> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> >>
> >> By the way try reset your password on any website, they will all send you
> >> a
> >> link you need to click
> >>
> >> ----- Original Message -----
> >>> From: "Stian Thorgersen" <stian at redhat.com>
> >>> To: "Bill Burke" <bburke at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Thursday, 20 August, 2015 8:44:12 AM
> >>> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> >>>
> >>> -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
> >>>>
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: google.png
Type: image/png
Size: 72323 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150820/dcd0ce57/attachment-0001.png