Layer 8

What’s in a name?

[Ed. note:  Happy blogoversary to me!  Time flies when you’re posting ... and especially when you’re not.]

Someday you, too, may be privileged to be able to design a username schema for your system, and I hope you’ll have your safety equipment to hand.  There are few activities more contentious than naming something.

Let’s take a look at a few of the aspects you should consider when choosing the format of a username.

- Frequency of use.  How often is your typical user going to be logging in?  How long are you going to keep that account around?  Persistence + infrequent use = forgotten username = help desk call (unless you are satisfied with letting them click a link to get it mailed to them).

- Disambiguation.  How are you going to tell your Robert Smiths apart if you let the real name be part of the username?  You can add a randomly generated disambiguator, but then you risk user memory lapses again.  You can add a disambiguator that the user will remember, but that usually turns out to be biographical data.  Please don’t tell me it’ll be the last 4 of the SSN.

- Basis for usage.  Why are you letting a user on your system to begin with?  Is it inherent in their job?  Are you making access decisions based on their position, location, relationship, or other?  How often is that likely to change?

- Other identity attributes available.  Are you going to try to be clever and overload the username with role or organizational information or some such?  Try not to do this as a poor man’s sorting function.  Data modelers will hate you and spit on your office chair.

- Need for respectability.  Are you going to let your users pick any aspect of their username?  Is it a problem if they pick “yourcompanysucks”?

- Will the username be immutable, technically or by policy?  Will a user have to apply for a new account if something about the old one changes?  How many help desk calls are you willing to support?

- Do you really think that obscuring the schema for the username will make attackers less likely to break in to your system?  (Hint:  if you choose anything other than a randomly generated string of characters for the username, it’ll end up being generated by an algorithm that is guessable.  The security shouldn’t be in the username; it should be in the strength of the password.  I hope my pentesters are reading this and will get off my frickin back.)

- Will you need to bulk generate or bulk upload new users?  If this is the case, you’ll need to be able to generate and assign usernames automatically.  Make sure your schema isn’t too complicated (let’s see, was that the first four of the last name?  What about the twenty people named Li?).

- Do you have username length restrictions anywhere?  Do you have the ability to create username aliases for an identity to interface with back office systems?

- Audit requirements.  Will you need to keep retired accounts around for reporting purposes?  I don’t recommend recycling usernames in any case.

- Will users need to have multiple accounts?  If you just said no, think again.  What about your developers and QA testers?  Show me a developer who has fewer than 200 accounts associated with her name and I’ll show you a developer who isn’t earning her keep.

- Don’t even THINK about making the username case sensitive.  Thank you.

I hope these little tips help you in your quest to create the perfect system.  Good night, and good luck.