I once worked at a small Governmental Instution that assigned both User Name and Password as a random string of characters. We (the System and Security Admins) did a sweep one evening of the Managers Row, ostensibly to inventory and upgrade the network cabling. We found the passwords on Post-It notes in 10 of the 17 offices (I did say it was Government, remember). In five of the ten, both the name and password were on the Post-It.

At an other site, the naming policy was 'first three letters of your first name and first three letters of your last name'. That policy got changed the day after Fatime Hagadopian was hired.

Yes, you will have people giving themselves a cutsy-poo name. So? They are the ones who will have to live with 'iMaNid1ot'. Make sure that you have a reasonable password policy in place, enforce it, and don't worry about the User-IDs.

I totally agree - let the user decide. There is no way you'd be able to ensure 100% unique names all the times, which means you'd have to search the name space anyway. Just make it easier on yourself, and implement a loop that breaks once the user has chose himself a unique name.

Hear, hear! ++

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

This is not desired for a few reasons

1. It requires a user to be present at the time of the accounts creation. In our case we need to invite a user to log in to create the account, and that in itself would require a username of sort - or some method for us to attach preentered data about that user who has not yet accepted the invitation.
2. It makes the assumption that we want to allow people to annoy themselves with the chore of guessing their user names
3. After a user initially logs in we will have a 'request name change option' - we might anyway
4. we want to make a statement with their login ID to earn trust, kind of like shouting 'l00k how l33t and caring we are, we custimzedzzz you a username', which is partly true, we are trying to stress the ease of migration
5. The market for this product is people who probably don't remember what their 'internet login thingy' they chose was to begin with. So they are not likely to have an emotional attachment to their u/n.

In the real deployment the username collisions will be much less likely because we will factor in domains. However we want to use the aol tactic and send out invitations to our service on both customized business cards, and demo cds and the backend must have the precompiled data we have aquired for that user - business locations and other good stuff.



Evan Carroll
www.EvanCarroll.com

some method for us to attach preentered data about that user who has not yet accepted the invitation.

That's easy enough; on these cards, give folks a short "Invite Code", and a standard URL for account creation -- this is one less chunk of initial info than the "username + password + URL" you have, as well as slightly more secure -- your commentary does not explain how you intend to defend against someone other than the user getting their hands on someone's card.

The "Invite Codes" act as one-time pads for creating that initial acct., and passing the data on -- this is similar to the "two forms of authentification" methods that recent legislation asks banks and other financial institutions to implement for Internet-based activities. Having the one-time pad also means that, if your database is hacked, at least the preexisting data is NOT tied to specific people and logins.

Your comments seem to underline security, yet because you have a guessable scheme, a kid with a half-day off from work could suss out the overall scheme, and start a dictionary attack to guess usernames and passwords. This is unwise; note that most high-security areas do not pre-generate userids or passwords, and this is one of the reasons.

Reference the other comments about forgetting usernames and passwords for that, as well, so be ready for most of your Internet-unsavvy users writing the information down on Post-It notes. As someone who did Tech support for years, I 2nd, 3rd, and 4th that the harder it is to remember these things, the more they are written down, and the harder it becomes to secure your environment.

Overall, I think your emphasis on "ease of use" does not factor in real world conditions. If your service is "good enough", people will be happy to deal with a simple login and registration process. Building real trust and interest, in my experience, comes not from making logins that any script kiddie can suss out, but from building a solid foundation where people feel comfortable with the program in question. AOL tactics worked for AOL, but the millions of floppys, CDs and DVDs with AOL software, and their declining share of the market, say something as well. I strongly suspect you'll spend better money on an infrastructure that's easy to use _and_ secure, over mass, or even semi-targeted, mailings.

----Asim, known to some as Woodrow.

Following the KISS principle....

1. Allow the user to enter thier own username.
2. Test to see if it exists and, if not, allow it
3. If it exists, return a new username that simply adds a numeric value. (incremented by 1 from the previous like-username)
4. If it's less than 6 chars, padd out with numerics.

This way the username should be pretty easy to remember.

I think there's something to be said for a solution like this, though I'd just require them to enter more than 6 characters for their username in the first place.

I would be wary of trying to generate usernames from the user's real names simply because it seems problematic to try to use non-unique data to generate something unique. Since their real names aren't required to be unique (and can't be required to be), they're not a good starting place for usernames (which must be unique).

Any form of auto-generated user name based upon the user's full name is going to have problems, because you can't anticipate what the edge cases are that cause the algorithm to blindly come up with something offensive or otherwise unusable. For instance, "Root" is a perfectly good last name, so you need to be able to tweak the algorithm in the last-name-only case.

True story: back when Usenet news was the "killer app" on the Internet, a young woman enrolled at a university which used the algorithm "first six letters of last name followed by first and middle initials" to assign usernames. Her name: Mary E. Cummings. (Or perhaps without the 'g'; it's been a while. I leave her actual username as an exercise for the reader, as some may find it offensive if I were to just spell it out.)

You could add:

4. fn
5. ln
6. ln.fi
7. ln.fn
8. fi.li
9. filn
10. fnli
11. fnln

and possibly use a simple "next count" rather than a partial md5.

The dot/non-dot distinction is somewhat subtle.

• Generate all possible character combinations
• http://tartarus.org/~martin/PorterStemmer/ remove/correct words
• then inner join with a dictionary word table in your database to return valid names.
• filter words that might be offensive

Just one more 'Unfortunate name' story -- there's a Dilbert cartoon about exactly this topic, which the last panel being the PHB complaining about how cranky the user Brenda Utthead was with the E-Mail address she'd been assigned. Let the user choose, perhaps from a list that you provide.

I used to work at a university, so we saw a few interesting usernames go by. We thought 'dicklove' was a rather poor choice for a name, until we saw it was chosen by 'Richard Lovelace'.

So, as I've dealt with this issue a half a dozen times ... I don't know the context, so let me say that the only folks who have names autogenerated were the medical school -- they'd give me a list of incoming students, and I'd verify they didn't already have accounts (eg, from undergrad), and go through various patterns 'till I found a name that wasn't in the system. As it was, I still had human eyes look over eveything before they were passed back to the user, so I could deal with issues such as:

Not all users have middle names.

David X. Cohen, from Futurama

Some users have more than one middle name.

my neighbor's middle name is 'Edward Thomas'

Some users have more than one first name

My mom's name is 'Mary Ann'. It's pretty common in France, the American south and China

Some users go by their middle name.

My high school principal was always listed as 'W. Cecil Short', but I didn't know that a former co-worker 'Bret Jones' was actually 'Johnny Bret Jones' for over a year.

Some users go by an 'american' name that isn't their given name.

Very common among Chinese in America. (eg, cooking chef Martin Yan's name is Zhen Wenda)

Some users have more than one last name.

In Spain a person might list their mother's last name, their father's last name, or both. (I work with a Suárez-Sola)
update:Similarly some women will hyphenate their last name, and go by either name or both as it suits them

'Last' name is not always the family name. (China, Cambodian, etc)

Some cultures use {surname} {given_name}.

Arabic names

lots of ways it doesn't fit with the Western first/middle/last, although the link gives suggestions

So -- do you reduce two-name components to 2 letter initials? How do you deal with people who use their middle name as their common name?

And luckily, I've never had to deal with people with only one name (Teller, Cher, Madonna, etc.)

There are also the rare people with single letter surnames (see The Story of O).

It's quite common for names from the British Isles to fail the /^[A-Z][a-z]+$/ regex.

emc

Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.

Albert Einstein

I've had success with the following approach (John Smithenstien) is the example username:

1. Create <fi><ln(6-chars)>. (jsmithe)
2. If this is taken, query the DB (once) for records matching jsmithe\d+, finding the largest value for \d+ (say, we find jsmithe1 through jsmithe7, so the value is 7)
3. Add one to the value from the previous step. (8)
4. Append value to username (jsmithe8).

This requires two queries and one update to the DB, at most. It implements a rule that is easily understood and guarantees no duplicates. Obviously, there are many variations on this simple rule, but it's best to keep the approach straight-forward.

One problem you may find with the wildly varying 'fallthrough' naming scheme is when users are trying to guess each other's username to send any kind of communication to them.

"Oh, I'm John Smith and I need to contact Bill Briggs.. they gave me J.Smith, so I guess he must be B.Briggs".

No, Mr.Briggs could have ended up with anything. Bill.Briggs, BriggsB, almost any combination of their name.

Whilst this does happen to some extent with normal 'JSmith, JSmith1, JSmith2' collision prevention it doesn't leave the user confused as to why their friend has this different name.

As you stated, your users are not going to be able to remember their name anyway, so it will be just as easily fo r them to remember a number. Ten digits is the same number of digits as a phone number, so it is not really that hard to remember. Now you don't have the problems of people with name like Sam Hit or the 300th Joe Smith on the system. Allen

I agree with others here that you shouldn't autogenerate usernames from names if you can help it. FYI, we have auto-generated usernames in the university computer lab of the form js429 where "js" is the initials of the person always coerced to [a-z]{2}, and "429" is a three-digit number somehow generated from the name and other user data.¹ There are 14200 such usernames. (The most common initials are sa(280), ka(244), ba(206), sg(191), kg(180), kz(149), bg(140).)

If you need the usernames for the open internet, just set up a simple rule (e.g. /^\w{2,12}$/) and let the user choose what he wants.

But if you need usernames for a company, I'd use a rather strict rule. What this role looks like depends on the system, e.g.

• length between 8 and 20 chars
• first 4 chars are the department
• next chars are the surname in international spelling [A-Za-z], with a maximum of 12 chars
• first char of the givenname in international spelling

If this is not unique, add more letters of the givenname, and if still not unique, add something like [a-z]

So my username for a company could look like 1234fabianim or 1234fabianima or 1234fabianimartinx (if there are a lot of persons with the name martin fabiani in the same department)

The advantage of this rule is that these usernames are rather easy to remember

Another possibility is to pick a dictionary word or words, but change one or two letters.