Layer 8

Security is fundamentally about people, and everything we know about people is relevant to security. -- B. Schneier

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.

Posted by shrdlu on Thursday, May 08, 2008
(3) CommentsPermalink blogmarks Favicon del.icio.us Favicon Digg Favicon Fark Favicon Furl Favicon Google Bookmarks Favicon StumbleUpon Favicon Technorati Favicon TailRank Favicon

Comments

LonerVamp United States on 05/09  at  04:05 PM:

I would add to be aware of things in the username that might change. Position, location, date of hire (if they return?), last names, and so on.

I really, realy hate looking at logs or a system to see who is logged on only to see that it is user23562. Who the crap is that? There are places for such obfuscation, but I don’t think the staff pain is worth it. Hell, I don’t consider usernames to be sensitive information anyway.

On a similar note, will you want two schemas for different things? Do you want your email addresses masked the same or similarly to your system usernames? Enough people have their email address posted on the website to start guessing schemes. *unconscious tic in the direction of the tinfoil drawer*

When I started at Iowa State U in 1996, their systems were still relatively new, so at freshman orientation we were allowed to choose our system usernames. I got lucky and went through my time at the school as . I don’t think students get to choose anymore, but that was a really cool little piece we could personalize. I believe student workers were the ones to type it in, thus able to deny offensive ones.

I think a good BSOFH would make the usernames:
information is based on the requestor ()
hiredate (ddmmyy)
full ssn (ddmmyysssssssss)
a PIN they reuse (ddmmyyssssssssspppp)
5 random digits for padding, making sure to absoultely use any digits not already used (ddmmyyssssssssspppprrrrr)

Zydia Toy Great Britain (UK) on 05/13  at  09:07 AM:

And I thought only allowing alphanumirec chars (including _) and setting a length range was good practice!

Rob Newby Great Britain (UK) on 05/15  at  07:50 AM:

A company I worked for in 1998 had 2 John Brown’s in their user directory. John Brown was the IT Director, but had joined later than John Brown, who for all I know cleaned the toilets.

Thus, John Brown (Dir IT) was given “john.browqn”. This is a simple and effective disambiguity system for your user directory.

If only it had worked for people wanting to email him.

“What are you telling me for, I clean the toilets"…

Page 1 of 1 pages

Add a comment

Name:

Email:

Location:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?

Submit the word you see below: