Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Your Pa$$word doesn't matter
Published Jul 09 2019 08:58 AM 562K Views
Microsoft

(to learn about other credential attacks, see https://aka.ms/allyourcredsarebelongtous)

 

Every week I have at least one conversation with a security decision maker explaining why a lot of the hyperbole about passwords – “never use a password that has ever been seen in a breach,” “use really long passwords”, “passphrases-will-save-us”, and so on – is inconsistent with our research and with the reality our team sees as we defend against 100s of millions of password-based attacks every day. Focusing on password rules, rather than things that can really help – like multi-factor authentication (MFA), or great threat detection – is just a distraction.

 

Because here’s the thing: When it comes to composition and length, your password (mostly) doesn’t matter.

 

To understand why, let’s look at what the major attacks on passwords are and how the password itself factors into the equation for an attacker. Remember that all your attacker cares about is stealing passwords so they, or others, can access accounts. That’s a key difference between hypothetical and practical security – your attacker will only do really wacky, creative stuff you hear about at conferences (or wherever) when there’s no easier way and the target of the attack justifies the extra effort.

 

Here are some ways passwords are broken today (stats are only from Azure Active Directory connected accounts, whether hybrid or cloud only; on-premises only environments are not visible to our team):

 

Attack

Also known as . . .

Frequency      

Difficulty: Mechanism

User assists attacker by . . .

Does your password matter?

Credential Stuffing

Breach replay, list cleaning

Very high – 20+M accounts probed daily in MSFT ID systems

Very easy: Purchase creds gathered from breached sites with bad data at rest policies, test for matches on other systems. List cleaning tools are readily available.

Being human. Passwords are hard to think up. 62% of users admit reuse.

No – attacker has exact password.

Phishing

Man-in-the-middle, credential interception

Very high. 0.5% of all inbound mails.

Easy: Send emails that promise entertainment or threaten, and link user to doppelganger site for sign-in. Capture creds. Use Modlishka or similar tools to make this very easy.

Being human. People are curious or worried and ignore warning signs.

No – user gives the password to the attacker

Keystroke logging

Malware, sniffing

Low.

Medium: Malware records and transmits usernames and passwords entered, but usually everything else too, so attackers have to parse things.

Clicking links, running as administrator, not scanning for malware.

No – malware intercepts exactly what is typed.

Local discovery

Dumpster diving, physical recon, network scanning.

Low.

Difficult: Search user’s office or journal for written passwords. Scan network for open shares. Scan for creds in code or maintenance scripts.

Writing passwords down (driven by complexity or lack of SSO); using passwords for non-attended accounts

No – exact password discovered.

Extortion

Blackmail, Insider threat

Very low. Cool in movies though.

Difficult: Threaten to harm or embarrass human account holder if credentials aren’t provided.

Being human.

No – exact password disclosed

Password spray

Guessing, hammering, low-and-slow

Very high – accounts for at least 16% of attacks. Sometimes 100s of thousands broken per day. Millions probed daily.

Trivial: Use easily acquired user lists, attempt the same password over a very large number of usernames. Regulate speed and distributed across many IPs to avoid detection. Tools are readily and cheaply available. See below.

Being human.

Using common passwords such as qwerty123 or Summer2018!

No, unless it is in the handful of top passwords attackers are trying.

Brute force

Database extraction, cracking

Very low.

Varies: Penetrate network to extract files. Can be easy if target organization is weakly defended (e.g. password only admin accounts), more difficult if appropriate defenses of database, including physical and operation security, are in place. Perform hash cracking on password. Difficulty varies with encryption used. See below.

None.

No, unless you are using an unusable password (and therefore, a password manager) or a really creative passphrase. See below.

 

Only in password spray and cracking attacks does the password have any bearing at all on the attack vector. Go turn on MFA if you haven’t, then let’s drill into those to see what makes a “good password” for those cases.

 

Password Spray

Ok, this one is easy. Your job is to have a password that isn’t easily guessed. But when I say easily, I mean *easily*. In the password spray attacks detected by our team in the last year, we found that most attackers tried about 10 passwords (some as few as 2, some as many as 50) over the duration of the attack.

 

The thing about password spray is that it is detectable, and once detected the login server can shut it down. The faster the criminals go, the faster they are detected, so low and slow is the order of the day. That means each guess is somewhat “precious” - attackers know they need to maximize their impact before they are detected, so they use histograms from existing leaks and use it to generate their attacks.

 

The graph below shows a recent pair of password spray attacks by way of example. Each color represents the hash values of failed password requests; the “hills” indicate multiple failures on the same hash value in that timeframe. There are two distinct attackers – the lower “hills” try 45 distinct password pulses over 22 hashes at around 4,000 accounts per hour; the higher “spikes” try 15 at around 10,000 accounts per hour, running over two weeks. Note the overlap in hashes used by the attackers.

 

 

Pa$$word1.png

 

If your password is not in the exact list your attacker is trying, then you are out of harm’s way. The attackers are mostly working from the same lists, so they try the same passwords. Here are the top 10 we are seeing in guessing attacks on our system:

  1. 123456
  2. password
  3. 000000
  4. 1qaz2wsx
  5. a123456
  6. abc123
  7. abcd1234
  8. 1234qwer
  9. qwe123
  10. 123qwe

There’s nothing fancy here. Users pick these passwords mostly because their high-order bit is simplicity – they can just run their fingers along the keyboard for the top passwords. Attackers try them because statistics of existing breaches tell them to. More targeted or advanced attackers may utilize your complexity and expiration rules to good success; “Summer2019!” will satisfy most complexity requirements, and is easy to remember if you are making your users do complexity and expiration rules (Don’t do either; it’s demonstrably harmful – read https://aka.ms/passwordguidance to understand why). Attackers may also be clever about trying things your employees, specifically, may use – against Microsoft, for example, attackers might try “Office2019” or “Azure19” or “XboxOne.”

But again, the average attacker is moving so slowly in response to detection systems that they only get a few guesses in. So, your password only matters if it’s included in that short list the attacker is trying. As an admin, you want to prevent use of these commonly attacked passwords when passwords are created or changed. We have been using this approach for years in Microsoft account (our consumer identity system which supports Xbox, Skype, Outlook, OneDrive, etc.) and at this point, we have effectively mitigated password spray as a mechanism on active accounts (we have the same system in Azure Active Directory called Password Protection).

 

So, as far as password spray is concerned – your password doesn’t matter – as long as it isn’t in the “most common passwords” top 50 list!

Database Extraction and Cracking

Ok, that leaves the last case, the one that gets people into creating really wacky password rules. That is the “what if the database is extracted?” case. This is a popular, scary attack to talk about. We don’t have good numbers on how often it happens to Active Directory domain controllers because most organizations are understandably tight-lipped when breached. We have lots of sensors deployed to detect extraction of our cloud credential hashes (we won’t discuss the specifics of those sensors for security reasons). We have no evidence of extraction from our cloud systems, but the high-profile breaches of other big systems over the years teaches us to stay humble – and cautious. It *can* happen.

 

We’re going to wallow into a little crypto here to summarize that document. A couple of definitions first:

  • Hashing means creating a one-way, non-recoverable transformation of the password. We use SHA256, which transforms ANY string into a 256bit sequence from which the original password cannot be mathematically recovered.
  • Iterating means repeating that algorithm, which just burns the same amount of compute horsepower for each turn of the crank.
  • Salt means adding something to the password before we hash so that the same password doesn’t result in the same hash for different users. Without salt, each password the attacker breaks gives them access to all accounts using that password; with salt, they have to attack one account at a time because the hash can’t be precomputed and looked up across the database (Salt isn’t a “secret” and is usually stored with the hash – an attacker who has the hash also has the salt).

Azure Active Directory uses 1000 iterations of SHA256 over the salted password to generate our per user, per password hash. If the incoming password is synchronized from on-premises, we receive a hash of that on-premises password then re-hash using the same scheme. What this means is that we never store the password directly; by repeating the algorithm, we can tell if the password we’re checking at login is the same as the password that was set by comparing the generated hashes. In addition to this, the database in which the passwords are stored is encrypted (encryption also scrambles data, but the data can be recovered with a key), and then stored on an encrypted drive using Bitlocker.

 

To extract the data from an on-premises AD environment, the attacker needs to extract the files from a domain controller. Typically, this means the attacker has achieved domain admin status in the network, though variations in security posture can change this. This takes a certain amount of work. To extract the data from the Azure Active Directory cloud environment, the attacker would need access to the environment, the ability to decrypt the database and, if using physical theft, the ability to break the Bitlocker keys. This requires considerably more work. Why put out so much effort when you can just find the password (reuse), guess it (spray) or just ask nicely (phish)?

 

But let’s say the bad guys have secured a database full of hashes – how do they proceed?

  1. Get a cracking rig. The cryptocurrency markets have driven costs here waaaay down and it is now feasible to build a rig capable of cracking in excess of 100B (yes, that’s a B) passwords per second against SHA256 for $20,000 (as of July 2019). Organized criminals and governments can blow that budget away, and quantum may and may not vastly accelerate even these numbers.
  2. Do the homework to figure out the algorithm, salt and any organization specific password rules (min/max length, complexity, etc.). This is usually straightforward, and in our case, we even publish it. But even if it isn’t known, assume the attacker controls at least one account in the system, and can insert a known password from which they reverse engineer the algorithm.
  3. Build an initial list of passwords to try. They start by taking the >500M passwords which have been disclosed in any breach, phish, or spray attack. Think of this as “every password anyone has ever thought of, ever.” Some guidance says to ban all passwords on this list. Try that and see how successful your users are at choosing passwords at all.
  4. Try every password on that list against the target account. Statistically, this will break >70% of user passwords. 500M is ½ a billion, home rigs can run 100B guesses a second – so that complete list just takes 5ms to try. An attacker can run the complete list against 200 accounts every second in a rig like this. Yes, this means most accounts fall almost instantly, and that database extraction detection is super important, as is login anomaly detection, and most of all – turn on MFA!
  5. In the unlikely event that the target account’s password still isn’t cracked, build a list of all popular phrases, song lyrics, news headlines, whatever they can think of to pick up from search engines, Wikipedia, popular articles, etc. These are available pre-canned in the hash-breaker communities. This may pick up another 5-7% of user passwords.
  6. Still no luck? The attacker can run every allowable password going as far as the rig and time will allow. Assuming 96 easily typable characters (without any fancy tricks), we get 96 possible values for each position in the password. Brute forcing like this becomes prohibitively expensive quickly, even on our 100B passwords per second rig. In practice, with this rig, the attacker can try every password up to 8 characters in a day, 9 characters in 3 months, 10 characters in 21 years – each additional character takes 96 times longer, so the attack caps out in practical terms at 9 characters with this rig. All of this buys you only perhaps another 5% of passwords broken:

    Password Length

    Possible Permutations

    Time in seconds

    Time in minutes

    Time in hours

    Time in days

    6

    782,757,789,696

    8

    0.13

    0.002

    0.00009

    7

    75,144,747,810,816

    751

    12.52

    0.21

    0.01

    8

    7,213,895,789,838,340

    72,139

    1,202.32

    20.04

    0.83

    9

    692,533,995,824,480,000

    6,925,340

    115,422.33

    1,923.71

    80.15

    10

    66,483,263,599,150,100,000

    664,832,636

    11,080,543.93

    184,675.73

    7,694.82

    (While we’re here, lets point out that increasing the iterations here basically is linear slowdown for the attack. Going from 1,000 to 10,000 iterations doesn’t even buy one additional character. We’d need to go 100,000 to move each row by one character – at the cost of 100 times the servers, rack space, and energy consumption.)

  7. Finally, the attacker can use predictable patterns (e.g. always start with a capital letter, follow with 3-6 lower case letters, 2-4 numbers and add an exclamation mark at the end) to create a high-ish probability subset of guessable passwords out to perhaps 12 characters. Returns are now vanishingly small, a few percent.
  8. Because of the salt, all that was for ONE account (but with about 85% probability of having succeeded). The attacker must now start over at step one for the next account whose password they want.

The point is – your password, in the case of breach, just doesn’t matter – unless it’s longer than 12 characters and has never been used before – which means it was generated by a password manager. That works for some, but is prohibitive for others. If you are using a password manager, use the maximum possible length – there’s no usability downside if you are already cutting and pasting.

Password managers have their own issues (usability, single high value target, etc.) but in this case a password manager makes a meaningful difference (against this unlikely event) by generating a long, random, string.

Or you could just enable MFA. Ultimately, compromise via database extraction and cracking ends up being similar to guessing,phish, or replay – the attacker must try logging in with the compromised password, and at that point MFA is your safeguard.

The Inevitable Punchline

Your password doesn’t matter except for password spray (avoid the top guessed passwords with a dictionary checker of some kind) or brute force (use more than 8 characters, or use a password manager if you are *really* nervous). That’s not to say your password isn’t terrible. It’s *definitely* terrible, given the likelihood that it gets guessed, intercepted, phished, or re-used.

Your password doesn’t matter, but MFA does! Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.

 

With the increase in sophisticated MFA phishing and bigger cracking rigs (including quantum) what we *really* need is a cryptographically strong credential bound to the client hardware that stores a benign artifact online – which makes the inevitable punchline better creds (like FIDO2). But the assessment of current and next generation creds is the subject for another blog.

 

Stay safe out there!

 

(@alex_t_weinert)

 

The follow up to this article on MFA vulnerabilities, "All Your Creds Are Belong to Us," is here.

35 Comments
Brass Contributor

Nice post :)

 

Copper Contributor

Great Article

Brass Contributor
Great article Alex, thanks for sharing. Still surprises me to see companies not utilise MFA in 2019, when it's so simple to implement!
Iron Contributor

Very informative article Alex. I would argue though that enabling MFA alone is not enough. You should also block legacy auth (basic auth) for as many of your accounts as you can.

We have MFA and are noticing lately when an attacker finds the correct password, we see a few 'regular' attempts which fail due to MFA and then they switch to basic auth protocols like an older Office client to get in.

Currently defining which accounts still need one ore more basic auth protocols like smtp and then we will shut that door as well.

Copper Contributor

Thanks for this article. Given the reccomendation in this article for passwords longer than 8 characters (10 seems to be a good minimum), why does Azure AD still allow 8 character passwords? Wouldn't bumping up the requirement to 10 characters make sense, or at least allow organizations to set the character minimum to be >8?

Microsoft

Hey all thanks for the comments. Challenging format for threaded replies, but:

 

@Adi Hafiskadic It is pretty hard to get all the way out to the edges, because of services that still require legacy auth and because of the need for unattended service accounts. One should still minimize exposure here (CA is our tool for this). We are working feverishly to make this easier.

 

@Steve Hernou yes absolutely agree. We are doing a variety of things to help block this. Keep pressure on users to update clients and keep pressure on vendors (including us) to eliminate legacy auth endpoints. In meantime, scope use of legacy auth to users who absolutely need it.

 

@Craig Chambers (hopefully the right one) 20 hours to break one password puts this at prohibitive levels already, but we are planning AAD password configuration controls so you can increase minimum as needed. That said - length really doesn't matter. Remember by the time you are here, there's an 80% chance that the user is already compromised. Length requirements tend to increase other bad behavior and hurt more than they help - see https://aka.ms/passwordguidance for more on this.

 

 

Copper Contributor

Good article but not fully comprehensive. You omitted several types of attack.

  1. The educated guess attack. We see password guessing attacks at low frequency (trying to fly below the radar). The risk is that the attacker has obtained samples of passwords the user had used on other Internet sites and that the user has a pattern for generating their passwords.
  2. The offline attack. If a user has protected a certificate pfx or an SSH keyfile and that file is stolen then the attacker can attempt to crack that password at their leisure.
  3. Consultants re-using passwords for multiple customers. We have seen attackers logon to VMs that were created by MS consultants with only a few incorrect passwords before success. We suspect that either those passwords were found in some document/list (or perhaps hardcoded in a script on some compromised box) or the attackers had cracked them from a compromised SAM database or a QA/dev network. They were not accounts used interactively. 

 

MFA is not a panacea. SMS and mobile calls can often be hijacked or copied using SS7 hacks. The Authenticator app Verification Code is more secure but not every user has a smartphone. We have seen an increase of attacks bypassing MFA, the most common is an attacker stealing the credentials (e.g. by phishing) and then attempting to sign-in at the same time as the legitimate user. As there is no correlation code or sequence number on the SMS or call-back MFA calls the users may grant the attacker access - even if they get two calls (one from their own sign-in attempt and one for the attacker) they don't regard that as suspicious because it happens often (especially in countries with poor cell coverage).

 

There are also ways to get past CA, it raises the bar but is not impregnable. 

 

We have disabled basic auth on the tenant and blocked legacy auth (by CA policy, don't forget to un-check the menu box so you apply it to ActiveSync on older devices).

Copper Contributor

Cracking a password through brute force may not be as tough as you say. 

Basically, the hacker isn't really interested in my password (which produces hash X), but only a password (which produces hash X).  Since the hash would be shorter than the password, many passwords would yield the same hash.  There could be a 5 character password which produces the same hash code as my 12 character password.

Copper Contributor

The credential stuffing attack shows at least that although the specifics of your passwords don't matter, reuse across sites does in fact matter a lot. So in case no MFA is available, never reuse. :)

Brass Contributor

Hello!  What methods does Microsoft offer or suggest to help identify existing passwords that are considered common passwords in a local Active Directory?  As I understand it, Microsoft now offers a service called Azure AD password protection for Windows Server Active Directory, but my understanding is that this only checks the password when it is set or changed.  Since the recent guidance from Microsoft, NIST, etc appear to be to no longer force a password change unless a compromise is detected, how do we:

  1. Verify that existing passwords for users are not using common passwords that are vulnerable?
  2. Verify that future passwords added to the common password list are checked against existing local AD passwords to report on newly identified weak passwords that we would want to encourage changing?

I recognize that MFA is still critical, but I was curious about attempting to avoid having extremely weak/common passwords.

 

Thanks!

Copper Contributor

HI @alex_t_weinert,

 

MFA is GOOD, but your last paragraph talks about something GREAT: 

         ===> "what we *really* need is a cryptographically strong credential bound to the client hardware"

 

I have worked as a cybersecurity professional only for a few years now, but I am SO CONVINCED that this is the only way to get this worldwide cybersecurity crisis under control.

===> Every trustworthy connected device must be equipped with "high-entropy, tamper-resistant cryptographic keys".

 

I have published a "Cybersecurity Pro Bono Petition/Brainstorm" about this subject, on my LinkedIn account. I am trying to reach out to non-cybersec and cybersec collaborators, alike. i.e.: #humans who want to live in a safer world :)

 

"CYBERSECURITY BRAINSTORM - Technology professionals are not empowered to secure cyber-systems, because technology corporations are working in solo"

 

https://lnkd.in/ekHvmam

 

Stay safe,

Maria

Copper Contributor

1.  Mult Factor Authorization systems will be the death of me yet!  Words do not express hos much I despise having to use such systems, or the contempt I have for people who ASSUME that because I have 1 or more computers that I must ALSO have 1 or more cellular telelphones, and that same device is capable of receiving random textural information.  I haven't owned a cell phone since Verizen depracated my new Samsung PDA that ran Windows CE that cost $800.  It was a gift from someone who passed away several years ago.

 

2.  MFA using an email address is a joke.  For one thing, it requires the email receiving point-device to be online and connected in order to work.  It doesn't help when it isn't even in the same city sometimes.  Then there are the problems with email providers not wanting to honor your email access if they see you have changed location, so again you don't have access to the MFA code.

 

3.  if the email is accessed from the SAME computer being used to log-in to the site sending the MFA, then the safety is defeated anyway as the system, if compromised, is already compromised.

 

4.  The sign-up for using this board to merely comment on the blog-entry requires too much informationm, and way too much is in the TOS one has to "agree to".  Just becuase I clicked that I agree to it doesn't mean I agree to it.  It just means I clicked on it so I can comment.

Copper Contributor

Yes, but.

Of course this is a great article about passwords.

 

But it doesn't address the problem of how people who get hold of a password are able to download a whole database full of stuff.  I propose a look at http://solutionsny.nyc/pc-security.html.  Obviously no useful data should ever be stored on-line, or accessible from an on-line system.  The paper suggests how data should be made available on-line.

 

The paper also suggests, implicitly, that PC architecture (as it is currently implemented) may not be appropriate for a secure environment as compared to the IBM System/360 (now z/System architecture.  On a S/360, all IO devices use the same hardware interface.  There are no unique device drivers.  The supervisor sets up the channel program to operate the device, and runs it under supervisor control.  If the wrong number of characters are transferred, the problem program is cancelled.  Hardware prevents buffer overruns, thus it isn't possible for a buffer overrun to corrupt problem program code and execute inappropriate code.  Each problem program runs in its own address space with it's own storage protect key.  Again, hardware enforced.  There was quite a lot of pushback when IBM started to enforce these rules in MVS, but without them, there is no real security.

Copper Contributor

Sorry but you just can NOT push Microsoft crazy marketing ideas and pretend like you know what you are talking about when it comes to security...

This "no passwords" thing you are pushing looks like Microsoft's typical stubborn behavior...  like something you pushed in 1995. "Hide extensions of known files" - remember that? ITS STILL IN WINDOWS BY DEFAULT and it is spawned whole family of 100s of thousands of all kinds of malware that use it as an entry point into a system, how come no one mentions that security HOLE.

 

With spear-phishing that is planned right and some MITM,  none of your authentication protocols would fare any better than a sole password.

 

Password DOES matter, and you can learn to create them, learn how to remember them on your own.  There are ways of doing that  and being completely secure while never forgetting multiple passwords (yes PERSONAL pass-phrases are a good solution but not the only one) and NO you DON'T need password manager to create or "store" them.

Where did you even get that "good password is only the  one generated by password manager" are they paying you too?

It would help if Microsoft helped with completely removing limitations like 14 or 16 character passwords (256 character thing is not completely alive yet)

 

Also, for db extraction, IF you even manage to do it.  your "100B hash a second" rig what is that for?  MD5 or Microsoft's "pure" 64 bit "encryption"

Do 100 000 000 000 hashes a second for SHA-2 512, and what if I decide to salt hashes in DB like most do, while my users have at least 24 character phrases? You'll find it or its duplicate NEVER or in a really expensive big number of years (maybe phone NSA for help), and when you do you'll have to do it all over again.

 

MFA isn't "additional protection" or protection at all. MITM attacks can be used on it too, it's just an annoyance- for the user, not to mention having to buy Ms's most expensive enterprise E5 version of everything if want MFA to actually work all the time (not even going to explain it - look it up)

 

And what kind of HW/SW "protection" is going to protect you if systems used beneath are faulty by default/design?

What am I talking about? Well TPM decoding and/or storing certificates' PK might sound secure but if certificates that are used, utilize something like SHA-1 hash-ing protocol (designed and proposed by NSA - PROVEN to have BUILT-IN weaknesses, btw reason for all the "joy" of changing them all to SHA-2 few years ago)

Guess what, SHA-2 was also designed by NSA

 

Stop treating us like we are all idiots. No, it is NOT hard to learn to protect yourself. And if your friends call you "geek" or "nerd" for using your mind like normal human being, maybe find some new friends....

 

 

 

Brass Contributor
I've been researching and experimenting with Steve Gibson's SQRL concept. https://www.grc.com/sqrl/protocol.htm It seems to solve many of the issues I have with passwords, account validation et al. A simple client application on each device you might want to use to read mail/access a database etc. The relying party presents a QR code, which the app scans, and you're logged in. If your PC can't scan the bar code (or you're running a Windows phone, so no app) you can enter a password (stored locally) - it never goes to the relying party. The big selling point is that there is no database of hashed/salted/encrypted passwords for the hackers to grab.
Copper Contributor

I have so many problems with the slanted narrative presented in this article. I think I now understand why Microsoft is pushing the end of passwords. My theory:

1)   It’s popular.

2)   Their perspective is limited to broad-scale user culture. They are ignoring how effective traditional guidance is for the minority of users who care enough to adopt it.

 

Absent this article’s slanted narrative, the conclusions from the actual facts presented are more appropriately:

1)   Yes, password hygiene matters.

2)   No, your password strength will not save you if you are going to give it away.

 

Corrections to the table:

Attack

User assists attacker by . . .

Does your password matter?

Credential Stuffing

Reusing passwords.

Using poor passwords.

YES – Don’t reuse passwords for accounts you actually care about.

YES – The majority of credentials obtained are through database extraction and brute force hash cracking, in which case the author clearly shows password strength matters – a lot.

Phishing

Anyone can fall for a good spearphish. However the majority of phishing is easily overcome with basic awareness.

No – user gives the password to the attacker, and I’ll point out that MFA is easily overcome in this case as well.

Keystroke logging

Clicking links, running as administrator, not scanning for malware.

Irrelevant - you are already compromised.

   

Extortion

Being human.

No – exact password disclosed and absolutely nothing else will protect you in this case either so I’m not sure why it’s relevant.

Password spray

Being human lazy.

Using common passwords such 123456 or password

YES – Don’t use short, lazy, common passwords.

Brute force

Using weak passwords.

YES – as clearly shown below, password strength makes all the difference against this common bulk-credential theft vector.

 

To be clear, I am not arguing that passwords are the only way. I do use 2FA and do believe we should move to more modern authentication mechanisms. I even applaud Microsoft for their vision and for looking for ways to make secure authentication simple for everyone.

 

AND I think we should make rational, thoughtful communications about next steps rather than create media hype that subverts today’s good guidance. Contrary to popular belief, passwords are not the root of all evil. They are still necessary, and good password guidance is necessary to follow. 

Copper Contributor

A simple way to make a password virtually unbreakable by brute force is to use one or more unicode characters from outside the Latin set. Add an Arabic letter for example and you're attacker is very unlikely to try brute forcing your password. The search space is simply too big.

Copper Contributor

@Alex Weinert wrote:

...

Organized criminals and governments can blow that budget away, and quantum may and may not vastly accelerate even these numbers.

...

 


That sir, is A+ word play.

Copper Contributor

Nice post and very nice summary about password security.

 

Brass Contributor

I agree totally with commenters Musicalguitarfreak and steve3055 . Thoughtful.

The article has a simplistic view point of “all human-made passwords are weak”, which is simply not true. If you have decent policies in place AND instruct the user (can be a high-priority memo) your systems are quite safe. MS doesnt help by not supplying decent policies. However there are a few third party tools. One very flexible, affordable, and KISS is ActivePasswords (https://wizardsoft.nl/products/activepasswords). Easy to give it a test run too. Works great for us.

Iron Contributor

Great article. Passwords suck. In this day and age it's time to move on. The whole MFA thing is a no-brainer, simple to setup, effective and convenient enough for most people, yet it's still not widely utilised in my experience.

Copper Contributor

@Alex Weinert Thank you writing this.

 

At the end of the article you state:  "Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA."

 

Can you share any of your research, or at least some more details on how the 99.9% was derived?  If there is a little more background I'd like to use this number in some quantitative risk calculations.  

Copper Contributor

Read through this after discovering it in a book... and I find that it definitely assists in a good understanding of this concept. For the record... have been using a password manager for the past seven or eight years now. 

Brass Contributor

Call me paranoid...I use the Edge "Suggest a password" option for run-of-the-mill sites, where I'm not too bothered. I have Privacy Badger installed everywhere, that removes a lot of the cruft, Edge itself stops a lot of the trackers.

For really important stuff, I use a different browser (Edge-Dev / Opera / Firefox), in InPrivate mode. I don't click out of the authenticated site in that browser instance. It requires a little discipline, those click bait ads are sooo smooth now.

 

I write my complex passwords down in a booklet (not indexed by site).

 

I've just received my UbiKey, so I'll start investigating that, it only deals with authentication, not web tracking, but we'll see. The big worry I have is: what if I lose the key / it breaks - will I still be able to authenticate via old-school methods?

Copper Contributor

Yes, you can. that's why you always have multiple factors of authentication... my Microsoft account is set up, for example,to allow both my UbiKey as well as GitHub aauthentication... and my Office 365 account is protected via Duo. 

 

For password storage, I use BitWarden, and I half of the time don't even know the password for each entry in there. I just let the application do it's job. 

Brass Contributor

re-reading this after a few months, am I the only one who finds it amusing that all the security pros are saying we need to do something about security, and as soon as MS announced the requirements for Win11 (hardware root of trust, TPA2 etc) the howls of anguish could be heard on Mars:grinning_face:

users don't want security, at least only for something important like their farcebook account, they just want to do their job. We have to find a way to let them do that without getting in the way, vis my wife's outfit where IT have implemented a 5 minute inactivity lock. Fair enough when you're in a busy shared office, but working from home? Puhleeze!

 

Copper Contributor

Let's set aside the fact that MFA and passwordless auth are not a panacea (in most cases except those with strong cryptographic token and verifier guarantees) and in many cases outsource the risk to requisite processes (hello SMS / SIM Swap attacks and provider identify verification failures), you basically spelled out why length, some complexity, and avoidance of reuse is important in pure offline attacks like bruteforcing, dictionary, rainbow table-based attacks. So I don't quite understand why the "Does your password matter" column says no there. Beyond that, and I'm sure this is mostly geared toward human authentication, but in the case of service accounts or resource accounts, MFA simply may not be possible. Of course today we have things like access tokens and STS and temporary privilege escalation and password vault integration, but in environments older than about 3-5 years, you're going to encounter the tech debt of domain or local service accounts used to keep the lights on with standard password auth. We can sit here and talk about what best practices for IAAA should be followed, but in reality, passwords DO matter, because in reality they are still widely used.

 

Whether people need to reassess and modernize their approaches to credential management and authentication are vastly different than saying "don't worry about password hygiene, they don't matter anyway"

Copper Contributor

Since MS can detect Password Spray and Brute force, why doesn't it lock the account for 30 minutes or an hour after 5-10 wrong attempts?  If they can try 1 Billion passwords a second, this would limit it to 10 a second and for the next 30-60 minutes any passwords tried for the next 30-60 minutes won't work.

Iron Contributor

I have a question @Alex Weinert 

 

In Microsoft Secure Score we have recommendation that affect the secure score: Set 'Minimum password lenght' to 14 or more characters'

If we create a Cloud Account today the password generated i 8 characters, there is no way to change this policy.

 

For going passwordless, I would generate a cloud account use Temporary Access Pass, the user would setup Window Hello For Business and would never recive or know the password for the account.

 

However this would affect the Microsoft Secure Score, the password is only 8 characters.
I might be thinking of this wrong and we can use alternate mitigation and type Passwordless setup. 
Just wondering what is the correct or best way to handle this, or if im thinking of this completly wrong.

 

Great post, really good information and easy to digest :stareyes:

Copper Contributor

This article is four years old and still on point. It is amazing how many people don't have MFA. The article of course assumes that the attackers have powerful machines. So, maybe just add that because even when we build virtual machines to use in teaching password cracking, we have to tweak the CPUs.

Copper Contributor

Very informative and will excellent additional document for Users awareness training.

Copper Contributor

Excelente artículo. Thanks for your article, it is amazing, this world about security. I'm excited to learn more about this.

Copper Contributor

Fantastic post!

Copper Contributor

Great post, really informative.

 

Copper Contributor

I agree with @Musicalguitarfreak that this article has a clear narrative. There are good points, but password length CLEARLY matters (if you're stuck using passwords for various things).

 
Version history
Last update:
‎Nov 09 2023 11:10 AM
Updated by: