Ian Glazer - The Most Forgotten Thing in Identity Management

There we go first. Thank you. It is a continued honor, a continued privilege to be able to come and speak with you tonight. Previously last year, the talk I gave was the most difficult I've ever had to put together. The most difficult to deliver. This one was the most fun. So I hope we enjoy it. What I wanna talk about pretty simple usernames. We never talk about usernames.

They are, they show up, they do their work. They're the most used things in identity management and no one thinks about 'em and I figured, well, maybe we should do that.

Well, you see username are overshadowed by like everything in the industry like passwords, or like passwordless login. Like they show up, they do their job. No one thinks about 'em and the thing is you can't ignore. 'em they're really important. So let's see what we can do. So why?

Well, first and foremost, I have been comedically wrong about many things in identity management. And so I developed a habit. I take an idea off the shelf. I dust it off. I take this belief, I shake it and I see if it's still valid. And I happen to be doing this with usernames recently, partially because it was driven by my customers over the last 18 months to drive me to think about username schemes, partially it has to do with the program that I'm in the middle of right now at Salesforce. And I thought let's spend, you know, next couple of minutes talking about them. All right. So here we go.

There are five aspects of usernames. Usernames are not secrets. They must be classified as public data. They must be memorable. They must be unique and they must be recoverable or to dig into all five. Here we go. Let's take care of the big one. First usernames cannot be secrets. Repeat user repeat usernames cannot be secrets. We're gonna work on this sad to say, there are many reasons not to emulate the United States right now. Those include our haircuts, our athletic prowess and our physique. But most importantly, our social security number just don't do it. Right?

So here's what happened originally in 1938, it was meant as a username for employers who report wage earner data. That was the mission. 1943. It gets a little bit of scope creep and the government decides to use it, to identify everyone never designed to do that. Seems like a good idea. At the time it took until 2008 to undo this in 1972, social security administration gave up, see, previous to 1972, the cards came with a sign that said not for identification. The thing was everybody started using social security ID number as a way to identify people.

And the thought process went well, like only the person's gonna have the card. So only they know the number, right? It became a secret that every single business had, we were installing a massive damage. Amplifier. Anytime there was a breach, we had this amplification effect, which made the next breach even easier because I knew a username which ended up being a secret. The social security number identities cannot be identifiers, cannot be secrets. Usernames cannot be secrets. If you have an identifier, if you have a username and it's a secret, you don't have an identifier.

You have what I call a zero factor authenticator, essentially, with possession of it, you get access to resource. Let me show you one. This was my employee ID number. When I was at IBM theory goes that has a mainframe. It has six characters. IBM gets really big and they switch to Hexa decimal. That's the best I can do. But here's the thing. If you knew this back in the day, it would unlock just a TNC bit of resource in human resources. It was a zero factor authenticator. Okay. Second usernames have to be classified as public.

So, all right, we've already said that usernames can't be secrets. What I'm saying is in your data classification scheme, you have to classify them as public. Those of you who are European right now should be getting nervous. I'll explain it in a minute. So why the hell is this simple? If we classify it as public, it can't be a secret.

Okay, great, thanks. But that's the second reason. If we do this, it's going to prevent you from putting attributes into the username that are in the account. It will prevent you from doing things like using a policy number or a membership number as the username, because that attribute actually has some real value and isn't something you would classify as public and it needs to stay out of the username. Now I am saying classify usernames as public. I am not saying public size, do not go rent a billboard and put your usernames on there with who those people are. That's an enumeration attack.

Don't do that. So what happens at the intersection of secret and public?

Well, I clearly know where I am and I have been involved with the GDPR program at Salesforce since it's very inception. And I know what article four section one says talks about personal data has this great little sentence in there, such as a name, an identifier, an ID number or online identifier. And with that little phrase, GDPR blows up username handling in like ways that, well, those of us who are service providers have to go deal with. The reality is this. And this is a personal opinion.

There are such different types of identifiers that get processed differently, but the regulation doesn't really allow for a nuanced conversation or that differentiation. And I think that's a miss on the part of the regulation. We need nuance here. Third aspect. These names have to be memorable, seems straightforward. One of the most memorable books in American literature, Moby Dick. And it has a very memorable first sentence call me Ishmail and you're probably thinking, I know what he is doing. The important part's Ishmael cuz that's the username. No.

The important part of this sentence is call me the ability for the narrator to name himself is the power to control. And so in this act, the narrator takes control from the author and the reader. The ability to name oneself is part of self-determination. This is important. People have to be able to give themselves names, especially in an online setting. Now this is mandatory in B2C and B2B to C, but I actually also think it's applicable in B2B and B2 E as well names have power. Now here's the thing is that file fun. Alana is not self-determination.

I mean, we're really used to it, but it doesn't support self-determination is there's some confused faces. Do we not? Oh you do you know this? Yeah. Ready. First letter, first name, last name file. Falana it is the username like scheme that we use in so many places and it doesn't support self-determination it's not a great model. Here's the thing. If you don't provide memorable usernames, what's gonna happen. Couple things.

First off, you're gonna need to provide more onscreen, help hints, essentially more customer support. And you should expect increased account recovery calls because the poor individual can't remember how to log in, has nothing to do with password and even know the username. The other thing that's gonna happen is you will get reregistration. You will get duplicate accounts because people show up at a site. They register, they come back a couple months later, don't remember their username. I'll just create a new account. This is the bane of like every marketer everywhere.

The other thing you'll see is you're going to see username reuse. Now that's not necessarily a bad thing.

However, if username reuse is coupled with password reuse, then what we're doing is paving a path for account takeover or making it easier. And it's just something you have to live with. So you've gotta provide choices, right? And so it's not just say email is username, right? This is a good example. You ask for email as username and on the very next screen, you want to know that that individual's communication preferences are. And they're like, yeah, don't talk to me over email. Well then why'd I get your email to be, ah, you need more choice, right?

So it's not just about saying, or you use email as a username scheme. I wanna use phone. I wanna use a nickname. I don't wanna use a choice of any of these multiple of these usernames have to be unique.

No, one's gonna argue this, but there's a little nuance. We have to consider this scope of uniqueness. So are you building something that's unique at the tenant level? For those of us who have to deal with multi-tenancy or at the service level, is it globally unique amongst all of your services? Is it even universally unique? The question is, do you actually know what scope you're designing for? Do you have it clear in your head what you're designing for now? Most of us, most of us in this room probably just need service scope uniqueness, probably.

But if you ever have to split a system or merge systems or split off a whole company or buy a company, uniqueness becomes a very interesting challenge, consider scope early. Now the other thing about uniqueness is the type of identifier. And I've already alluded to this a little bit. There are really two kinds, external and internal. So an external identifier is an email address, a phone number, a nickname. It's how I, as an individual, identify myself to the system. Then the internal identifier is essentially the thing that the system uses to process that user account.

Here's the interesting thing. They live in different life cycles. The user has control of the username more or less. That's a different cadence and a different pattern than the internal identifier, which lives in an enterprise controlled life cycle. Now here's a fun thing. You can allow multiple user names to be mapped to a single user account. And if you do that, then those user names don't even have to be unique. Not all of them. You just have to make sure the internal one is, this opens up some really interesting and strange use cases.

Last thing on this, if for some reason you are tempted to make your external identifiers, the same as your internal identifiers do not do this. This is what the social security administration got wrong. Every business said, I've got a unique identifier. Perfect. It'll be the internal identifier. And then like 50 years later, you're like, ah, crap, how the hell do I change this? Don't do this please. So let's look at the intersection of memorable and unique. There's a couple things to think about.

One of those is the email address, your phone number, that's memorable, but like I did identify or a U I D isn't and that's okay because they're different types. They serve different purposes. They're processed differently. So just in case you think memorability is something that has to be blanket approved or blanket applied. So going back to my employee ID number, it was memorable clearly, cuz I haven't worked at IBM in a long time and I still remember it. I assume it was unique, but it totally fails the public test. Like this is not something that should be in a username.

I wanna tell you a little story. So in America there is a very talented actress named Alana Glazer and there's no relationship she's really popular.

Again, no relationship. We both have usernames. I think you see where this is going and she's really accomplished. So she's been on say late night talk shows. She's been in people magazine or MTV, except that's my Twitter handle up there. And it's a really awkward moment to find out that you were in people magazine and you didn't buy your mom. A copy of it. Weirds happens. It's memorable. The user games are memorable. They're unique, but they're conflated strange occurrence, true story. And this is kind of a symptom of file. FA Alana. We're like totally expecting this to work.

Lastly, usernames have gotta be recoverable. Now recoverable is more than just a reminder. Recovery is more than just a reminder. Keep this in mind. You see recovery means reconnecting the individual, whether digital persona with their stuff more often than not to do that, you're actually gonna have to repro the person to make sure they are who they claim they are because we're trying to reconnect them to a digital persona. Now here's the thing. This doesn't necessarily mean you're going to reuse the same identifier.

You may go through that whole process and the person may have a new username. Well, why is that again? Recovery is more than a reminder because if you remind me like, Hey Ian, your login was, I don't know, your old email address from work. That's useless information to me. I can't get to that email address. Why are you like you're not helping me at all. You're just annoying me. I'm gonna recreate a new account. So you have to start thinking about backup user names or allowing multiple user names, multiple identifiers per user account.

It's a little tricky to do, but it's actually something that increasing is more worthwhile. The other thing you have to consult is that reuse is real among usernames. There are email providers that will reuse the same username, certainly phone numbers have this behavior. And it's kind of a funny situation because the identifier has stayed unique, but the person associated with it has changed. They're not unique. Now it's a very odd situation. And this is why we have to think about recovery as a re proofing process at which we may get a new identifier for that individual. Okay.

So with those five aspects, you can take them as a guide, but you can also start to evaluate other things as you think about a username scheme. So yeah, of course the username gotta be memorable, but I also believe it has to support self-determination. I believe that it needs to be privacy respecting, essentially classified public, that it needs to be recovery deflecting. It needs to be something that contextually people know what it is and it ought to be account takeover resistant. And if we take these as axes, we can actually plot on a very unofficial scale.

What different schemes look like? So something like email is really good from a memorability perspective and pretty good for self-determination. That's really bad from account takeover because I harvest that email and I can use it. I'll just spray it everywhere and do credential stuffing. What about phone? Phone's not bad, but it suffers some of the same shortcomings that email does. What about a nickname?

Well, nickname's actually really interesting. It's really good. Especially from privacy respecting perspective, you can check to make sure the person's not putting their account name or their account number into their nickname. For example, that's all good. But if I really want to go overboard in terms of privacy protecting, I could just do a random set of strings. The problem is like that's great from an ATO perspective, totally sucks from recovery deflection, cuz you're gonna not know what your username is. I have a couple of accounts that are random character strings. It's a mess.

The reality is no one's scheme is perfect. You're going to have a balancing act here. So let's sum up. There are five aspects of usernames. Usernames have to be secret. They have to be classified as public. They need to be memorable. They need to be unique. They need to be recoverable. We're trying to shoot for the center of the five way VIN there. It's not easy, but it actually can be done.

And we can take these aspects as a guide, as we evaluate username schemes, knowing it's a balance, knowing there are trade-offs knowing that maybe we support multiple of them, but here's the thing I strongly believe we need to put the power to name into the hands of individuals. This is how we support self-determination. This is how we support empowerment. And with that call me, I Glazer. Thank you so much, everybody. So.