68

Supposedly, Microsoft is banning common passwords, and their list will dynamically update:

Microsoft says it is dynamically banning common passwords from Microsoft Account and Azure AD system. […] Microsoft is seeing more than 10 million accounts being attacked each day, and that this data is used to dynamically update the list of banned passwords.

Is this based on actual passwords for other people's accounts, or just passwords used in brute force attempts?

Could a secure system be built that checked password updates against other people's passwords and rejected them if a password was too common?

  • 3
    @NeilSmithline You can ban common passwords specific to your site, you simply can't do it based on existing users passwords. I think this is what you were saying, but since the distinction is important I wanted to make sure it was clear. – Xander May 26 '16 at 17:13
  • 6
    Maybe I'll care when I can have a password >16 chars. – Seiyria May 26 '16 at 19:36
  • 10
    I wonder what, exactly, Microsoft's Alex Weinert means when he writes "we see more than 10M accounts attacked daily". It would be very useful to know what constitutes an attack on an account to them. If that's answerable, say the word, and I'll post the question. – RockPaperLizard May 26 '16 at 19:41
  • 1
    I think OS developers should get together and create a cloud-based interoperable password manager (or equivalent with certificates/keys) built right into the OS. That way these problems will be a thing of the past and everyone wins. – André Borie May 27 '16 at 1:35
  • 5
    @SeldomNeedy Thanks. Yes, it is currently hard to know from that data. If someone tried logging in with every user name starting with a and going to ZZZZZ, with the password 123456, that could be counted as millions of "attacks". Ironically, such an attack would probably work on thousands of those accounts. – RockPaperLizard May 28 '16 at 1:48
123

We, at Microsoft, are banning the passwords most commonly used in the attacks and nearby variants. We aren't basing this on our user populations, who (because of the system) don't share these passwords unless the attacks change.

The attack lists generally derive from studying breaches. Attackers are smart enough to look at lists to figure out high probability passwords, then do their brute force, etc. around those high frequency words. We look at the same lists plus the attack patterns to determine our ban lists.

Hope this helps.

  • 10
    Who are "we"? – techraf May 27 '16 at 5:14
  • 63
    MSFT. Alex Weinert, Group Program Manager of Azure AD Identity Protection team Source – TJ- May 27 '16 at 5:21
  • 1
    I am not sure I understand the "dynamic" part: (from the OP source) (...) and prevents users from having a password that is found on attack lists(...). This means that bad new passwords will be checked or that bad existing passwords will trigger something (like an account lock)? – WoJ May 27 '16 at 14:19
  • 1
    @TJ- Aaaaand changed my LinkedIn password.... – SeldomNeedy May 27 '16 at 23:26
  • 5
    This answer is currently too ambiguous, I suggest rewording it to make it clearer. What does "[users] don't share these passwords" mean (I can take a guess and I'm only 80% sure I'm right)? And what is the actual consequence if a password is on a ban list? And why are there multiple lists? – Peter May 28 '16 at 9:42
29

A system that checks existing account passwords before deciding to block a new user's password as "too common" would, in fact, be self-defeating. You would not only be letting a user or attacker know that in fact the password is valid for some accounts, but that's it's valid for a lot of accounts. Specifically, the commonality threshold value - 1 of them.

So, the approach described in the article is in fact the approach that Microsoft is using to ban common passwords for Microsoft Accounts and Azure AD. It's a combination of known common and/or weak passwords, passwords that are commonly used in brute-force access attempts, and variations on those passwords that are determined to be too similar.

  • 1
    So, Microsoft is not banning passwords that are used too commonly on Accounts/Azure, but that are used too commonly on all services it can find data for? – trysis May 26 '16 at 22:17
  • 2
    @trysis Yes, that's correct. – PwdRsch May 26 '16 at 22:45
  • @trysis And by services you mean websites that have already been hacked? Basically the algorithm learns from other websites' mistakes by making a giant list of "known" passwords from collected breach data, correct? I think such a database could easily be sold out to other companies. – oldmud0 May 26 '16 at 23:21
  • 3
    What you say in the second paragraph of your answer seems to line up with what Microsoft states in their blog post. However, the first paragraph is not correct. There are ways of keeping track of the most common passwords and blocking them, in a way that doesn't help break into accounts. See eecs.harvard.edu/~michaelm/postscripts/hotsec2010.pdf for a careful analysis. (Two of the authors on that paper work at Microsoft Research.) – D.W. May 26 '16 at 23:30
  • 1
    @oldmud0: Why would "other companies" buy such a password list when they can simply download a list from sites such as "Most common passwords list"; "Security Blanket"; "Unmasked: What 10 million passwords reveal"; "SecLists"; "Today I Am Releasing Ten Million Passwords"; etc.? – David Cary May 29 '16 at 17:13
1

Could a secure system be built that checked password updates against other people's passwords and rejected them if a password was too common?

There are reasons not to do so, but if I were tasked with preventing passwords from being overused, I'd receive the password, Hash it, Store the hash in a table with no connection to any user nor even the text that was used to create the hash, or update the count if it already exists. If the count exceeds some limit, advise the user to choose another password. Once an acceptable password is given, salt it and store the salted hash for the user.

So, you're not checking against other user's passwords directly, just against their unsalted hashes.

  • A stripped down version of this may be helpful (as addition): Consider the "hash function" that maps uppercase to A, lowercase to a, digits to 1, specials to % and immediately ban anything hashing to Aaaa, Aaaa11, Aaaa1111, or similar totally overused patterns – Hagen von Eitzen May 29 '16 at 13:23
0

I think the best thing to do is just checking for password weakness on server side, this can be an expensive operation (in example lookup from dictionaries). Also passwords commonly used or checked for attacks are a good bet.

It is possible MS first try to hash the password and compare it with a list of unsecure passwords (that are actually not used by any real user). If the hash fail, then it could in example try to look for password strenght with another euristic, finally it can either refuse or accept the password and forget it in its non-hashed version. If the password is refused it is likely it is added to unsecure hash list.

Password weakness check can also keep into account common used attacks, so it has to be a evolving algorithm.

This has either 2 advantages:

  1. You do not need to store ALL unsecure passwords' hashes.
  2. You can ban altogheter collisions in hashes (in example a strong password with same hash of a weak password).

Of course those are just speculations, we cannot know password security measures taken by such a big corp like microsoft.

As final measure I would just use a different hash for weak passwords compared to real user passwords.

EDIT: Why even weak passwords should be hashed? To me there's no need for strong hashing, but hashing weak passwords would allow at least to "secure" valuable data. It is no cost do some simple hashing, but if any database data leak, you know at least competitors won't be able to easily reverse weak passwords, wich may still be a security concern for services that do not use the ban list or at least may just cause a minor economical advantage.

So to answer GroundZero comment: No, to me neither weak passwords should stored in plain text. A simple hash would benefit the corporation anyway. This is because there are passwords that are culture specific, gather that information would require massive investement, so why should you store valuable info in an easy to retrieve way?

  • Hashing a list of known weak passwords and testing that with password hashes on the system, should not work as you're supposed to salt every password with an unique hash. This method of hashing passwords was made especially to prevent rainbow table attacks. MS should only be able to test the weakness of your password during account creation or when login in, as those are the only times your plain-text password is exposed to them. As Alex mentioned before, MS has a list of know bad passwords (many are publicly available, such as rockyou). They can test your plain-text pw with that. – BlueCacti May 27 '16 at 11:38
  • @GroundZero you missed that I explicitly told to not test hashes on the system. What I was saying is simply: START WITH A LIST OF KNOWN BAD PASSWORDS -> Enrich the list as long as a new bad password is detected by a euristic (much more affordable than just guessing bad passwords programmatically). At this stage salting is totally useless. You can have a cloud but if the same weak password have 2^64 variants you can quickly eat up all storage anyway if you generate/store those in advance XD – GameDeveloper May 27 '16 at 12:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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