70

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?

Michael
  • 2,432
  • 2
  • 20
  • 37
  • I can't find it, but there's a question on this site about banning common passwords specific to your site. Whatever you do, it lowers security. So, no, can't be done – Neil Smithline May 26 '16 at 17:08
  • 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
  • 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. – RockPaperLz- Mask it or Casket 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 01:35
  • @AndréBorie Anyone could do it. The problem is you'd have to get all the OS developers to agree to it. That's the hard part. – phyrfox May 27 '16 at 21:50
  • @RockPaperLizard Looking at the [security brief](http://www.microsoft.com/sir) referenced in [this article](https://blogs.technet.microsoft.com/ad/2016/05/24/another-117m-leaked-usernames-and-passwords-new-best-practices-azuread-and-msa-can-help/) I get the sense that metrics for distinguishing attacks from "logon attempts" is partly heuristic e.g. unusual IP-address, etc. It's possible the real number is much lower or indeed much higher. – Seldom 'Where's Monica' Needy May 27 '16 at 23:37
  • 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. – RockPaperLz- Mask it or Casket May 28 '16 at 01:48
  • Assuming, and this is a big assumption, that Microsoft has the basic skills to block IP ranges, "10 million accounts being attacked each day" gives you an idea of the size of botnets combined with the intensity and frequency of secret government (and possibly corporate) data collection efforts. – RockPaperLz- Mask it or Casket May 28 '16 at 01:54
  • If it ever actually works, first consequence would seem to be that a whole new set of "most common" passwords will arise. – user2338816 May 29 '16 at 04:02

4 Answers4

126

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.

Dan
  • 103
  • 3
Alex Weinert
  • 786
  • 1
  • 5
  • 4
  • 12
    Who are "*we*"? – techraf May 27 '16 at 05:14
  • 65
    MSFT. `Alex Weinert, Group Program Manager of Azure AD Identity Protection team` [Source](https://blogs.technet.microsoft.com/ad/2016/05/24/another-117m-leaked-usernames-and-passwords-new-best-practices-azuread-and-msa-can-help/) – TJ- May 27 '16 at 05: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.... – Seldom 'Where's Monica' Needy May 27 '16 at 23:26
  • 1
    Oh, so this is based on brute force. And by "brute force", I don't mean trying to guess every possibility. I'm referring to the password lists that black hat attackers are successfully using, and then Microsoft obtaining those lists when they are found on computers which are confiscated with the help of a government's... brute force. – TOOGAM May 28 '16 at 07:06
  • 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 09: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.

Xander
  • 35,616
  • 27
  • 114
  • 141
  • 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 http://www.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
  • 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"](http://www.passwordrandom.com/most-popular-passwords); ["Security Blanket"](http://lorrie.cranor.org/blog/2013/08/12/security-blanket/); ["Unmasked: What 10 million passwords reveal"](http://wpengine.com/unmasked/); ["SecLists"](https://github.com/danielmiessler/SecLists); ["Today I Am Releasing Ten Million Passwords"](https://xato.net/today-i-am-releasing-ten-million-passwords-b6278bbe7495); 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.

TecBrat
  • 133
  • 8
  • 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

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?

Michael
  • 2,432
  • 2
  • 20
  • 37
CoffeDeveloper
  • 516
  • 3
  • 12
  • 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 – CoffeDeveloper May 27 '16 at 12:12