5:26 p.m.
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
* 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.
Reset Password changes:
* A Temporary Code is included in the Email in addition to a clickable
link.
* When a user requests to be sent an email, they are brought to a new
screen. This screen allows the user to alternatively enter in the code
from the email rather than clicking on a link.
* Temporary codes can only be entered once. If it is entered wrong,
user has to start login process all over again.
* Links can only be clicked once.
* The "Enter code" screen is shown with a success message even if a bad
username or email is entered. This is how it worked before. I'm
guessing this is here to avoid guessing email/usernames?
Change Password changes:
* It is a different email than Reset Password as there is no code
Questions:
* Should we get rid of the "back to login" links and instead have a
"Cancel" button? This applies to registration
* Should "Enter code" screen show a success even if the username/email
was invalid? Do we need to protect hackers from guessing usernames?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:43 a.m.
ping. Didn't hear whether the Temporary Code addition to reset password
was or about back to login links/"Cancel" button.
On 8/16/2015 5:26 PM, Bill Burke wrote:
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
* 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.
Reset Password changes:
* A Temporary Code is included in the Email in addition to a clickable
link.
* When a user requests to be sent an email, they are brought to a new
screen. This screen allows the user to alternatively enter in the code
from the email rather than clicking on a link.
* Temporary codes can only be entered once. If it is entered wrong,
user has to start login process all over again.
* Links can only be clicked once.
* The "Enter code" screen is shown with a success message even if a bad
username or email is entered. This is how it worked before. I'm
guessing this is here to avoid guessing email/usernames?
Change Password changes:
* It is a different email than Reset Password as there is no code
Questions:
* Should we get rid of the "back to login" links and instead have a
"Cancel" button? This applies to registration
* Should "Enter code" screen show a success even if the username/email
was invalid? Do we need to protect hackers from guessing usernames?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:04 a.m.
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(a)redhat.com>
To: keycloak-dev(a)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
* 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.
Reset Password changes:
* A Temporary Code is included in the Email in addition to a clickable
link.
What's the benefit of a temporary code? Is it not easier for a user to just click the
link? Having both seems like it could confuse users.
* When a user requests to be sent an email, they are brought to a
new
screen. This screen allows the user to alternatively enter in the code
from the email rather than clicking on a link.
* Temporary codes can only be entered once. If it is entered wrong,
user has to start login process all over again.
* Links can only be clicked once.
* The "Enter code" screen is shown with a success message even if a bad
username or email is entered. This is how it worked before. I'm
guessing this is here to avoid guessing email/usernames?
Yes
Change Password changes:
* It is a different email than Reset Password as there is no code
Questions:
* Should we get rid of the "back to login" links and instead have a
"Cancel" button? This applies to registration
Cancel suggests to me that it would go back to the application. Back to login is more
clear that it goes back to the login screen. A user could have clicked the recover
password link by mistake.
* Should "Enter code" screen show a success even if the
username/email
was invalid? Do we need to protect hackers from guessing usernames?
Yes, we should never make it possible to guess/check usernames/emails.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:53 a.m.
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(a)redhat.com>
> To: keycloak-dev(a)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
2:01 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
>> To: keycloak-dev(a)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
9:10 p.m.
On 8/19/2015 2:01 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)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(a)redhat.com>
>>> To: keycloak-dev(a)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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:04 p.m.
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(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)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(a)redhat.com>
>>>> To: keycloak-dev(a)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
2:44 a.m.
-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(a)redhat.com>
To: keycloak-dev(a)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(a)redhat.com>
>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>> Cc: keycloak-dev(a)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(a)redhat.com>
>>>>> To: keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:46 a.m.
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(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
> To: keycloak-dev(a)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(a)redhat.com>
> >>> To: "Stian Thorgersen" <stian(a)redhat.com>
> >>> Cc: keycloak-dev(a)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(a)redhat.com>
> >>>>> To: keycloak-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
3:09 a.m.
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(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
> To: "Bill Burke" <bburke(a)redhat.com>
> Cc: keycloak-dev(a)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(a)redhat.com>
> > To: keycloak-dev(a)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(a)redhat.com>
> > >>> To: "Stian Thorgersen" <stian(a)redhat.com>
> > >>> Cc: keycloak-dev(a)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(a)redhat.com>
> > >>>>> To: keycloak-dev(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:54 a.m.
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(a)redhat.com>
> To: "Bill Burke" <bburke(a)redhat.com>
> Cc: keycloak-dev(a)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(a)redhat.com>
>> To: "Bill Burke" <bburke(a)redhat.com>
>> Cc: keycloak-dev(a)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(a)redhat.com>
>>> To: keycloak-dev(a)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(a)redhat.com>
>>>>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>>>>> Cc: keycloak-dev(a)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(a)redhat.com>
>>>>>>>> To: keycloak-dev(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 a.m.
Google sends link as well, see attached screenshot
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
>> To: "Bill Burke" <bburke(a)redhat.com>
>> Cc: keycloak-dev(a)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(a)redhat.com>
>>> To: "Bill Burke" <bburke(a)redhat.com>
>>> Cc: keycloak-dev(a)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(a)redhat.com>
>>>> To: keycloak-dev(a)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(a)redhat.com>
>>>>>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>>>>>> Cc: keycloak-dev(a)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(a)redhat.com>
>>>>>>>>> To: keycloak-dev(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:05 a.m.
If it makes it easier I think sending a recover password link, but not loging-in the user
afterwards is fine.
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 20 August, 2015 4:00:13 PM
Subject: Re: [keycloak-dev] Reset Password changes complete needs review
Google sends link as well, see attached screenshot
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)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(a)redhat.com>
> >> To: "Bill Burke" <bburke(a)redhat.com>
> >> Cc: keycloak-dev(a)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(a)redhat.com>
> >>> To: "Bill Burke" <bburke(a)redhat.com>
> >>> Cc: keycloak-dev(a)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(a)redhat.com>
> >>>> To: keycloak-dev(a)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(a)redhat.com>
> >>>>>>> To: "Stian Thorgersen"
<stian(a)redhat.com>
> >>>>>>> Cc: keycloak-dev(a)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(a)redhat.com>
> >>>>>>>>> To: keycloak-dev(a)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(a)lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:53 a.m.
On 8/20/2015 10:05 AM, Stian Thorgersen wrote:
If it makes it easier I think sending a recover password link, but
not loging-in the user afterwards is fine.
That might work. I think that might allow us to not have special
user-facing APIs and also avoid a stale login window.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:08 p.m.
On 8/20/2015 10:05 AM, Stian Thorgersen wrote:
If it makes it easier I think sending a recover password link, but
not loging-in the user afterwards is fine.
I implemented it so that after you type in the username for Forgot
Password, it brings you to the login screen with a message "You should
receive an email with instructions to reset your credentials". Clicking
on the link in the email allows you to log in.
I added a fork() method that clones the current ClientSession and resets
it to follow the browser login flow. This is called in the email
authenticator. I couldn't get around introducing another SPI method.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:30 a.m.
On 8/20/2015 10:00 AM, Stian Thorgersen wrote:
Google sends link as well, see attached screenshot
Not in the USA. For me I get a text: "Your Google verification code is
XXXXXX".
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:34 a.m.
Did it send "Your Google verification code" to email? That's what I get on
SMS if I recover through SMS. If you have another recovery email address associated with
your account you should get the email I pasted.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 20 August, 2015 4:30:40 PM
Subject: Re: [keycloak-dev] Reset Password changes complete needs review
On 8/20/2015 10:00 AM, Stian Thorgersen wrote:
> Google sends link as well, see attached screenshot
>
Not in the USA. For me I get a text: "Your Google verification code is
XXXXXX".
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3170
days inactive
3174
days old
16 comments
2 participants
participants (2)
-
Bill Burke -
Stian Thorgersen