Change passwords regularly - a myth and a lie, don't be fooled, part 1
TL;DR: different passwords have different protection requirements, and different attackers using various attacks can only be prevented through different prevention methods. Password security is not simple. For real advise, checking the second post (in progress).
Are you sick of password advices like “change your password regularly” or “if your password is password change it to pa$$w0rd”? This post is for you!
The news sites are full of password advises nowadays due to recent breaches. When I read/watch these advise (especially on CNN), I am usually pissed off for a lot of reasons. Some advises are terrible (a good collection is here), some are good but without solutions, and others are better, but they don’t explain the reasons. Following is my analysis of the problem. It works for me. It might not work for you. Comments are welcome!
Password history
Passwords have been used since ancient times.
Because it is simple. When I started using the Internet, I believe I had three passwords. Windows login, webmail, and IRC. Now I have ~250 accounts/passwords to different things, like to my smartphone, to my cable company (this password can be used to change the channels on the TV), to my online secure cloud storage, to full disk encryption to start my computer, to my nude pictures, to my WiFi router, to my cloud server hosting provider, etc etc etc. My money is protected with passwords, my communication is protected with passwords/encryption, my work is protected with passwords. It is pretty damn important. But yet people tend to choose lame passwords. Pretty lame ones. Because they don’t think it can be significant. But what is not essential today will be relevant tomorrow. The service you used to download music (iTunes) with the lame password will one day protect all your Apple devices, where attackers can download your backup files, erase all your devices, etc. The seven-character and one capital rule is not enough anymore. This advice is like PDF is safe to open, Java is secure. Old, outdated, untrue.
Now, after this lengthy prologue, we will deep dive into the analysis of the problem, by checking what we want to protect, against whom (who is the attacker), and only after that, we can analyze the solutions. Travel with me, I promise it will be fun! ;)
What to protect?
Internet banking, online money
Credit card data
Work related passwords (e.g. Windows domain)
Email, social sites (Gmail/Facebook/Twitter), cloud storage, online shopping
Other important stuff with personal data (e.g. your name, home address)
Not important stuff
This is the category other. I usually use one-time disposable e-mail to these services. Used for the registration, get what I want, drop the email account. Because I don’t want to spread my e-mail address all over the internet, whenever one of these sites get hacked. But still, I prefer to use different, random passwords on these sites, although this is the “low level password” class.
Attackers and attack methods
After categorizing the different passwords to be protected, let’s look at the different attackers and attack methods. They can/will/or actively doing it now:
Attacking the clear text password
This is the most effective way of getting the password. Bad news is that if there is no other factor of protection, the victim is definitely not on the winning side. The different attack methods are:
- phishing sites/applications,
- social engineering,
- malware running on the computer (or in the browser),
- shoulder surfing (check out for smartphones, hidden cameras),
- sniffing clear-text passwords when the website is not protected with SSL,
- SSL MiTM,
- rogue website administrator/hacker logging clear text passwords,
- password reuse - if the attacker can get your password in any way, and you reuse it somewhere else, that is a problem,
- you told your password to someone and he/she will misuse it later,
- hardware keyloggers,
- etc.
The key thing here is that no matter how long your passwords are, no matter how complex it is, no matter how often do you change it (except when you do this every minute … ), if it is stolen, you are screwed. 2FA might save you, or might not.
Attacking the encrypted password
This is the usual “hack the webserver (via SQL injection), dump the passwords (with SQLMap), post hashes on pastebin, everybody starts the GPU farm to crack the hashes” scenario. This is basically the only scenario where the password policies makes sense. In this case the different level of passwords need different protection levels. In some cases, this attack turns out to be the same as the previous attack, when the passwords are not hashed, or are just encoded.
The current hash cracking speeds for hashes without any iterations (this is unfortunately very common) renders passwords like Q@tCB3nx (8 character, upper-lowercase, digit, special characters) useless, as those can be cracked in hours. Don’t believe me? Let’s do the math.
Let’s say your password is truly random, and randomly choosen from the 26 upper, 26 lower, 10 digit, 33 special characters. (Once I tried special passwords with high ANSI characters inside. It is a terrible idea. Believe me.). There are 6 634 204 312 890 620 different, 8 character passwords from these characters. Assuming a 2 years-old password cracking rig, and MD5 hash cracking with 180 G/s speed, it takes a worst case 10 hours (average 5) to crack the password, including upgrading your bash to the latest, but still vulnerable bash version. Had the password been 10 characters long, it would take 10 years to crack with today hardware. But if the password is not truly random, it can be cracked a lot sooner.
A lot of common hashing algorithms don’t use protections against offline brute-force attacks. This includes LM (old Windows hashes), NTLM (modern Windows hashes), MD-5, SHA1-2-512. These hashing algorithms were not developed for password hashing. They don’t have salting, iterations, etc. out of the box. In the case of LM, the problem is even worse, as it converts the lowercase characters to uppercase ones, thus radically decreasing the key space. Out of the box, these hashes are made for fast calculation, thus support fast brute-force.
Another attack is when the protected thing is not an online service, but rather an encrypted file or crypto-currency wallet.
Attacking the authentication system online
Attacking single sign on
Attacking 2FA
- one time tokens (SecurID, Yubikey) can be relayed in a man-in-the-middle attack,
- smartcard authentication can be relayed with the help of a malware to the attacker machine - or simply circumvented in the browser malware,
- text based (SMS) messages can be stolen by malware on the smartphone or rerouted via SS7,
- bio-metric protection is constantly bypassed,
- SSH keys are constantly stolen,
- but U2F keys are pretty good actually, even though BGP/DNS hijack or similar MiTM can still circumvent that protection,
- etc.
Others
Beware that there are tons of other attack methods to access your online account (like XSS/CSRF), but all of these have to be handled on the webserver side. The best you can do is to choose a website where the Bug Bounty program is running 24/7. Otherwise, the website may be full of low hanging, easy-to-hack bugs.
Now that we have covered what we want to protect against what, in the next blog post, you will see how to do that. Stay tuned. I will also explain the title of this blog post.