47

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.

data
  • 103
  • 2
Rakkhi
  • 5,803
  • 1
  • 23
  • 47
  • 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 '11 at 13:53
  • @rory-alsop yes. Go try it with rakkhi.s@gmail.com :) Not sure it is designed to let you authenticate the site or just be more friendly. Either way username enumeration plenty – Rakkhi Jun 23 '11 at 14:16
  • I don't know Quora. It'a facial identification device? like fingerprint reader? – Anarko_Bizounours Jun 23 '11 at 15:16
  • @Anarko-Bizounours No a Q&A site: http://www.quora.com/ – Rakkhi Jun 23 '11 at 15:53
  • 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. –  Jun 23 '11 at 15:54
  • @DKGasser but every mitigation I mentioned above except user education can be technically enforced. If you implemented these would you need to keep usernames secret? – Rakkhi Jun 23 '11 at 16:00
  • 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 01 '11 at 20:25
  • @ewanm89 agreed. You could be right about UK govt. But surely these days an email address or mobile is unique enough? in the database each user will have a unique ID anyway but it doesn't need to be used to login. – Rakkhi Jul 02 '11 at 09:30
  • There's a related question at [Does username length/complexity/uniqueness positively impact security?](http://security.stackexchange.com/questions/118411/does-username-length-complexity-uniqueness-positively-impact-security) – user389823 Apr 08 '16 at 19:52
  • Related: Related: [Why do we authenticate by prompting a user to enter both username and password? Does prompting the password only suffice?](https://security.stackexchange.com/questions/2384/why-do-we-authenticate-by-prompting-a-user-to-enter-both-username-and-password); [Difference between authentication and identification](https://security.stackexchange.com/questions/10933/difference-between-authentication-and-identification-crypto-and-security-perspe) – Gilles 'SO- stop being evil' Mar 27 '18 at 20:24

5 Answers5

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.

Jeff Ferland
  • 38,170
  • 9
  • 94
  • 172
  • 8
    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 '11 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 '11 at 18:55
  • @Jeff-Ferland I gave you a +1 but the WTF article which I have read before as its on my reader :), they used the username as for authentication. The joke was that it should have been only an identifier. Perfectly illustrates my point. Also do you really care if someone knows your account number? Why? It it is like HSBC online banking you still need a password plus all the other passive checks they do (device, location etc). If its your bank account number all they can do is transfer money in or setup a direct debit which you can cancel. Is the risk really worth having a complicated number? – Rakkhi Jun 24 '11 at 13:59
  • @Jeff-Ferland the problem with your phishing paragraph is that if you allow people to go through the whole scenario it trains people not to look for their image, as an image is always displayed (we have researched this). I also don't know what it has to do with the username question. – Rakkhi Jun 24 '11 at 14:01
  • @Rakkhi - In the WTF article, they used only the password for authentication. The username was a meaningless field. The phishing thing is included because the asker talked about site-key images. While I've never had an account with a site that uses those images, I imagine if you enter a wrong yet valid username you'll get somebody else's images. If there's a time they don't display, how can that defeat a phishing attack? They would be unlikely to be displayed there too. – Jeff Ferland Jun 24 '11 at 14:49
  • 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 '11 at 15:01
  • My bank's online system has a bank-selected 8-digit number (that is *not* an account number) as logon ID plus a user-selected password. Are there really banks out there using actual account numbers as the logon ID? On the other hand there is no secondary verification (assuming I get the password right in the first couple of tries). The banking regulations are different here in Australia though. – nnnnnn Jun 28 '11 at 07:22
  • 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 '11 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 '19 at 07:25
  • @ErikP. (cont'd) J Clarkson famously was "robbed" in favour of a charity as proof that this can work (https://www.telegraph.co.uk/news/uknews/1574781/Jeremy-Clarkson-eats-his-words-over-ID-theft.html). It is however an extreme case where you can always get your money back (and I am fine with this, as it makes my life easier, I have the same case in France) – WoJ Dec 17 '19 at 07: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."

l0b0
  • 3,011
  • 21
  • 29
  • 1
    That's true Security is always a tradeoff! Experience it everyday! – Anarko_Bizounours Jun 23 '11 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 '11 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 '11 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.

symcbean
  • 18,418
  • 40
  • 74
  • 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 '11 at 18:21
  • @avid such as? the privacy angle? – Rakkhi Jun 24 '11 at 14:01
0

I used to do a mix of security.

For example, for the user mail account :

  • ID : lastname.name@mail.com
  • 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.

Anarko_Bizounours
  • 101
  • 3
  • 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 '11 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 ;) – Anarko_Bizounours Jun 23 '11 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 '11 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. – Anarko_Bizounours Jun 23 '11 at 15:02
  • @Anarko - made some spelling/grammar updates for you. I have no idea what helmet bread is though:-) – Rory Alsop Jun 23 '11 at 15:30
  • thanks for the spelling/grammar updates (really long day, pretty exhausted. Bread Helmet is a meme that come from the egyptian revolution some month ago. there is a picture of the revolutionnay guy that become the bread helmet meme http://blogs.yorkschool.com/yorkstudents/fmoretzsohn13/files/2011/02/Bread-Helmet-235x300.png – Anarko_Bizounours Jun 23 '11 at 15:32
  • @Anarko-Bizounours I'm sorry I've tried but I can't make sense of that – Rakkhi Jun 23 '11 at 15:33
  • I'm the one that's sorry for not being clear. I don't know how to be more precise, I'm sorry. – Anarko_Bizounours Jun 23 '11 at 15:35
  • 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 '11 at 20:09
  • Indeed. But I use username quality check, in fact I use a username generator which can be parameterized to meet quality requirement. Also I just said (well I wasn't clear with my sentence sorry) that it's not my problem if the user write down they account on sheet of paper and hide them (leave them in public view) on their desk. – Anarko_Bizounours Jun 24 '11 at 06:40
  • I don't see how keeping the user name secret will help against an attacker using network resources for brute-forcing. It just takes longer, which means that it uses even more of your network bandwidth. – Paŭlo Ebermann Jun 28 '11 at 19:02
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.

bmike
  • 204
  • 3
  • 9
  • @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 '11 at 15:57
  • 1
    @bmike: so why are you using stackexchange where your username is published? – symcbean Jun 23 '11 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 '11 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 '11 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 '11 at 16:20
  • Why doesn't increasing security of authentication offset a decrease in security of identification? I think identification and authentication are serial. – this.josh Jun 23 '11 at 19:58
  • @symcbean: The stack exchange user name is not used for login (unless you use the same username for your OpenID provider). – Paŭlo Ebermann Jun 28 '11 at 19:04
  • So let me rephrase my idea. If you first asked for password and only allowed users to enter the username as a second step, would you tell everyone the password entered was valid? Would you broadcast the failed password before taking the user name, after the user name, or never only conceding that everything wasn't a perfect match. – bmike Jun 28 '11 at 20:20