I like this picture by Daniel Miessler which helps your audience get more secure.
In a world of keyloggers, phishing and password reuse;
In a world of 2FA, password managers, certificate based authentication, zero trust;
In a world in which researchers, authorities and criminals have understood how users create passwords and that password complexity is unrelated to password strength;
focusing on password complexity is harmful, misleading and the least of your concerns. Notice that password complexity plays on level 1 of the above picture (and we know since a long time that password complexity is different from password strength). Why not help your audience instead?
Below I will discuss why sharing this popular "time to brute force your password"-table by Hive is harmful and misleading to your audience and what you could do to help your audience.
Why Hive's password table is harmful:
Complexity
It is well known, that password complexity (i.e. does your password contain uppercase letters, lowercase letters, numbers and special characters/symbols) does not increase the strength of the password (i.e. how hard is it for attackers to guess your password.
Why? Researchers and criminals have pretty well figured out, how humans behave when creating passwords, especially regarding numbers and symbols. Criminals instantly know your password if you follow standard human behaviour.
Hive's password table on the other hand promotes password complexity and even gives your audience the harmful illusion to be secure.
Wrong focus
Password complexity is the least relevant topic your audience should focus on. Their time and resources are limited. Making them waste their time with this irrelevant topic harms them.
How the table should look if you want to increase security of your audience:
I describe in another blog-post, what your audience should do to increase their security.
Why the Hive table is also misleading:
Note that there might be a very important difference for you between
“time it takes criminals to guess your password after they obtained the stored password” and
“time it takes criminals to access your account”.
Let’s think about how criminals get access to an account and check if the Hive table applies. Let’s call our Victim Vic and assume you want to have access to his LinkedIn account because you assume that he uses this for business communication. How could you do this?
Scenarios in which you instantly fail:
1. Hope that Vic did not activate 2FA or login with google/apple, otherwise most of the following attacks will automatically fail.
Social engineering:
2. Just ask Vic directly for his password (this works sometimes, and in the right circumstances might even trick experts on social engineering, so don't blame the victims)
3. Call Vic, pretend to be the LinkedIn and ask Vic to identify himself by telling you his password or some code sent to his phone if he has 2FA activated (you can also try to annoy him by sending him 2FA-notifications until he accepts them).
4. Send Vic a phishing mail and e.g. ask him to log into his account at LinkedIm.com because it is urgent. Hope he doesn’t pay attention to the difference between LinkedIn.com and LinkedIn.com (<-or just clicks on this link, which also doesn't send him to google).
Get lucky and observe him entering his password
5. Observe Vic entering his password while you stand behind him or observe him via CCTV.
6. Get a TV-crew to Vic’s workplace and let them record and broadcast the password on national TV.
Hope his system is not secure
7. Try to install some malware on Vic’s device, by either letting him install some software on his own or by using vulnerabilities in other software (it could also work to attack another company and then use the update function to get the malware to Vic’s device). This could work by sending him an interesting looking email, which tricks him to download something or sometimes it is enough to click a link, if there are serious vulnerabilities in his browser (drive by compromise and yes this also applies to iPhones). Then let the malware record him entering his password and use
8. Steal his smartphone or laptop and hope, you can use it without a PIN or fingerprint.
Brute force login on LinkedIn
9. Try guessing his password by going through the list of most common passwords or popular patterns. If you know the name of his partner or pet or his birthday, try those as well (maybe google it?).
10. Probably he used the same password on some other services. Check some sources which passwords are known to be related to his email-address and check if this password also works for Vic’s LinkedIn account.
11. Find the password “Password@XY-shop” linked to his email-address and check if maybe “Password@LI” or “Password@works” works for his LinkedIn-account.
12. Just try out all possible combinations for passwords, which usually is not feasible because after some failed attempts LinkedIn will notice and will let you wait some time before trying again.
Try the password reset options:
13. Check if you can access Vic’s account via the reset password option. Maybe you just have to guess that his favourite meal is pizza, or use google or LinkedIn to find out he went to high school XY.
14. Maybe you can convince his phone-service-provider to issue you a new SIM-card and then try to get a 2FA code or password reset via SMS.
No success so far? Let's try some hacking:
15. Hack into LinkedIn and hope they don’t notice. Then access Vic’s account.
16. If hacking into Vic’s LinkedIn account doesn’t work, maybe you can reset his LinkedIn-password by hacking into his password-reset-email-account.
So, in which of these attacks does Hive's table apply? In none.
But what is the assumed scenario?
17. You hack into LinkedIn and hope they don’t notice. Then grab the file in which Vic’s password is stored. Does Hive's table apply here? No, it depends. How is the password stored?
Cleartext: Hurray, you are finally in. Job accomplished.
Encrypted: That is good for you. Let’s see if you can find the decryption key too. This is probably not much harder than cleartext.
Hashed: Did the company implement best practices (like a dedicated password hashing algorithm, enough iterations, salt)?
Yes, best practices are implemented: Too bad for you - but if you are really lucky, maybe he was inspired by bad advice that the password “MyPassword!1” is a good one. Better give up, if Vic used a password manager to generate a random password.
An outdated, insecure algorithm (like MD5) was implemented. We have two options again. Is the login sufficiently protected so that we actually need to decipher the password?
No, the login is not protected sufficiently and we can start a pass-the-hash-attack instantly, no need to know the password.
The login is sufficiently protected, but thanks to the insecure algorithm, we can guess the password fast, especially if our tool uses knowledge about human behaviour. How long do you need to guess his password?
If Vic created his own password, then you probably have an instant hit. Hurray, finally.
In the case that the password of Vic was randomly generated you have to go through all possible combinations of possible characters. Take a look at Hive’s password table to see how long you need to go through all possible combinations.
We notice, the Hive table is completely wrong if you are in any scenario but: 17 c. ii. 2. b. In all other scenarios (and you can find many more at MITRE's Att&ck-Matrix) you either
instantly can access Vic’s account (social engineering attack/phishing, malware, password reuse, weak but complex password created by Vic, company is hacked and stored passwords the worst way possible or allows pass the hash attacks, bad password reset process with knowledge-based-questions or provider of password reset email/sms compromised) or
need much longer to access Vic’s account (2FA activated, system secured, limited number of wrong password login attempts before login is disabled, best practices implemented for password storage).
Hive’s popular table predicts the time to crack your password (which Hive also explains in the related article), if
you used this password only on a single service,
your password was randomly generated,
the service stored the password in a very bad way but not the worst way possible,
and the service allowed the criminals access to your stored password,
your computing power stays the same (which might be questionable for the above 3 years time lengths) .
I think, it is misleading to your audience if you share the Hive-table without these assumptions.
Final thoughts
This was a critique of the experts promoting password complexity, instead of helping their audience become more secure.
What can you do to increase security and awareness for your audience? Share the above picture by Daniel Miessler.
Or share my picture, if you think it better fits your audience and want to communicate more than the login process:
Share the popular xkcd-post if your audience is interested in mathematics and combinatorial arguments:
Comments