On 17/12/2014 03:22, Ryan Feeley wrote:
The user can be sent to the "account locked" screen as the result of three
actions:
1) sign in
2) delete account (from settings)
3) change password (from settings)
Thanks for this! I updated the flow to accommodate the additional cases.
I imagine the original tab, if still open and verification occurs in the same
browser, should complete whatever it was trying to do.
This is definitely tricky, especially when it comes to deleting the account.
Thinking through the currently known scenarios, and that locked accounts will
not happen often, it’s probably best to keep it simple, and just show the same
experience for all users.
I wholeheartedly support the "this is a very uncommon scenario, keep it
simple" philosophy here :-)
The user attempts to perform a high-security action and is informed that the
account is in “lockdown”. Clicking the email unlocks the account, and if they
are attempting a delete or change password, they can then try it again.
So what I’m proposing is that we introduce the Lockdown screen as soon as the
user clicks the Delete Account or Change Password link, and not after they have
initiated the action.
From a technical standpoint, I'll note that the frontend will be able
to poll for the lockout status of an account using the
/v1/account/status endpoint.
Link again:
https://www.lucidchart.com/documents/view/a8190a33-b8f3-448c-bc9c-474528e46d37
Thanks for this Ryan, I'm looking forward to seeing it all come together.
Some notes below, based on my understanding of the core technical
details of lockout as currently conceived. (Which makes "those
technical details will have to change to make for a better experience" a
perfectly valid reply...)
* Re: the "Locked state" diagram on the first tab.
Being "in lockdown" is a property of the account, not of a particular
device, so I'm not sure the new-device/old-device/attacker-device
distinction is useful.
On the backend, the account is put on lockdown as a result of very high
rate of failed login attempts, regardless of what device(s) the attempts
came from. Once in this state, the "you can't do that because the
account is locked" error applies uniformly to anyone attempting a
high-security operation.
I'm not sure how to offer "previously used device -> experience
unchanged" in a useful way. Is this safe to do in the event of a
lost/compromised device? And how do we identify a previously-used
device anyway?
Branching on whether the password is correct seems to defeat the major
purpose of lockdown, which is to prevent brute-force password guessing
attempts. When the account is in lockdown, we must not leak any
information about correctness of submitted passwords.
Relatedly, the "signing-in/not-signing-in" distinction is an illusion.
All three of the operations in question require the user to enter their
password, which is why they're on the lockdown list - these are all the
operations that provide an opportunity for password guessing by an attacker.
* Re: the "Lockdown to Attacker" screen on the second tab.
I question whether this screen is useful. What do we gain by showing
this screen rather than the "Lockdown to User" screen?
For an attacker triggering lockdown maliciously, I don't really care
about them having a nice UX. They're probably hitting the backend APIs
directly anyway.
For a user who triggers lockdown accidentally (e.g. by trying to
brute-force their own forgotten password) the "Lockdown to User" screen
seems more useful than "Lockdown to Attacker".
Cheers,
Ryan
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
