Usernames: allow, require, or forbid users to user their email address as a username?
19 comments
Interesting -- I just checked out what Amazon does, as a reference. Amazon uses email as the login. If you change your email address (and can't get into the old one), AND you forgot your password, you are SOL: you have to open a new account.
I guess that's the "lots of pain" part, but I don't blame them.
I guess that's the "lots of pain" part, but I don't blame them.
On my site we require every user to pick a username, but users can log in with their username OR email address. This allows us to keep email addresses private, but also makes it easy for users who just can't or dont want to remember their username.
It's a simple regexp in your login controller to figure out if what they typed in should be checked against the email address or username field in your users table.
It's a simple regexp in your login controller to figure out if what they typed in should be checked against the email address or username field in your users table.
On most sites it's difficult for a bad guy to discover the email addresses of your users (they're private). It's trivial to discover the usernames (they're public). With thousands (or millions) of users it's not hard for a bad guy to find accounts with weak passwords. Probably wise to make sure you have decent password constraints and a way of preventing brute-force logins.
Allow, but..
Username should an arbitrary object-id, service generated.
This is OOD, isn't it ?
Additionaly user should be given the possibility (not obligation) to provide: - one or more email addresses (primary & secondaries) - a unique user chosen ID - 30 or so chars. - a user chosen Display Name, not unique - a password (optional too)
User should be able to login using their optional password and either : - an email address or - their user chosen unique ID or - their system generated unique ID
If login fails because user is not known, user should be directed to a pre-filled "register" page ! Never ask user to re-enter data just typed a page before.
Only the object-id and Display Name should be public by default. Display Name should default to unique user, name part of email address or Anonymous.
There should be a log of failed & successful logins, with optional email delivery/alerts.
Username should an arbitrary object-id, service generated.
This is OOD, isn't it ?
Additionaly user should be given the possibility (not obligation) to provide: - one or more email addresses (primary & secondaries) - a unique user chosen ID - 30 or so chars. - a user chosen Display Name, not unique - a password (optional too)
User should be able to login using their optional password and either : - an email address or - their user chosen unique ID or - their system generated unique ID
If login fails because user is not known, user should be directed to a pre-filled "register" page ! Never ask user to re-enter data just typed a page before.
Only the object-id and Display Name should be public by default. Display Name should default to unique user, name part of email address or Anonymous.
There should be a log of failed & successful logins, with optional email delivery/alerts.
Additionaly : User should be able to use their email address for password, if they wants it that way. In that case I guess that they should be warned when they allow their email address to be seen by others...
How do you cope with many users having the Display Name "pg"? How can a reader easily tell which pg it is?
Allow it, maybe even default to it, but don't require or forbid.
Another approach is to require it, but allow an optional display name.
Another approach is to require it, but allow an optional display name.
i really like it when it is the email address. then it is never taken, and i don't have to remember which one of my usual username variations i have to put in.
when it is the the mail address, this makes a strong case for also validating them, otherwise people can accidentally lock up other peoples address by misspelling their own mail address. i think a user will never switch mail accounts to get access to a site. and as the customer service person you will be reluctant to delete a stale account from a misspelling, only because somebody claims his address is blocked. so you better know in advance this cannot happen.
when it is the the mail address, this makes a strong case for also validating them, otherwise people can accidentally lock up other peoples address by misspelling their own mail address. i think a user will never switch mail accounts to get access to a site. and as the customer service person you will be reluctant to delete a stale account from a misspelling, only because somebody claims his address is blocked. so you better know in advance this cannot happen.
If you ever get into a situation where your site has over 50k users or so, you will see banned users switch email addresses to circumvent your security measures several times a day. I know I do, and my site only has 300k users.
The solution is to store banned IP's in your database, excluding massively-shared IP's like AOL, and check against this list during registration. I also keep a list of free proxies and prohibit people using those IP's from signing up.
The solution is to store banned IP's in your database, excluding massively-shared IP's like AOL, and check against this list during registration. I also keep a list of free proxies and prohibit people using those IP's from signing up.
i was not talking about security, but about usability.
the key, is that it limits the amount of information you need from the user to create a relationship with them.
getting an email address and password is the bare min you need to communicate with them.
in some cases, i have only requested an email address and then sent the password in the mail. this solves a number of problems and if the user just uses the password, then you can assure they have a somewhat secure one.
getting an email address and password is the bare min you need to communicate with them.
in some cases, i have only requested an email address and then sent the password in the mail. this solves a number of problems and if the user just uses the password, then you can assure they have a somewhat secure one.
Requiring it is more convenient for the users. I know that I'm always trying to be safer by using different passwords for different sites. However, if I stop using a site and come back a year later, I probably won't remember my password and it's also possible that I won't remember my user name. Not being able to retrieve this information would discourage me from using the service.
I'm sorry, I read the title very quickly and misread it. My opinion on the actual question is that I generally like it when the log in is the email address and there is a separate display name. This way the username is easy to remember, but the email address remains private.
It depends on your service. If users can see each other, then you probably want to keep email addresses hidden.
I have a related question, for the email system we're about to launch:
-should we enable OpenID before launch
- or should we integrate it later?
- or just forget about it? (unless bazillions of users request it)
Depends on a few variables...Time frame for launching, ease of integration, etc, etc.
Ignoring those... As a user of OpenID I would vote for enabling before going live (one less new account to create). I have typically noticed its the legacy sites (pre OpenID) that are integrating, whereas most new services looking to leverage the service have it ready for go-live.
Ignoring those... As a user of OpenID I would vote for enabling before going live (one less new account to create). I have typically noticed its the legacy sites (pre OpenID) that are integrating, whereas most new services looking to leverage the service have it ready for go-live.
I say require it. People always remember their email addresses... Because username conflicts abound, people use "fire-and-forget" usernames all the time.
I seem to be in the minority here but I dislike sites that an use email address as username. Yuck.
PRO: The user doesn't have to remember yet another username for yet another site. PRO: Email addresses are more or less unique. PRO: Entering the email address does not require any new thinking on the part of the user.
CON: A lot of pain when the user changes his/her email address. CON: If the user can share his username publicly on the site, he will get inundated with SPAM and other unwanted email. CON: "Email address:/Password:" prompts mislead users into entering the password for their own CON: It is easy to guess a person's account, and determine if they are a user or not, and even impersonate them if they use the same username/password for the site that they use for their email.
(b) The user should be forbidden from using an email address as a username.
PRO: Email address is kept private. PRO: The user can change email accounts without disturbing his identity on the site. PRO: Users who want to use their email address for convenience may be missing some of the subtle security problems caused by doing so--you are kind of protecting them against their own ignorance.
CON: Nice, easy-to-remember names get taken fast; the user is likely to forget what username he used. CON: Users' anonymity often causes as many problems are it solves; this is why Amazon.com has the "Real Name" feature.