49

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.

10
  • so on Quora, you type in username, it responds with a pic so you can authenticate the site, and then you enter password?
    – Rory Alsop
    Jun 23, 2011 at 13:53
  • @rory-alsop yes. Go try it with [email protected] :) Not sure it is designed to let you authenticate the site or just be more friendly. Either way username enumeration plenty
    – Rakkhi
    Jun 23, 2011 at 14:16
  • I don't know Quora. It'a facial identification device? like fingerprint reader? Jun 23, 2011 at 15:16
  • 2
    When proving these methods wrong/unnecessary you seem to call for what is effectively better users.. making them create safer passwords (longer, more complex, not reused on other sites) and not to reuse their usernames all over the place. Unfortunetly, as is again and again proven in large-scale real world applications... someone will always get lazy, and getting people to do things your way is nearly impossible... EXCEPT for when you can force these 'smart choices' upon them. Thus, the measures you mention above.
    – DKGasser
    Jun 23, 2011 at 15:54
  • 2
    The password is secret deliberately so the username doesn't have to be. The username is only there to identify which password in the database to match against, nothing more. The reason the UK Government Gateway uses stupid generated usernames is more cause of the number of registered users that need unique identifiers than and secrecy.
    – ewanm89
    Jul 1, 2011 at 20:25

5 Answers 5

13

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.

10
  • 9
    Nobody should know your bank account number? Really? What about anybody that wires you money? What about your employer, that needs to deposit your salary? What about anybody - including the gas station attendant - that has handled your bank-issued credit card? Still, as long as it's only the username and not the password, it's not as bad as SSN on some gov't sites (which is considered THE authenticating secret... which everybody knows). I don't think that alone is a good username, but thats neither here nor there. Anyway, still +1 cuz it's a good answer and I'm just nitpicky :)
    – AviD
    Jun 23, 2011 at 18:19
  • 1
    My account number is between the bank teller and me. It's not on my debit card, and it definitely shouldn't be. My employer has a routing number, but not my bank account number.
    – Jeff Ferland
    Jun 23, 2011 at 18:55
  • 1
    @Jeff-Ferland sorry quite right, either way the mistake was not using both fields not that the username was revealed. The way to do the sitekey image correctly is: Enter username and simple secret value (e.g. postcode) If invalid they are provided username or value is incorrect If these are valid the users personal sitekey image is shown and the password is requested If invalid password, error message incorrect password If valid access granted . 3D secure does this where you enter your credit card, it authenticates that then shows you screen with your personal message to enter 3DS passwd
    – Rakkhi
    Jun 24, 2011 at 15:01
  • 4
    @AviD and @Jeff: whether bank account numbers are to be considered secret differs from country to county. E.g. in the Dutch banking system, bank account numbers are fully public information; there is no such thing as a routing number and the account number of the other party for every transaction is shown on every bank statement. This knowledge, however, only enables you to transfer money to that account. In North America (and most English-speaking countries?) bank account numbers are as secret as PINs (or moreso).
    – Erik P.
    Jun 28, 2011 at 18:29
  • 1
    @ErikP.: This knowledge, however, only enables you to transfer money to that account - almost. There is the possibility for a financially recognized institution to make direct debit claims on your account. yes, there should have been a previous authorization of yours (but the banks take the risk to make life easier for the customers) and yes, you will be reimbursed if you protest (also part of the risk banks take).
    – WoJ
    Dec 17, 2019 at 7:25
5

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."

3
  • 1
    That's true Security is always a tradeoff! Experience it everyday! Jun 23, 2011 at 14:15
  • 1
    ok first point you agree with me. Second is reasonable but surely mitigated by allowing the user to choose the username i.e. users who don't want to reveal their email etc will not choose that. Do you belive that any user today in the Facebook, Twitter age that is so adverse to revealing any information would use a web based service where they don't have to? I guess this would be a reasonable justification for government services having a system generated username and taking high protection measures
    – Rakkhi
    Jun 23, 2011 at 15:37
  • 1
    the problem I have with throwaway sound-bites like security is a trade-off is its like saying thats fine as long as you accept the risk. Of course everything is a trade-off, our job as security people is to assess the risk and trade-off's as experts and provide a recommendation. Otherwise what value are you adding?
    – Rakkhi
    Jun 23, 2011 at 15:38
5

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.

2
  • 2
    I agree completely that usernames are not authenticators (as the OP mentioned, usernames are identification, not authentication). However, there are other reasons not to disclose the username, aside from considering it an authentication secret.
    – AviD
    Jun 23, 2011 at 18:21
  • @avid such as? the privacy angle?
    – Rakkhi
    Jun 24, 2011 at 14:01
0

I used to do a mix of security.

For example, for the user mail account :

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.

11
  • thanks for the attempt Anarko_Bizounours . I think you are making point 2. my colleagues did. Can you respond to my counter argument? Isolating an account is an interesting angle, not sure how having a secret username or 3 different usernames helps with this. Surely you are isolating by username attempts per site / application.
    – Rakkhi
    Jun 23, 2011 at 14:20
  • exactly I isolate username per site/application. I'll try to respond to you counter argument. Will edit my answer (pretty messy to respond in comment ;) Jun 23, 2011 at 14:27
  • @Anarko-Bizounours what I meant was even in a SIEM monitoring multiple applications you would get: usernameA attempt on AppA, usernameA attempt on AppB. Combining username attempted and application name you would be able to individually identify the attempt. No need to have different usernames for different apps.
    – Rakkhi
    Jun 23, 2011 at 14:32
  • It's true. But my company policy about that is 1 application 1 username. I know it's pretty annoying, especially for us Sysadmin because we need to remember a lot of account. But I came to think, it's not a bad thing. Because like that you reduce the risk of breach. If one account on one machine got a policy like jdoe on machine A, and 124021 on machine B for the user John Doe, the risk is low even if john doe is hack and machine A is cracked, machine B is safe. But I agree, 1 usernames for all apps will be easier to administrate. Jun 23, 2011 at 15:02
  • 1
    While its entertaining to consider the users as 'not my problem' I don't think it is practical. Users are part of real security systems, and they are usually the weakest part. Attempting to enforce a username per application will likely lead to serialization (john1, john2, john3, ...) or context specific usernames (john.netadmin, john.useradmin, john.audit, ...), just like it does with passwords. You could introduce username quality checking, but I suspect you will run into the same issues with usernames that now exist with passwords. Instead of one call to the help desk you'll get two.
    – this.josh
    Jun 23, 2011 at 20:09
0

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.

8
  • @bmike so in your view where does the balance tip? Costs in terms of users forgetting their username, needing to write it down, the additional call center traffic, users having to self service username reminder vs the reduction in security? It's interesting to note HSBC recently added a remember userID tick-box to their on-line banking. I wonder if this was a qualitative or quantitative judgment call
    – Rakkhi
    Jun 23, 2011 at 15:57
  • 1
    @bmike: so why are you using stackexchange where your username is published?
    – symcbean
    Jun 23, 2011 at 16:12
  • 1
    @bmike don't really see what it has to do with user education. I have 100's of sites, I login to some infrequently. I always try my email as username. I would be surprised if many others were not like this. You would not get rid of the username field because it is the key that uniquely identifies your user, without it passwords would have to be unique and you don't want that. Key distinction of identification and authentication.
    – Rakkhi
    Jun 23, 2011 at 16:14
  • Yes my view is it's a bad qualitative decision. If one expends so little effort to educate users and call center costs are not seen as a positive benefit of actually having a secure practice involving real people, then you've already lost. Just get rid of the user name field altogether as it's an engineering cost that you are going to nullify in practice. As a security professional I would make the case to do usernames right or not do it at all. (and if I lost that argument - that's a business decision I may have to live with, but doesn't change the reality from an IT Security point of view.)
    – bmike
    Jun 23, 2011 at 16:17
  • @symcbean Same reason I vote in first past the post elections even though I would design an instant runoff voting system if I had the chance. (this would be much better in a discussion room :-) :-)
    – bmike
    Jun 23, 2011 at 16:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .