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

Identifying users #25

Open
govuk-design-system opened this issue Jan 12, 2018 · 23 comments
Open

Identifying users #25

govuk-design-system opened this issue Jan 12, 2018 · 23 comments

Comments

@govuk-design-system
Copy link
Collaborator

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

What

Provide a secure service by accurately identifying users. Includes guidance on:

  • authentication
  • identity assurance/verification
  • user accounts

Why

Anything else

@govuk-design-system govuk-design-system created this issue from a note in GOV.UK Design System Community Backlog (Agreed) Jan 12, 2018
@owenm6
Copy link

@owenm6 owenm6 commented Mar 1, 2018

We have updated our guidance on identifying users. Most of it is around authentication - https://home-office-digital-patterns.herokuapp.com/patterns/identifying-users

@quis
Copy link
Member

@quis quis commented Sep 17, 2018

Few short observations about doing two factor authentication (I was writing this down for someone anyway so thought I might as well put it here).

By text message

Front-load the code in the text message

Do this:

12345 is your code

Not

your code for Service Name is 12345

Call it a ‘security code’

This is friendlier than ‘2FA’ or ‘two factor’. I think Verify use this wording this as well.

Question how long the code needs to be

6 digits seems to be standard for authenticator apps. 4 or 5 feels way easier to transpose from one place to another. Anecdotally people with dyslexia find long codes troublesome.

By email

If using email for quasi-two-factor authentication make it a tokenised link, not a code that people have to copy/paste.

@stevenaproctor
Copy link

@stevenaproctor stevenaproctor commented Nov 22, 2018

This the 2 factor authentication screen from personal tax account.

image

@catrionabudge
Copy link

@catrionabudge catrionabudge commented Aug 22, 2019

Here's a 2fa code screen we're using at HO for reference
Screenshot 2019-08-22 at 12 48 00

@terrysimpson99
Copy link

@terrysimpson99 terrysimpson99 commented Aug 22, 2019

Is it acceptable for the page content to omit the number of digits?
Thus
"We just sent a 6-digit access code by text to: ********534"
could be
"We just sent an access code by text to: ********534"

@sulthan-ahmed
Copy link

@sulthan-ahmed sulthan-ahmed commented Sep 4, 2019

@quis we followed your guidance for authentication by email. We send the user a token link that expires in 24 hours. If they click on the link, they get access to our form and then we destroy the token. However, some users are having problems. Our users work in organisation. These organisations have security policies or infrastructure that we don't have control over. When the users click on the link, the website says something along the lines of "this link has been already used or it's invalid please make a new request".

If the user copy and paste the link instead of clicking it then it actually works

We are considering the following options:

  1. removing the bit that destroys the token if a user uses the link. Therefore, they can use the token as many times as they want in the 24hour period and seeing if that works
  2. Or redesigning the login so they have to use a code to log in

We'd be interested in your advice or anyone else's

@quis
Copy link
Member

@quis quis commented Sep 4, 2019

@sulthan-ahmed we have seen the same problem occasionally, but haven’t got round to fixing it yet. There’s a story in our backlog here: https://www.pivotaltracker.com/story/show/158630655

Lots of things click links before you can. Email virus scanners might click links to check their > content for malware. Instant messaging apps might click links to render previews.

Our magic email link logins are one-time only. We need to make sure that if a link is clicked by a robot, the real person can still click that link and sign in after.

Some potential solutions:

  • A link can be used multiple times
  • A link’s expiry time gets closer after it’s been used once
  • The user has to click a button on the page they get from the email link
  • Email users a short code that they then enter, same as SMS
  • User agent filtering
  • javascript redirect (with fallback to button/link)

User agent filtering is discounted because there’s no reliable way to whitelist or blacklist user agents (eg the automated ones we’ve seen still contain ‘Mozilla’).

Short code is discounted because:

  • it’s placing additional burden on the users
  • we saw people struggle with it (navigating multiple tabs etc) in very early Notify user research

If it’s one particular organisation you’re dealing with maybe you can get their IT team to turn this behaviour off?

@sulthan-ahmed
Copy link

@sulthan-ahmed sulthan-ahmed commented Sep 4, 2019

Super stuff @quis thanks for the rapid response. Ahh useful to know the background

Lots of things click links before you can. Email virus scanners might click links to check their content for malware. Instant messaging apps might click links to render previews.

Also we never thought of the solutions you suggested. That's very helpful. Question what do you mean by the last two bullets

The user has to click a button on the page they get from the email link
javascript redirect (with fallback to button/link)

Also why did you cross our Email users a short code?

@sulthan-ahmed
Copy link

@sulthan-ahmed sulthan-ahmed commented Sep 4, 2019

I see your the comments in the pivottracker about discounting the options

@quis
Copy link
Member

@quis quis commented Sep 4, 2019

The user has to click a button on the page they get from the email link

This would change the flow from:

User clicks link in email → Check token → Redirect user to service

To:

User clicks link in email → Show page with button to user → User click button → Check token → Redirect user to service

javascript redirect (with fallback to button/link)

Same as above, but Javascript ‘clicks’ the button for the user, if it’s available. This is working on the assumption that things like virus scanners won’t be running Javascript.

@sulthan-ahmed
Copy link

@sulthan-ahmed sulthan-ahmed commented Sep 4, 2019

Here is an idea that came from our Test manager, Chris Long

Here's an idea, combining the first & 3rd bullet points; we enable the link to be used multiple times, but expire it when the user clicks the Start button

@quis
Copy link
Member

@quis quis commented Sep 4, 2019

@sulthan-ahmed that sounds like a neat solution if you have that subsequent page anyway.

@sulthan-ahmed
Copy link

@sulthan-ahmed sulthan-ahmed commented Sep 4, 2019

yeah we do @quis thanks for bouncing the idea off with us. I think it's kind of similar to the approach you said
The user has to click a button on the page they get from the email link

@sulthan-ahmed
Copy link

@sulthan-ahmed sulthan-ahmed commented Sep 13, 2019

@quis user tested and it looks like it went well. All positive reactions. We are planning to go live next week. I'll keep you updated with what our users say

@idavidmcdonald
Copy link

@idavidmcdonald idavidmcdonald commented May 13, 2020

On GOV.UK Notify we recently came across this problem and came up with a solution so thought I'd share.

Problem

For people that sign in with username and password and use text message 2fa (often with a personal phone number), there’s no way for us to know if they still have access to their inbox. This means people can leave an organisation, have their email account closed, but if the team doesn’t remove them from the Notify account, they’ll still have access forever. That’s not good.

Solution

So we should periodically send people that use text message 2fa an email, so that we can confirm the email account is still valid and they have access. It’s not foolproof, but it’s a good backup measure.

When someone is logging in and they:

are on text message 2fa AND
are in an active state AND
last time email address was 'validated' was >=90 days ago

‘validated’ includes password changed at (which is also updated when you first create your account) and these re-validations - so we’ll need to store a date of last validation against a user and bump it each time either of these events happens.

Then we show them an explanatory screen and send them a re-validation email after they enter the text message 2fa code.

Until they click the token in the email, they can’t do anything. They could log on again to trigger another re-validation email (not locked out or anything).

image

@frankieroberto
Copy link

@frankieroberto frankieroberto commented May 28, 2020

DWP are using SMS authentication via their DWP Authenticate service (see blog post):

3a -text-message-authentication-HR

@frankieroberto
Copy link

@frankieroberto frankieroberto commented Jun 1, 2020

This is how the 2FA screen currently looks in Government Gateway:

Screenshot 2020-06-01 at 11 28 41

@hannalaakso
Copy link
Member

@hannalaakso hannalaakso commented Jun 4, 2020

Posting this on behalf of a user:

The team had an IT Health Check audit conducted and not having autocomplete set to off on login form fields (username & password) was identified as a security risk.

The team had a conversation with their Accessibility team regarding this and the steer was to set autocomplete to off for sensitive information and include it in the accessibility statement. One of the cited sources is https://knowbility.org/blog/2018/WCAG21-135InputPurpose/

It would be good to know if other teams have been advised to do this by their security or IT teams.

@matthewford
Copy link

@matthewford matthewford commented Jun 5, 2020

Posting this on behalf of a user:

The team had an IT Health Check audit conducted and not having autocomplete set to off on login form fields (username & password) was identified as a security risk.
The team had a conversation with their Accessibility team regarding this and the steer was to set autocomplete to off for sensitive information and include it in the accessibility statement. One of the cited sources is https://knowbility.org/blog/2018/WCAG21-135InputPurpose/

It would be good to know if other teams have been advised to do this by their security or IT teams.

It's a common issue that gets brought up. It does seem to go against this guidance: https://www.ncsc.gov.uk/blog-post/let-them-paste-passwords

And I'm pretty sure most password managers in browsers or addons just ignore it anyway.

If a site sets autocomplete="off" for username and password fields, then the browser still offers to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits the page.

From Firefox's docs

@mptorz
Copy link

@mptorz mptorz commented Sep 10, 2020

I can see that discussion from hmrc/design-patterns#117 was moved here, but I don't see any progress.

I am stucked getting the We cannot confirm your identity error. It is really poor UX for me. There is no action I can take to reverify my identity. After a few years I suddenly lost access to my personal tax account and all other gov.uk services and there is no clear way to solve this problem for me. The helpline sent me to tech support, tech support did not really help at all. I think the error should be more informative and there should be a clear action for the user to take.

@hannalaakso
Copy link
Member

@hannalaakso hannalaakso commented Sep 28, 2020

@mptorz Could you please contact us through email or Slack so that we can see if there is a way to redirect your query?

@idavidmcdonald
Copy link

@idavidmcdonald idavidmcdonald commented Mar 19, 2021

How long should a 2fa code be valid for before it expires. Here I am thinking about the case of a user requesting a code on a web page and then receiving that code on their mobile (which may be a separate device) and then needing to enter that code into the web page and click submit before their code has been considered expired.

2fa SMS codes are currently valid for 30 minutes on GOV.UK Notify.

We sometimes get people advocating for shorter time, as low as say 60 seconds, likely for the reasons of 'security'.

I believe the accessibility regulations would require us to take an estimate of how long a user without accessibility needs may need to do the task and then times that number by 10 to give extra time to those with accessibility needs.

At a finger in the air estimate, a user without accessibility needs after receiving the code may need as much as 30-60 seconds to locate the code, enter the code and click submit, meaning that we would likely suggest a minimum of 5-10 minutes. This doesn't take into account any time spent between the code being generated and it arriving on the users phone which will often be within a minute but could sometimes be longer.

The situation should also be considered if the code is sent via a different channel such as email (my hypothesis is that you need slightly longer to navigate and log in to your email account then you would to get to your text messages).

The minimum amount of time a code should be valid for may differ dependant on the service but if any guidance/pattersn are produced on this, I would like to see a minimum and/or suggested time validity :)

@idavidmcdonald
Copy link

@idavidmcdonald idavidmcdonald commented Apr 1, 2021

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Linked pull requests

Successfully merging a pull request may close this issue.

None yet