Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Within the design of my web application, I am trying to now choose the final steps of the members profiles for security. *I need to choose if I should use a system which you login with a username or email, and which is more secure?

With the current members table design, I have this setup:

  • The member ID is randomized out of 8 digits.
  • They have a nickname to display when they are welcomed. E.g. Welcome, $nickname.
  • Passwords are encrypted using bCrypt.

On top of the security which I have added into the design of the web application, which is more secure? A username and password or email and password?

Also, I do know the new standards are to the email and password, as I am seeing more of.

share|improve this question
up vote 7 down vote accepted

Give them a choice. For example, my e-mail address is fairly long whilst I usually pick short usernames; you can develop your login form to accept both.

Usernames aren't for securing accounts, passwords are. It isn't for no reason that the username is visible when entered in the browser, whilst the password is hidden. Also, users often re-use usernames, which, in contrast with password re-use, should not be a problem. And, of course, e-mail addresses were and are never meant not to be shared with anyone.

But the main problem: you don't store usernames or e-mail addresses hashed / encrypted, because you want to use them for other purposes than logging in. If someone steals the database with your hashed passwords, they will also have the usernames and e-mail-addresses. Gone is the “security benefit”!

So, forcing users to log in using only the e-mail address (and the password) or only the username (and the password) makes no sense.

Your defense should be enforcing strong passwords, and making sure you encrypt them with a strong password hashing function. Don't forget to set the cost high enough.

Additionally, to prevent an attacker that did not steal your database from renting a bot net and brute-forcing weak user passwords, restrict the number of login attempts per hour per IP address. Also, if you encounter a lot of login attempts for an acccount, block login attempts from any IP address from which no successful login for the account has been done in the past.

share|improve this answer
In addition to blocking an IP address you can inform the user by sending an email, when there is unusual login activity, like logging in from another country, or logging in at different locations at the same time, or logging in in Germany and five minutes later in Singapore. Facebook and Gmail do this. – SPRBRN May 12 '14 at 13:18
@user2428118: good points, especially the advice to use random salts in addition to hashing the passwords from your linked source. – Rüdiger Voigt May 12 '14 at 13:54

Having a username provides more obscurity than email does which provides security as a bruteforcer would requires the username before being able to perform an attack.

An email is not as obscure as a username as email. Users might use their email in every other account registration, subscription to newsletter or even posted it somewhere to have someone contact you. If a hacker does a bit of research or knows you and somehow got hold of your email address through social engineering you, they will have higher chances of doing a bruteforce attack or guessing password.

A username implements more security in this way as now the hacker needs to know both your username and password to do the attack. It's easier to get one's email address with legit reason than getting one's username. If you have features like 'adding username to friend list', you could instead implementing add by member ID and it is not used for login.

An email address offers convenience to user as they will need to memorise one lesser thing as most of us who owns and uses email often do remember their email address. Security and convenient is always a trade off of each other.

Also note that to keep the username obscure, make sure you're not returning message like "Username does not exist" upon fail login. Return something like "fail login: Please check your username/password"

Most banks I know they don't uses email address for authentication, they would prefer username as it provides more obscurity. You could consider username as another form of 'password' in this case, just that it's a less secured password as it's not encrypted and can be view in plaintext by others by peeking over the screen.

share|improve this answer

There is little to be gained by having a secret username or something of the like. As long as you enforce a suitable password policy, brute force attacks will be ineffectual, regardless of whether the username is public or not. If an attacker intercepts the password in someway, through a keylogger or packet sniffing, he can also intercept the secret username.

This problem is better thought of in terms of usability. Do you want your users to remember an email address a nickname, a secret login name and a password? Keep it simple.

share|improve this answer

If you have use proper HTTPS and other security mechanisms, in security wise there will not be much different. But if user names are too complex, users may try to write them on sticky notes and put on desktop (probably with passwords). So go with less complex one.

If you can use two factor authentication, that would greatly enhance the security.

share|improve this answer
HTTPS has nothing to do with the complexity of credentials. I think the focus of the question relates to username/password guessing. It is entirely possible to guess credentials with the use of HTTPS (and other security mechanisms). – Jason Higgins May 12 '14 at 13:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.