[What follows are some thoughts on usernames and identifiers. This was an extremely fun talk to put together. Many thanks as always to everyone who helped improve this talk including Chuck Mortimore and George Fletcher. – IG Sept 3 2019. If you don’t feel like reading everything, you check me out giving this talk at Identiverse in June of 2019.]

What I want to talk about

Usernames. They are the most forgotten, the most overlooked thing in our industry. They are, as we would say in the US, the “Gen X” of identity management. They show up; they do their job; they don’t get any credit. In fact, they do not get the same attention that their big brother “Password” and their little sister “Password-less” get. Instead, usernames do their job without thanks or recognition. But failing to pay attention to usernames can have major negative impacts to both B2B and B2C scenarios.

Why this talk?

Having been incredibly wrong about many things when it comes to identity, I have developed a habit: I like to re-examine my believes from time to time and make sure they are still valid. I like to root out the assumptions and the implicit principles, hold them up to the light, and see if they are correct.

Customer needs have driven me to think more about usernames. The very large program I am in the midst of at Salesforce has spurred this on as well.

But most of all – usernames are incredibly important, especially given how much use they get every day. And yet we don’t often talk about them.

5 Aspects of Usernames

There are 5 aspects of usernames that I’d like to discuss. These aspects overlap and, in the intersections, there are lessons to be learned.

Usernames:

• Are not a secret
• Must be classified as public data
• Must be memorable
• Must be unique
• Must be recoverable

Secret

There is an instructive lesson in the United State’s Social Security Number (SSN) as an anti-pattern for identifiers and usernames.

SSN was meant as a username. Well, more accurately, it was meant as internal identifier. It was something the Social Security Administration would use to tie a human to their entitlements; it was something that they would use for their business processes. And they shared this internal identifier with people and businesses.

In 1938 the SSN was created for employers to report wages to the federal government. It served its purpose well, but in 1943 its charter was expanded to identify everyone, not just wage earners. Although the SSN was not meant originally for this purpose, it was used to do so.

In 1972, the SSA gave up trying to prevent secondary uses of the SSN. Previously the Social Security Card explicated stated “Not For Identification Purposes.” But companies realized that the SSN was a convenient way to uniquely-ish identify a human.

Businesses used it to validate that the person on the phone was who they claimed to be… because who else would be in possession of their Social Security card? And in that moment, the SSN became a secret.

The need for this specific secret permeated so many of our business processes throughout our economy. This has created a massive amplifier for damage when data brokers and others have breaches.

The lesson of SSN is that identifiers cannot be secrets. Full stop. Do not do it. If you have a username or an identifier that has to be treated like a secret, then you do not have a username; you have a Zero Factor authentication method.

An identifier that acts like a secret is a Zero Factor Authentication method. Purely by possession the secret unlocks resources. 9A0919 was my employee id number at IBM many years ago. My best guess is that the mainframe had 6 characters to store employee id and when IBM go too big, they just switched to hexadecimal IDs. But just knowing my ID allowed a little bit of access to resources in Human Resources.

By the way, since biometrics cannot be secrets either, they can be used as identifiers. But this is a different talk for a different day.

Public

It is not enough to make sure that usernames are not secrets. You must also classify usernames as public in your data classification scheme. This is true for employees, partners, and customers alike.

Why? Because it will force you not put attributes related to the individual into the username. You do not want to put attributes from the account into the username such as a policy number. Airline or hotel loyalty identifiers demonstrate the problem of an identifier which is “public” but contains attributes that have value. And by classifying usernames as public it reinforces that identifiers cannot be secrets.

To be clear, I am saying that the username should be classified in your data classification system as public data. I AM NOT saying you should publicize the usernames you have – that is a self-inflicted enumeration attack.

Intersection of Secret and Public

If usernames cannot be secret and must be classified as public, then what does that mean? Well, in this currently age, it puts us identity professionals in a tricky position.

I have worked with Salesforce’s response to GDPR since the beginning of the program and I know quite well that GDPR says. In article 4(1) of GDPR enumerates kinds of Personal Information including, “such as a name, an id number… an online identifier.”  In doing so, it makes identifiers personal information and thus cannot be public. But I strongly feel that GDPR’s treatment of identifiers needs some rework and some nuance. It doesn’t consider use or purpose.

At the very least, and this is my personal opinion, I believe that internal and external identifiers require different treatment. The thing that the data processor uses to link to an individual – the internal identifier – is materially different from how the person identifies herself to the data processor and thus requires different treatment. Nuance is required.

Memorable

Part of the canon of US literature is Herman Melville’s Moby Dick – a favorite of mine. And it’s first sentence reads “Call me Ishmael.” Ishmael, the username, is not the most important part of that sentence – the “call me” part is. The power to name something is the power to control it. And by naming himself Ishmael takes control over himself, away from the Reader and away from the author.

In support of self-determination, people have to give themselves names and in the digital world this is crucially important. Identifiers need to be self-generated in B2C settings and really ought to be in all cases.

Let’s be honest, File Finalana is not self-determination; we may be used to it but it really isn’t self-determination. Oh, wait… you don’t know File Finalana. First Letter First Name Last Name. For example “I” – first letter of first name, and “Glazer” my lastname – which gives us “iglazer.” Requiring File Finalana definitely does not support self-determination.

Failure to support memorable usernames means increased account recovery calls, more on-screen help, and more customer support needs. And it also leads to duplicate identifiers because people register after not remembering what they identifier was that they used to register.

And this leads to username reuse. I’ll jus tend up using my email address because I remember it. Now this isn’t necessarily a bad thing in and of itself. But if that identifier is an email or a phone number then account take over becomes easier.

Also, when building a username scheme, you need to provide choice. If you ask for email as username and then on the very next screen the user says do not use email to talk to them… that feels strange.

Unique

No one is going to argue that at some level usernames should be unique, but this brings up 2 issues: scope and type.

You need to consider the scope of uniqueness. Is the username unique at the individual service level, the tenant level (if you are multi-tenant), globally across all of your services, or even universally unique? Do you have a clear picture of what scope you are designing for? And that picture today may change so you need to at least momentarily consider if you expect to have to merge systems or may have merger and acquisition activity in the future.

Most of us need service-scoped uniqueness. But, trust me here, if you ever have to combine systems the scope of uniqueness matters greatly.

And this brings us to the second consideration for uniqueness, which is the type of the identifier.

You might allow for a traditional username, phone number, or email all to be used to log in. And you might not even require all three to be unique for a given scope. But if you do this, you better make sure you have an “internal” identifier that is unique, and here you very much have to consider the scope of its uniqueness.

This is where the type of identifier matters. Internal identifiers, the things your services use to identify the user account within the system have to been unique at the service-scope. And if you are concerned about data subject reidentification then those internal identifiers probably ought to be unique at the global-level as well.

If you support multiple external identifiers, multiple usernames per user account then those don’t have to always be unique at the service-scope.

By the way, if you were for some reason tempted to make internal and external identifiers the same thing… just don’t do it. That is exactly the same mistake that the US made with the Social Security Number and you do not want to replicate it.

Another thing to consider is identifier reuse. Yahoo email allows people to use email addresses that were once used by someone else. Phone number certainly do. In this case, the identifier may still be unique but the person… isn’t. The person has changed. This is a difficult situation to be in if for no other reason the new possessor of the email or phone looks like an attacker in many cases.

Intersection of Memorable and Unique

My phone number is memorable. A UUID isn’t. And that’s just fine for internal identifiers but not so much for usernames and external identifiers. Arguably, 9A0919, my employee ID, was memorable (clearly as I still remember it years later) and unique, but it fails the public test.

Often the way we met the dual requirements of Memorable and Unique is via the work of File Fina Lana. Those of us of a certain age and/or who have worked in enterprise are habituated to File Fina Lana.

Story Time: Ilana and Ian

In the US there is a very talented actress, Ilana Glazer (show twitter profile) – no relation. And she and I are both on Twitter and she is very popular (show followers) – again, no relation.

For example, I have been on a popular nightly talk show – Late Night with Steven Colbert. I have been in People and Glamour magazine. I am attributed with doing some awesome things. (show tweet screengrabs)

But sadly, they mean ILAZER and not IGLAZER – File Fanalana strikes again.

Recoverable

I want to credit Justin Richer whose conversation at IDPro’s Slack workspace triggered some of these thoughts.

Usernames need to be recoverable, which is to say, that there needs to be a way to get a person back to their digital persona. Recovery means re-attaching the person to the digital persona; it does not necessarily mean they will use the same username over again.

And that‘s a good thing because reminding me that I used my old work email address to login is only useful if I can still get to that email… but I can’t! All these defunct email addresses aren’t helping. Your Geocities’ email address… no use. Your AOL instant messenger handle isn’t helping you now. All those old work emails… yeah, no help whatsoever.

Having a backup identifier can be tricky but it can help deflect some amount of username recovery calls away from your help desk.

The implication here is that recovery is more than just reminding you what your username is. It can involve reconnecting you to your digital persona and to do that safely often involves proofing or re-proofing the individual.

Selecting a Username Scheme

If we take these 5 aspects as guides, then we can evaluate different username schemes.

If I can remember my username, then I stand a better chance of not having to recover it. But being memorable is not enough.

Usernames also need to:

• Respect people’s desire for self-determination
• Respect the privacy of an individual by not including information they do not want publicized
• Help deflect account recovery help desk calls
• Resist account take over attacks

To that end, I have put together a few graphs that compare different username schemes including: email, phone number, nickname, and a set of random characters. I find it interesting that schemes such as nickname and random characters are good in terms of privacy respecting and resistant to account take-over but are poor at deflecting recovery requests. Similarly, email and phone are good from a memorability perspective but are not as good from account recovery and privacy perspective.

There is no “right” answer here but a balancing act between username requirements and their inherent strengths and weaknesses.

Summary

Identifiers:

• Cannot be secrets
• Must be classified public
• Memorable
• Unique
• Recoverable

When we have opportunities to consider usernames, consider the balancing act of the strength and weaknesses of username schemes.

Consider the power to name and that that power really ought to rest with the individual be they a citizen, customer, partner, or employee. For this is how we can support self-determination. For this is how we can take a small step to empower.

And with that call me iglazer!