Saturday, November 21, 2009

Guarding your usernames

Everyone tells you that your password is secret, and that you should never EVER share it with anyone, period. Well, if you're married (like i am), i wouldn't be all to surprised if your other half knows your #PIN (=password) for your VISA/AMEX/Mastercard, and probably a few other cards or online services as well. So much for the recommendation of not sharing your password (a PIN code is a password). Of course you're paranoid about your own security, but what about him/her?

Anyway; what i very rarely see, are guidelines on guarding your username. After all, if your going to call help desk, you'll probably be asked for your username and your full name. Nobody has probably told you to be a little suspicious about "anyone" asking you for your username, it's all about the passwords. Now here's the scary part: if somebody were to break into your account, either privately or at work, they would need to obtain at least 2 pieces of information: your USERNAME and your PASSWORD (they need a place to logon as well, but that's the easiest part to figure out).

If anybody were to break into any organization, they would need:
1) somewhere they can attempt multiple logons for multiple accounts,
2) usernames (account names) to use for logon attempts, and
3) a list of passwords to try out for every username. The more accounts in the organization, the higher the chance of compromising accounts and gaining unauthorized access.

1. Finding targets
Google, as well as other search engines, will happily provide hundreds of thousands of possible targets if they know what to search for. (No, i'm not providing examples.)

2. Obtaining account names
Most organizations has logical and easy to guess naming schemes for personal accounts. firstname.lastname, shorter versions of those, or even simpler schemes such as increasing letters or numbers (1,2,3,4 etc). Figuring out the account naming scheme can be as easy as calling the helpdesk - they're there to help, not to be paranoid nor difficult to anyone. Bigger organizations are typically more rigid and pattern-oriented then smaller ones, increasing the risk for the large ones.

Updated on June 12, 2012 (Thx @breaknenter!)
Obtain the current password policy. Preferably this should be the technical implementation, and NOT the written policy. The reason for this is simple:  very rarely will you find any domains or systems where the organisations written password policy is actually implemented 100%. In most cases the default password policy is used, adjusted to the minimum length, complexity requirements (number of character groups needed) and a few other simple parameters, based of the written policy.

3. Password guessing
When a list of usernames has been obtained or generated based on knowledge of the general naming scheme, make an educated guess on 2-3-4 passwords that most probably are in use by at least one user in the organization. (Hint: password).

4. Final stage: getting access
Script it, or use programs to attempt logging on to every account using the passwords you've "guessed". As stated earlier, the more accounts tested, the higher the chance of gaining unauthorized access to one or more accounts. Because of the very low number of attempts per account, there's little chance of locking any accounts, again lowering the risk of setting alarms in the organization. With thousands of attempts being easily possible in minutes, unauthorized access will probably be achieved within hours.

Observation
Most organizations doesn't provide any policy or guidelines on protecting user/account names. Way too many naming schemes are based on logical simplicity, and has seemingly been created without any risk analysis.

Risk
Both observations aids greatly in obtaining unauthorized access. Although initial access will be towards one or more completely random accounts, elevation from no access to random-user-access is a major step for any unauthorized purpose. Do not assume that executive staff or your legal department has any better passwords than anyone else - it could be them, it could be you.

Recommendation
I'm not telling you or anybody else to turn your organization upside-down over this. Understand the risk, do the risk analysis properly, and security may improve without any major changes for end users. After all, security is not about making things worse for your colleagues, but better.

2 comments:

  1. Good points.

    However, if your risk analysis shows that user/account *names* should be protected, then your authentication scheme obviously is malfunctioning.

    If user/account names are protected, they are de facto used as passwords. Instead of inventing unpredictable (hard to remember) user names, I suggest passwords be strengthened!

    Your attack strategy will probably work for any system where users are allowed to choose their own passwords. The administrator might make the guesswork harder for the attacker (i.e. lowering the success rate), by keeping the blacklist and password policy secret. However, one must expect that many users will prefer the easiest (to make up and/or remember) allowable passwords. Whether password, Password og Passw0rd is the better choice, depending the password policy.

    The fact that users tend to choose in similar ways, should - at least in theory - make password guessing possible in any regime where users choose their own passwords, no matter which blacklists are used.

    The robusat answer: perhaps short, system generated passwords?

    NIST 800-63[1] states 1 in 10 to 14 bits as the maximum acceptable success rate for online guessing attacks (10 bits for the population, 14 for a targeted user). Given 10k users (13 bits) you need only 23 bits of entropy in the passwords; 4 alphanumeric characters would do. :-)


    [1] http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf table 4

    ReplyDelete
  2. 4 random alphanumeric characters? NO. NO WAY. :-)

    It could, in theory, give decent protection from online brute-force attacks, where good rate-limiting and account lockout policies have been configured, but that's just not the case.

    Besides; the usability of system-generated passwords which the user cannot change? You would be out of users/customers before you even started.

    ReplyDelete

All comments will be moderated, primarily for spam. You are welcome to disagree with my posts of course.