Why you must use MFA and Ways to Manage It
How many times per year do you change your passwords? 3? 4?
What if I told you that it really does not matter?
It really does not. The reason is because your password is already out there, hackers have it... and the more you change it, the more likely you are to write it down or store it in some other insecure way that will be ripe for the picking. Sure, the longer your password is the less chance that it will be hacked. But that does not help you if the password was part of the Netflix breach, or the Sony breach, or the Microsoft breach, or the Best Buy breach, or... need I go on? Your passwords are out there. Someone has them.
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 MultiFactor Authentication - MFA.
Read on...
When it comes to composition and length, your password (mostly) doesn’t matter. Here is why...
To understand the rationale behind this, it is essential to examine the primary methods of password attacks and the role passwords play in an attacker’s strategy. The primary objective of an attacker is to obtain passwords to gain unauthorized access to accounts. This distinction highlights the difference between theoretical and practical security measures. Attackers typically resort to unconventional and sophisticated techniques only when simpler methods are ineffective, and the value of the target warrants the additional 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 Ensuring your password is not easily guessed is crucial. In the password spray attacks our team detected over the past year, most attackers attempted around 10 passwords, with some trying as few as 2 and others as many as 50.
Password spray attacks are detectable, and once identified, the login server can block them. Attackers often proceed slowly to avoid detection, making each password guess valuable. They utilize histograms from existing data breaches to optimize their attempts before being detected.
The graph below illustrates two recent password spray attacks. Each color represents the hash values of failed password attempts, with the “hills” indicating multiple failures on the same hash value within a specific timeframe. There are two distinct attackers: the lower “hills” represent an attacker attempting 45 distinct password pulses over 22 hashes at a rate of approximately 4,000 accounts per hour, while the higher “spikes” represent another attacker attempting 15 pulses at a rate of around 10,000 accounts per hour over a two-week period. Note the overlap in hashes used by both attackers.
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 based on the TechSperts research:
123456
password
000000
1qaz2wsx
a123456
abc123
abcd1234
1234qwer
qwe123
123qwe
Users often choose simple passwords, such as running their fingers along the keyboard, due to their ease of use. Attackers exploit these choices based on statistical data from previous breaches. More sophisticated attackers may effectively navigate complexity and expiration rules; for instance, “Summer2024!” meets most complexity requirements and is easy to remember. However, enforcing such rules can be counterproductive (refer to password guidance for more information). Additionally, attackers may tailor their attempts to specific organizations such as Amazon with things like Prime2024, Amaz0nSh0pping, or things along those lines.
Typically, attackers proceed slowly to avoid detection, resulting in only a few password guesses. Therefore, the significance of your password lies in whether it is part of the limited list the attacker attempts. As an administrator, it is crucial to prevent the use of commonly attacked passwords during password creation or changes. This approach has effectively mitigated password spray attacks on directory accounts.
So, when it comes to Password Spray, you are safe as long as you are not using the more common passwords.
Database Extraction and Cracking
Now, let’s address the final scenario that often leads to the creation of overly complex password rules: the “what if the database is extracted?” situation. This type of attack is frequently discussed due to its alarming nature. While we lack precise statistics on how often this occurs with Active Directory domain controllers, as most organizations are understandably discreet about breaches, we have numerous sensors in place to detect the extraction of our cloud credential hashes (specifics of these sensors are not disclosed for security reasons). Although we have no evidence of such extractions from our cloud systems, high-profile breaches of other major systems over the years remind us to remain vigilant and cautious. It is a possibility that cannot be ignored.
We’re going to dive into some technical jargon here to summarize these ideas. 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 employs 1000 iterations of SHA256 over a salted password to generate a unique hash for each user and password. When a password is synchronized from an on-premises system, we receive a hash of that password and re-hash it using the same method. This ensures that we never store the password directly; instead, we compare the generated hashes to verify the password during login. Additionally, the database storing these passwords is encrypted, and the data is further protected by being stored on an encrypted drive using Bitlocker.
To extract data from an on-premises Active Directory environment, an attacker would need to access files from a domain controller, typically requiring domain admin status within the network. This process involves significant effort. Extracting data from the Azure Active Directory cloud environment would require access to the environment, the ability to decrypt the database, and, in cases of physical theft, the capability to break Bitlocker encryption. This is a considerably more complex task. Given these challenges, attackers often resort to simpler methods such as password reuse, password spraying, or phishing.
But let’s say the bad guys have secured a database full of hashes – what now?
Get a cracking rig. The cryptocurrency markets have driven costs here waaaay down and it is now feasible to build a system capable of cracking over 100B (yes, that’s a B) passwords per second against SHA256 for $20,000 (as of May 2021). Organized criminals and governments can blow that budget away, and quantum may and may not vastly accelerate even these numbers.
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.
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.
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!
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.
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.)
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.
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.
Final Thoughts
The primary concern for your password is its vulnerability to password spray attacks (use a dictionary checker to avoid commonly guessed passwords) or brute force attacks (ensure it is longer than 8 characters, or consider using a password manager for added security). This does not imply that your password is secure; it is likely to be compromised through guessing, interception, phishing, or reuse. 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 MultiFactor Authentication - MFA.
In less than 60 minutes, we will hear your technology needs and outline how our security platforms and hardware support plans can increase your security and wrestle your technology support woes. Don't trust your technology needs to just anyone, talk to the TechSperts and find out how good your IT security and support can be.
Contact us TODAY - 610-910-9347 - online@stcntech.com
Commenti