Less is more? Let email addresses be usernames

My consultancy received a query from a client on what the new system they were developing should ‘do’ in terms of user account creation:

• generate and assign a numerical account ID (e.g.: 024171) — user must now remember this and needs it to login, get support etc
• generate and assign a alphanumeric account ID (e.g: user2810 or <firstname><lastname><random number>) — user must remember this and needs it to login, get support etc
• let the user pick an alphanumeric username (which now has to be checked for existing usernames) — they still need to remember this
• something else — ???

Hooray, another login window

I thought about this query for a little while then asked around in relevant circles if there were any good articles to help one think this through or data-driven guidance on what to do here (current best practices or justifications) — I couldn’t find any, so here I am, writing down the thought process we went through with the client.

The drawing board

Some of the questions (not in order) we helped our clients asked themselves to find an answer to their own query.

Does your system require a username at all?

If you offer other systems, can you federate the identity so it is valid across all of your services? Can you use Google or Facebook sign-in?

Not many systems that are externally facing (not just for your own staff) can work purely from magic authentication email links or rely solely on hardware tokens such as smart cards or YubiKeys.

Is what is behind the authentication (username/password) justified to be behind a username/password or should it be open?

Could they legitimately share the account?

In general, Jim sharing this account with Jack is probably a bad idea (for everyone) but is there a legitimate use-case for this within your system?

If so, probably change the system?

What if they forget?

Whether they picked it themselves or you assigned it to them, what do they do when they forget it? How painful or annoying is that for both you and the user? Do they have to call a support number? Does it stop them from potentially doing an urgent thing they need to do?

Don’t make assumptions around password managers

Password managers are not a magic bullet but they are overall beneficial but you can’t assume that your user has one so you can give them a complex username to use because you think they don’t have to actually remember it anyway.

Could the same user legitimately require more than one account?

This really depends on your system and purpose and what other systems you might also operate that the same user could want to use — but overall, in general, multiple accounts for the same individual should be rare.

• online banking — no
• social media — probably shouldn’t (multiple individual accounts, but may have personal account plus organisational ones)
• email —usually don’t require multiple accounts within the same domain (user1@domain.tld and user@domain.tld are the same human)
• productivity suites (G-Suite, Office 365) — maybe, probably shouldn’t unless administrative roles
• work/task management (Atlassian, Trello.com) — maybe, probably shouldn’t unless administrative roles

Could the user have more than one account but they should be kept separated?

This is nuanced of the question above: the example that came to mind when asking it was Amazon Web Services (AWS) console where my username can often be the same but as the login page asks me for an account/organisational identifier.

My username/password for AWS could actually be the same throughout (they are not!) but the account/organisational identifier ensures I login to the right one at the time.

What other information do you collect?

Do you collect other information in the account that could be used as a username?

Do you do account-level action tracking/audit?

The answer should be ‘yes’.

Tied into a previous question, if you assume each account is a unique individual and never shared, do you associate activity to an account or something else (hopefully something, rather than nothing) — the ability to reasonably identify the human end-user may well be a legal requirement etc.

I say ‘tracking/audit’ but this isn’t privacy defying — Amazon.com do the same to associate your previous purchase history to your account (simples and makes sense to all)

The answer on this occasion

On this occasion life was straight forward and the answers to the above was simple: the human shouldn’t shared their account and will should only have one.

The client’s system requires their email address as part of the account — fortunately they had already thought about email verification (sending an email with a verification link to ensure the email address was entered correctly and does belong to the user) through some previous advice we had given them some time ago.

The answer: their email address is used as their username.

On this occasion, the answer was not to federate sign-on to Google or Facebook and while the client does have multiple systems the same user could be using the time+cost+effort in creating a federated account system was too difficult to do right now but it is now on the cards — we’re now doing some work with them to help them figure out how hard this will be, as their other systems are based on third-party software which on face-value have no support for federated identities or SSO.

Reflective questions

Some we asked ourselves and/or the client to sanity check what was being decided on and some questions you may or may not be asking yourself while reading this post.

But email addresses are personal data?!

Yes, but the client’s system is already collecting that personal data in the ‘account’ a long with a bunch of other stuff.

Data Protection and Privacy considerations already applied — if they had chosen to assign a random username to the user they would have still been obtaining personal data and would now have to consider the random username also personal data.

The benefit of not needlessly making the user remember yet another piece of information far outweighs the burden of protecting the personal data (which this client already had to do)

Email address as username, isn’t that dangerous?

We provided some advice on how they should be careful about logging and debug data — their system generates a UUID for the account anyway so application debug logs (and so on) use the UUID not the email address to reference the account.

The client (through their GDPR programme, which we advised on but another consultancy led) already understands what log data they generate, what they contain and where it goes, who has access and how long they keep it for — they treat all of those logs as containing personal data to ensure their security approach is highest common denominator while appropriately balancing ‘security’ to ensure it is not over-egged or makes staff doing their job difficult.

Isn’t this password re-use?

No, this is username re-use which is entirely different.

Doesn’t this mean an attacker has one less thing to find out?

Yes, email addresses are far more more ‘known’ in general however the username/password (now, emailaddress/password) combination remains a single factor.

This client can’t enforce (require) multi-factor authentication because of this system’s user-base and some usability needs — but they will be making it available (as Google/Authy TOTP style) and encouraging users to enable it when they are happy to do so.

The onus for account security is split between the account holder (user) and the account provider (system/organisation) — the former should keep their account details private and unique (avoid password re-use) but the latter is responsible for anomaly detection, brute-force prevention, appropriate at-rest encryption (password hashing etc) and checking hashes against known-bad lists like HIBP.

I’d argue in the account security responsibility diagram/chart, it is skew towards the account provider.

Overall, while a attacher can now ‘know’ the username with confidence, this isn’t really much of a leg-up (for the attacker) and on balance is proportional organisational/system risk-taking as the mutual benefits of a better username choice outweighs the security risks that directly stem from the same.

What if an attacker (etc) gets a hold of their email account?

This is the same risk as them doing it before — all you can do as the system operator is detect stuff that looks weird (as above)

What if the user uses a temporary/disposable/one-time email account for sign-up?

The nature of this client’s system doesn’t make us think the user is motivated to do that but yes that is entirely possible… and to be perfectly honest I haven’t finished thinking through what that means (this whole thought process spurred by a client’s contextual query)

What if the user uses an email mutation they forget?

It is relatively popular to do things like emailaddress+somethingmadeup@gmail.com and indeed this is forgettable but directly comparable with a randomly generated username that you assign to the user.

Your lost username/password recovery workflows will help your user here.

What if the user uses a shared email account?

Shared email accounts aren’t uncommon but unfortunately out of control — we’ve given our client a reminder/guidance that their T&Cs and sign-up pages should explicitly ask/remind and require the user they should be the only one with access to the email inbox.

In essence, you can only ask/remind/tell/require as attempting to detect such programmatically would be a fools errand.

What if the user loses access to / changes their email account?

If the account contains the email address (in this case, it would have done) then the login itself will keep working but your messages to the user by email may bounce and any email re-verification workflows will fail (user can’t click the link or read the code etc)

Generally you should want to ensure you have the right email address (etc) for the user… how you keep that up to date is down to you (not one-size-fits-all answer I’m afraid) but ultimately if you’re in scope for the EU General Data Protection Regulation (GDPR) and/or UK Data Protection Act 2018 — keeping personal data current and up to date is a legal requirement.

What if someone else inherits that email account?

Similarly to another answer from one of the questions to the above: this isn’t a system problem (but yes the operator should consider it and try and detect it) but overall a common risk and a tough one to solve without frequent email re-validation workflows and/or asking if their email address (etc) is still correct every time the user signs-in (etc)

It would’ve been nice to have some stats

When I asked around, someone in an informal cross-UK government chat system provided some informal statistics from one of their old (now replaced) systems which used randomly generated usernames.

40% of support calls were about the user having forgotten their username or being closed but getting it wrong — I imagine the username was something like ‘sn58wna7a’ or ‘user01831’

In another system, they have a 15% error rate when sending people emails because their account does also require the user’s email address but it is never validated (fake or mis-entered email addresses are never verified so emails sent bounce) and this presents a Data Protection issue (information you hold should be accurate) as well as security bulletin, account updates communication problem — fortunately the email verification workflow our clients will implement nips this in the bud.

You might find other exciting posts in my Medium profile. I’m on Twitter as @JoelGSamuel.