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 (Confirm a phone number) #25

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

Identifying users (Confirm a phone number) #25

govuk-design-system opened this issue Jan 12, 2018 · 28 comments
Labels
pattern Goes in the 'Patterns' section of the Design System

Comments

@govuk-design-system
Copy link
Collaborator

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 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

@timpaul timpaul added the pattern Goes in the 'Patterns' section of the Design System label May 21, 2018
@quis
Copy link
Member

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

This the 2 factor authentication screen from personal tax account.

image

@catrionabudge
Copy link

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 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 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 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 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

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

@quis
Copy link
Member

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

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 commented Sep 4, 2019

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

@sulthan-ahmed
Copy link

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

@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

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

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

3a -text-message-authentication-HR

@frankieroberto
Copy link

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

Screenshot 2020-06-01 at 11 28 41

@hannalaakso
Copy link
Member

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 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 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

@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

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

Gov Wifi team have added TOTP for their MFA
https://govwifi-dev-docs.cloudapps.digital/features/admin-2fa.html#2fa-set-up

@timpaul
Copy link
Contributor

timpaul commented May 18, 2022

Adding this great blog post from Sulthan Ahmed in Home Office: https://hodigital.blog.gov.uk/2020/10/20/passwords-are-a-pain-in-the/

@dav-idc dav-idc changed the title Identifying users Identifying users (Confirm a phone number) Dec 5, 2022
@Catherine-Gilhooly
Copy link

Minor suggestion - formatting of the guidance for error messages.
When I referred to the error messages for this pattern, I thought there was inconsistency in how the error messages were written as it looks as if full stops are being used (which goes against the style for error message component).

I also thought using the word Say and single quotes makes it look cluttered. It wasn't until a 3rd look that I realised the full stops are part of the punctuation for the guidance, and not mistakenly included in the error message text.

I think the reading layout could be improved.

AS IS:
If the user does not enter enough digits:

Say ‘You’ve not entered enough numbers, the code must be 5 numbers’.

If the user enters too many digits:

Say ‘You’ve entered too many numbers, the code must be 5 numbers’.

If the user enters non-numeric characters, other than spaces:

Say ‘The code must be 5 numbers’.

TO BE:
If the user does not enter enough digits:

You’ve not entered enough numbers, the code must be 5 numbers

If the user enters too many digits:

You’ve entered too many numbers, the code must be 5 numbers

If the user enters non-numeric characters, other than spaces:

The code must be 5 numbers

@Catherine-Gilhooly
Copy link

What does this mean: if 2 hours ago...

I don't understand what this means below in the guidance where it says if the 15 minute code has expired, but it is correctly entered more than 2 hours later ' show an incorrect security code message even if the code was correct'.

What error message would make sense to the user here, other than, it has expired? Am I missing something? Thank you in advance.

Copy and pasted from the guidance:

Give a time limit of 15 minutes for the user to enter the code — the code should expire after this time limit.

If the user enters an expired code that was sent more than:

15 minutes ago, show a ‘code has expired’ error message and send the user a new code
2 hours ago, show an ‘incorrect security code’ message, even if the code was correct

@haynes-dev
Copy link

@Catherine-Gilhooly it sounds like it's just saying you shouldn't display a "your code has expired" message if the period of time that has elapsed since the code was sent is more than two hours. Instead, if this much time has passed, then just display an "incorrect error code" message.

@Catherine-Gilhooly
Copy link

Thanks @haynes-dev
My stumbling block was, what would the error say, as all the error messages are specific, eg too many digits / too few etc. If we just use the generic message: Enter a correct security code
But the code is correct - just expired - and it is the real user, and not suspicious activity, I think this is confusing to the user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pattern Goes in the 'Patterns' section of the Design System
Development

No branches or pull requests