Should the same email address be allowed to be used among multiple registrations?

I'm deciding whether to accept a new registration using an email that already exists in the database but using a different username or to refuse it.

There are times when I forget username and/or password for a website. I then try to re-register using a different username/same开发者_Python百科 email I used but often get refused by some web apps.

What is your opinion on this?

Edit: Forget this other important question...

When trying to see if username already exists in the database during registration, should I do case sensitive comparison? Should different case use create different usernames?

What about passwords? Should they be case sensitive?

Thanks!

I think requiring unique email addresses is a good idea. It allows you to reset forgotten passwords and email them to the forgetful user.

I suggest that if you want to refuse duplicate email addresses then have your users use their email address as their username.

The only reason I can think of NOT to do this is if your system might require a single person to have more than one login - for different access levels, permissions, regions, etc. It's better to design the system so that each real world person only needs a single login though.

Regarding case sensitivity: you avoid this problem by using email addresses as usernames - you can simply lowercase everything behind the scenes. Passwords should be case sensitive. Upper/lower case dramatically increases the number of characters available, which makes brute forcing and guessing passwords much harder.

I wouldn't do it. How would you contact your user if you have multiple emails? Besides aren't you confirming email upon register? Is better to add a 'recover password' routine than allow same emails accounts. I use them as an unique identifier too.

Allow only one username per email address. I think there might be cases where it makes sense to allow multiple accounts per email address depending on your service. E.g. I'd like to have multiple twitter accounts for the same email address (e.g. one for family twittering and one for technical twitters).

• Username or email = not case sensitive
• Password = case sensitive

I think this is universally accepted and expected.

Most systems don't allow same email to be shared between multiple identities. In my opinion, there are no strong arguments for such limitation, except the one @Scott Saunders pointed at - resetting password based on email only would reset password for all accounts that share the same password. However, I personally think that if the users are so engaged with your app so that they want to register twice - let them.

However, I would suggest couple of things to keep in mind with regards to emails and user identity:

• don't use the email as a user identity/unique identifier. People tend to forget their email password or to switch their emails.
• allow users to enter more than one email. The more ways to reach to user you have, the better.
• enforce the uniqueness of the email only on confirmed emails. (that is, if you ever choose to enforce email uniqueness)
• treat emails as case-insensitive. Unfortunately, there is no way to properly lowercase email addresses, that are not in your app primary culture.
• consider carefully how you treat the dot ('.') and plus ('+') characters in an email. Some systems ignore the dot and treat john.doe@thedoes.com to be the same as johndoe@thedoes.com. And some systems threat anything after the plus as an alias (or a sub-email), thus john.doe+mybank@thedoes.com is the same as john.doe+mybank@thedoes.com. (in particular, I know of at least one system that combines the two behaviors, so that john.doe+mybank@thedoes.com is equivalent to johndoe@thedoes.com)
• do not treat emails at subdomains the same as emails at the main domain. Unfortunately, there are cases, where the emails from particular subdomain are the same as the emails from the top domain, but there's no way for you to know when this holds true.
• and the most important one - allow users to register without providing email. This one is a bit controversial, but my take on it is that the less friction the user registration, the more chances they will get more engaged with your app. (I can't tell you how many web-sites have lost me in the middle of the registration, when it turned out I have to fill out five pages of random information...)