According to SecurityWeek, Microsoft is banning common passwords, and they will dynamically update their list:

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 list 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 existing passwords and rejected the update if the 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
    Commented May 26, 2016 at 17:13
  • 6
    Maybe I'll care when I can have a password >16 chars.
    – Seiyria
    Commented May 26, 2016 at 19:36
  • 11
    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. Commented May 26, 2016 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. Commented May 27, 2016 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. Commented May 28, 2016 at 1:48

4 Answers 4


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.

  • 12
    Who are "we"?
    – techraf
    Commented May 27, 2016 at 5:14
  • 65
    MSFT. Alex Weinert, Group Program Manager of Azure AD Identity Protection team Source
    – TJ-
    Commented May 27, 2016 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
    Commented May 27, 2016 at 14:19
  • 1
    @TJ- Aaaaand changed my LinkedIn password.... Commented May 27, 2016 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
    Commented May 28, 2016 at 9:42

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
    Commented May 26, 2016 at 22:17
  • 2
    @trysis Yes, that's correct.
    – PwdRsch
    Commented May 26, 2016 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
    Commented May 26, 2016 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.
    Commented May 26, 2016 at 23:30
  • 2
    @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
    Commented May 29, 2016 at 17:13

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 Commented May 29, 2016 at 13:23

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

It is possible Microsoft hashes the password and compares it to a list of insecure passwords, not actually used by any real user. If the hash fails, then they could check password strength with another heuristic. Finally the system can either refuse or accept the password and discard its unhashed version. If the password is refused it is likely it is added to insecure 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 insecure passwords' hashes.
  2. You can ban collisions in hashes altogether (e.g. a strong password with the same hash as a weak password).

Of course those are just speculations. We cannot know password security measures taken by such a big corporation like Microsoft unless they tell us.

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

Edit: Why should weak passwords be hashed? 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, which 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's comment: No, not even 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, gathering that information would require massive investment, 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
    Commented May 27, 2016 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 Commented May 27, 2016 at 12:12

You must log in to answer this question.

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