Less is more? Let email addresses be usernames

  • 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

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?

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?

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.

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

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.

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.

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.

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.

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.

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.

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)

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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store