Simply comparing the username selected by a new member to a list of existing usernames quickly show conflicts and denying the use of usernames already taken is very frustrating to the visitors of a web site.

I read the following statement on the Internet:

"In order to log in to the server, an authentication value derived from the password and username is passed to the server."

That probably means there could be an unlimited number of identical usernames using the same server if that value is used to identify the user.

Could anyone point to info, or explain how to do that because it obviously involves doing it on the visitor's machine.

Thank you for your help.

But as you wrote this authentication value is based on usernames. Users still need they "usernames". If you allow users to have the same username, then it will be security issue, as these users can choose (by accident) also the same password, how you then distinguish them?

You can use emails as usernames, or you can also use OpenID or similar solutions.

If this is login form on website, you can make it less frustrating, by checking usernames during they writing it in the field, using Ajax techology. That way they get immediately feedback.

1 members found this post helpful.

And most importantly, how will members be able to tell each other apart if different ones have the same name?

1 members found this post helpful.

Well, consider the real world. Many people out here have identical names. So, how do you distinguish among all the different people called ,e.g., "John Doe?" Obviously not by just the name. (Nor the SSN, which cannot - by law - be used as a unique id number, but that's a different issue.)

So, you could assign the new user a unique password (giving the user the option of rejecting a proposed p/w and looking at another one). That would prevent the duplicated p/w problem.

As to the "Which John Doe do you mean?" question, that assumes that the user knows that "John Doe" is available in the system. They could only know that by somehow getting that information by reading the site's contents. So, you could record the name of posters and post readers and, when a post reader wishes to contact some other reader, you could ask them which "John Doe" among those who created posts they've read they mean.

Alternatively, you could create a "personal community" for each user, and let them add other users to their "community" with, for example, a right-click on the other user's name in a post. When there's a collision in their "personal community," you could let the user add a "nickname" or "identifying characteristic" to the duplicated name, and present the user with a names and characterizations when they want to communicate with someone in their community.

There may be other possible solutions (e.g., face pictures?), but, as I noted above, we have been dealing with the problem of "John Doe" for centuries.

1 members found this post helpful.

I glanced at the paper I think you got the quote from. I gather that, at least for one of the features, the username is being used as a salt when the password is hashed. It's kind of weird, since normally you'd want the salt to be random, but in the end, usernames aren't intended to be secret (much like a salt) and I don't think there's anything technically wrong with using them as a salt in some cases (other than statistical deviations from pre-computing probabilities).

That said, I don't really understand the context in which this is all taking place, since I'm not familiar with this service.

As for this:I don't know how you reached that conclusion. Could you elaborate? There needs to be a uniqueness. Otherwise, you'd be susceptible to collisions since people will be able to pick identical username/password combination, which would generate an identical message digest (in the scheme above), which would consequently make identification (and therefore authentication) impossible. Therefore, considering there is no mention of any other unique identifier in the paper AFAICT, I would say that the usernames are indeed checked for uniqueness prior to being made usable.

1 members found this post helpful.

Thank you all for your explanations, I better understand the subject. If, under the scheme, the username still needs to be unique, then my assumptions were wrong and it offers no advantage.