Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recover an account #84

Open
govuk-design-system opened this issue Jan 15, 2018 · 2 comments
Open

Recover an account #84

govuk-design-system opened this issue Jan 15, 2018 · 2 comments

Comments

@govuk-design-system
Copy link
Collaborator

@govuk-design-system govuk-design-system commented Jan 15, 2018

Also known as: failed sign in, account recovery, forgotten password

What

How to help users who have forgotten their sign-in details or whose account has been locked.

Why

Services that use this pattern:

@govuk-design-system govuk-design-system created this issue from a note in GOV.UK Design System Community Backlog (Agreed) Jan 15, 2018
@timpaul timpaul added the pattern label May 21, 2018
@soupdragon99
Copy link

@soupdragon99 soupdragon99 commented Mar 18, 2019

Dropbox Paper audit

On 18th March 2019 the Design System team reviewed a Dropbox Paper document discussing the ​​Failed sign in and account recovery pattern.

The aim was to reduce the number of places containing guidance and code by:

  • migrating relevant, useful content into the Design System itself
  • recording important research findings in the community backlog
  • removing the original Dropbox Paper page

Below is a record of the outcomes of that review.

If you need to, you can see the original Dropbox Paper content in the internet archive.

Review outcomes

Combine the document history discussion on Dropbox Paper with this issue and remove the original Dropbox Paper page.

Failed sign in and account recovery

How it works

Avoid using security questions

Services should avoid using security questions. They are often guessable or else easily forgotten by users.

Use a reset link in an email or SMS

Consider interaction with two-factor authentication here (e.g. reset via SMS when SMS is in use as the second factor is bad, it defeats the point of requiring two factors).

Research on this pattern

Report on guidance from CESG https://beta.cesg.gov.uk/guidance/password-guidance-simplifying-your-approach

From the report: "If using lockout, we recommend you allow around 10 login attempts before the account is frozen. This gives a good balance between security and usability (‘Ten strikes and you’re out: increasing the number of login attempts can improve password usability’, Brostoff and Sasse, CHI Workshop 2003)."

Summary

  • Account lockout and ‘throttling’ are effective methods of defending brute-force attacks.
  • Allow users around 10 login attempts before locking out accounts.
  • Password blacklisting works well in combination with lockout or throttling.
  • Protective monitoring is also a powerful defence against brute-force attacks, and offers a good alternative to account lockout or throttling.
  • When outsourcing, contractual agreements should stipulate how user credentials are protected.

Related links

NCSC blog on security questions: Are security questions leaving a gap in your security?

@terrysimpson99
Copy link

@terrysimpson99 terrysimpson99 commented Jul 18, 2019

We're going to replace account lockout with throttling in response to multiple login attempts. This is influenced by NCSC guidance at the blog mentioned above and ("throttling is preferred" https://www.ncsc.gov.uk/collection/passwords/updating-your-approach). Has anybody done this before? For example:

  • is it acceptable to start the intervals between attempts at zero seconds, then 1, 2, 4, 8 etc seconds? I seen suggestions that this would contribute a significant barrier to a machine attacker.
  • what feedback do we give the user when the delay is human-perceptible?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants