Should usernames be kept secret?

Question

Help me settle an discussion among colleagues and guide future design:

Even in a high impact scenario: e.g. protecting payment application or government gateway but in an Internet accessible application

Is it worthwhile implementing any of the following (or other) measures to protect a username:

• Requiring a complex system generated username like the UK government gateway or HSBC on-line banking? Is the trade-off in terms of users forgetting this, needing to write it down, the additional call center traffic, users having to self service username reminder worthwhile vs the risk of using a public username such as email address or mobile number?

• Providing a generic message: "your username or password was incorrect" instead of more user friendly "your username was not recognized" and "your password was incorrect"

• Using the following type of login sequence where a site-key or user selected personal pass-phrase to assist in identifying phishing sites is used:

  • Enter username and simple secret value (e.g. postcode)
  • If invalid they are provided an error: username or value is incorrect
  • If these are valid the users personal site-key image is shown and the password is requested
  • If invalid password, error message incorrect password
  • If valid access granted

As opposed to the more friendly way on say Quora.com where you get shown your picture on correct username entry. Is this acceptable only on low risk Q&A site?

My colleagues argue for keeping usernames secret and the above type measures:

1. Mass username enumeration allows you to try dictionary and bruteforce attempts against a site
2. it enables you to dos a site by locking all the accounts where account lockout is enabled
3. Users like to use the same username and password across sites and many sites use e-mail address and mobile number for their sites. If users share credentials between sites, then credentials could be stolen or phished from the other sites and then used to access your site
4. Publicly known facts, such as mobile and e-mail, do not count towards authentication strength. If username is a known fact, to maintain the same level of security the password must be significantly stronger to make up for the statistical difference e.g. if username and password both have min of 6 characters, then assuming 52 possible characters we have 52^12 combinations. However, if username is a known fact then that becomes just 52^6 combinations; you have to increase the password to 12 characters minimum to get the same level of protection – failure to do this would increase account takeover risk.

I counter for each:

1. Your real control against this is password length, complexity and account lockout policy
2. You can mitigate this by having auto unlock after period of time (e.g. 5 - 30 mins), have a mass unlock function, have exponential back-off or IP banning for a period of time after a number of bad attempts, selective anti-automation controls (e.g. Captcha, Roboo script) displayed after a number of failed attempts
3. User education, a second authentication factor, adaptive authentication (e.g. step-up or graduated authentication based on device ID, location etc) would be better defenses against this
4. I see username as identity and password as authentication. If you want a stronger authentication make the password longer or require 2 passwords - leave identification alone

Happy to learn and change my position. Thanks in advance.

Answer 1

Conventional Wisdom re: Brute-Force Attack or Enumeration

There are a few ways to look at this. One should start with http://thedailywtf.com/Articles/The-Phantom-Password.aspx before trying to really think about it, though.

There are varying degrees in which passwords are disclosed. My username at Slashdot is known by everybody who reads a post of mine. My username at work can be viewed by everybody in the office, and equally discerned by anybody who knows my email address. Nobody should know my bank account number (which is the username for my online banking).

In each of those situations, the benefit of specifically saying that the username is invalid or that the password is invalid is limited. Now, in that scenario: If you're on Slashdot, you know the account is there forever so you can figure it out regardless. If you're attacking my work, that can give away whether I'm still employed. Against my bank or credit card accounts, that's the only way to enumerate accounts. It provide a clear goal.

I'm of the opinion that since acknowledging one or the other has limited value for public systems and can leak information about private ones that password authentication should always be of the form "do the username and password match?" That is a T/F question with no steps in between.

New Age Wisdom re: Phishing

A user gets to a website, which may be the wrong website. They enter their login credentials without paying attention to the URL (or perhaps they really get spoofed), and their account is compromised. Banks have addressed this by making authentication a multi-step process. To this idea, the original questioner mentions displaying a series of photos if the username is correct. I counter: ALWAYS make the authentication process go through all the steps. jonjacob(jinkleheimerschmidt) may not be a valid login, but you should still display a series of photos and ask for a password. That allows you to stifle the risk of leaking information and still attempt to prevent phishing from compromising a user account.

Risk v. Reward

The conventional wisdom about usernames and passwords above is simple and agreeable to most, I believe. Phishing is a new variable, and dealing with that is going to change the situation for some systems. There are answers to your question which may not be discussed here, or even thought of yet. I still believe, however, that you should be able to prevent somebody from enumerating accounts with any situation.

Answer 2

If users have complex passwords or you use additional security like tokens to force the complexity of an attack to a "reasonable" level, the cryptographic aspect should be covered. However, there is the privacy aspect to consider: Some people just don't like anybody to figure out anything about them. Remember that you can't cater to every minority, and design according to the business and community requirements.

Obligatory quote: "Security is always a tradeoff."

Answer 3

The suggestion of keeping usernames secret seems absurd.

It is inevitable that you need some way of identifying a user in a way which does not compromise the security of an account. How would email work if your email address was the authentication token? If I'm having problems using some software how do I tell the helpdesk which account this relates to?

it enables you to dos a site by locking all the accounts where account lockout is enabled

It would also allow you to access a system where there was no separate password - revealing the username is not the problem, rather its the implementation of the lockout rules.

Users like to use the same username and password

OK, I'll concede this one. But it doesn't justify the postulate. Users are stupid. Get over it. If you want them to think your site is secure, there's lot of research to show that putting a big picture of a padlock works better than using SSL. If you're trying to phish secondary authentication tokens which are implemented via partials (as in 'please select the 3 and 8th digits from your pin) just provide a text input box and ask them to supply the whole thing.

Publicly known facts, such as mobile and e-mail, do not count towards authentication strength

? but mobile numbers and email addresses are usernames!!!!!!!!

Passwords are not a complete solution for high security environments. But trying to use a username as an authenticator does not help improve security and it compromises other stuff.

Answer 4

I used to do a mix of security.

For example, for the user mail account :

• ID : [email protected]
• PASSWD : 1z"1dgG"@"é~#.

For the user account on the intranet, it's like that :

• ID : 1501823098 (usually I use there own ID from their ID card, or I generate that ID if I can't do otherwise.)
• PASSWD : #\ed"1:!)3qs

The problem of letting people know the user account on intranet (or internet) is that any hacker will try to brute force the login. Even if the password is complex, the dictionary attack and the brute force will have an impact on your connection, bandwidth decreasing and so on.

Also having only 1 policy about username account and password for the whole intranet/internet application is like running with only bread helmet against a tornado. You can survive but it's like suicide!

Even if the user will complain because they have to learn 3 differents account ID and 3 different passwords, your job will be much easier, because it'll be simple to isolate 1 account that being hacked, and the user will after some weeks, adapt to that policy, and you will have a really well protected stronghold.

Well at least that's what I did at my work. Even now, sometime users tend to forget their ID or password, or to write them down, but that's their problem, I did my job at ensuring a good security policy. (You can give them their ID or reset their password if they lost them.)

Hope this will help you.

EDIT :

Your real control against this is password length, complexity and account lockout policy

Having a good password length with complexity have a big flaw, dictionary. I use(for myself) password with high complexity and 26 characters length. Even if the dictionary doesn't find it immediately, it'll be consuming a lot of network process. And having account lockout policy is a good idea but when the account is locked out, the brute force script will try another account, and loop like that. Even if at least the account is safe, you network will lose a lot a bandwidth, and in the worst scenario case, all your account will be cracked, and you might even have a global network blackout.

You can mitigate this by having auto unlock after period of time (e.g. 5 - 30 mins), have a mass unlock function, have exponential back-off or IP banning for a period of time after a number of bad attempts, selective anti-automation controls (e.g. Captcha, Roboo script) displayed after a number of failed attempts

There, the flaw is the user. Well the user is always the flaw in IT, but try to picture a user, that after 3 weeks of holiday (Happen at my work with my N+2... true story) forgot his password, he'll try, block his account, wait, try again, blocked again, after 2 try he'll rush to you like a mongol rider invading Europe! You will have to disable this rule for him, but the rumour will spread that you made an exception, and other users will want you to do the same for them. Worst case, the user will not come at you, but will use the account of one of his collegue (that write down ID and password and keep them preciously under his desk blotter).

User education, a second authentication factor, adaptive authentication (e.g. step-up or graduated authentication based on device ID, location etc) would be better defenses against this

Well, I totaly agree with you on this point. I regularly do user training about security policy, just to be sure that they don't forget what is at stake, and train new commer. But that should be normally in every company.

I see username and identity and password as authentication. If you want a stronger authentication make the password longer or require 2 passwords. Leave identification alone

The identification is purely user/admin friendly. If you want to reinforce the security, make the password longer or requiring 2 passwords will only hinder the hacker. The real way(at least for me) to reinforce your policy, is to upgrade you encryption (hash md5, RSA, etc...). My N+2 used to think it's useless but after a critical leak on our security servers, he does not think like that anymore (the leak was his fault, refer to the second answer to understand...). I think with security you can never be to careful.

After it's only point of view. Some might say that your colleagues are right, other might say you are right, for me I think both party are right, you and your collegue need to find a tradeoff to work with.

Hope this answered your questions.

Answer 5

The simple answer is giving away the user name makes your application less secure.

Any argument about increasing the security of other authentication factors is a red herring.

Whatever you do to further enhance security of the other factors could also be done while still keeping the user name hidden. If this application is truly high impact, you will be implementing all the countermeasures you can think of whether or not the username security is conceded at the door.

Yes - overall security is a balance and only by measuring your actual support costs can you see if giving away the user name is worth the perceived or calculated risk to your reputation and budget.

The real question is why would you incur all the engineering costs of maintaining a username field to then store it in a cookie or otherwise give away that authentication factor.