Are there best practices and security issues about using emails as user id in a Web application?

Question

I am designing a Web application that will use users email as their user ID. Are there security issues and best practices I should be aware of that could make me reconsider this idea?

Answer 1

The only real consideration is the same as any other username - do not store the username itself, or the e-mail address, in a cookie or in a hidden field on the page (or whatever), unless it is to help "remember" what goes in the username field of the login box ONLY. Do not use it to store actual authentication information anywhere that is sent to the user in any way (cookie, hidden fields in the HTML, etc.)

Edit: unless you are storing extremely sensitive data, such as banking information, the below suggestions are completely unreasonable. There is no inherent reason you should place additional security, like personal questions, onto a login process simply because the username is an e-mail address. Usernames are not private data, so using a different piece of public information (e-mail instead of username) is no different, in normal circumstances. I would know because, well, I have worked in online banking for one of the largest banks in the world. And I've worked with major sites that have logins for less sensitive data.

Answer 2

It is my opinion that using their emails is a good idea. It is not some random ID that they will likely forget and it should negate duplicate submissions to a degree. At the same time, ensure your UserID field will support relatively long addresses (>100 characters perhaps). The security part can be handled differently.

Each login requires answering three of five security questions that were filled out when the account was initiated which is what I would suggest. The other would be to look for a MAC address or IPAddress and capture it in your application...not recommended. Also, you could deposit a validation cookie...not recommended.

Also, when the User needs to set a password - clearly state what the rules are at the time the account is being created. Standard rules:
x minimum characters
must contain a capital letter
must contain a number

Depending on what information the application is handling, you may wish to also not permit recognized words if your application is handling super-sensitive (banking) information or something similar.

Therefore, UserID=email
Password=user generated following specified rules
Challenge Questions=answer 3 of the library of 5 questions to validate before allowing access

Hope this helps...

Answer 3

My answer depends on what you mean by "user ID."

If you just mean their login name, then I don't know of too many issues, except that it leaves the user open to lots of spam from spybots, and I personally prefer not to log into sites using my email (although I will if I have to).

If you mean the primary key... no! Bad, bad, bad! Primary key should be an invisible number field that never gets shown to anybody (including the user). Otherwise, you're inviting headaches for yourself if/when the user changes their email address (which a lot of users do fairly frequently).

Actually, either way, you're going to have to create a way for the user to change their own email address, since (again), lots of users do this on a fairly regular basis.