Identifying users (Confirm a phone number)

[govuk-design-system]

What

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

• authentication
• identity assurance/verification
• user accounts

Why

Anything else

• Home Office has a version of Identifying users
• HMRC has a version for Two factor authentication (2FA)
• Discussion about 2 Factor authentication on Dropbox Paper

[owenm6]

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]

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]

This the 2 factor authentication screen from personal tax account.

[catrionabudge]

Here's a 2fa code screen we're using at HO for reference

[terrysimpson99]

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]

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

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

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]

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

[quis]

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]

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]

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

[sulthan-ahmed]

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]

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

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

[frankieroberto]

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

[frankieroberto]

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

[hannalaakso]

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]

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]

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]

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

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]

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

[timpaul]

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/

[Catherine-Gilhooly]

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]

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]

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

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.