How to avoid common password vulnerabilities

How to avoid common password vulnerabilities

Weak passwords and password reuse are still some of the most serious concerns for cybersecurity. There are several ways to increase password security but they are often not adopted by users and administrators. Here’s how you can make sure that sensitive data in your web application is not compromised by malicious hackers due to insecure user passwords.

Length or complexity?

The most common password policy enforced by administrators, both in the case of web applications as well as other systems, is a length and complexity policy. For example, a complex password may be required to contain at least 8 characters, uppercase and lowercase letters, numbers, and special characters. However, this policy is actually quite weak and should not be recommended. It’s best to set the minimum length to at least 16 characters, allow for spaces, and introduce no length limit.

Several websites exist, where you can check how long it would take to break your password using a brute-force attack. If you enter an 8-character password with numbers, uppercase/lowercase, and special characters in How Secure Is My Password, it says that a computer could break your password in 9 hours. On the other hand, if you enter a 16-character password that uses only lowercase letters, the result is 224 million years.

The reason for this is mathematical. The formula for password entropy is log2(RL), where R is the number of unique characters and L is the length of the password. If you use only lowercase characters, L=26. If you add uppercase characters and digits, it becomes 62. With special characters, it depends on which characters are allowed, but let us say it becomes 70. For a one-letter password, this means that adding the extra characters increases the complexity threefold. But a two-letter password based on just lowercase characters has 262 = 676 entropy. Therefore, adding just one lowercase character to a lowercase password increases its complexity not three but 26 times. You can clearly see, that it’s the length of the password that really matters, not the complexity.

Is length enough?

If password cracking were only based on the brute-force method (trying every single possible combination), password length would be the best way to practically make attacks impossible. However, there is also a cyberattack technique called dictionary attacks, which basically means password guessing based on commonly used words. For example, a password the quick brown fox jumps over the lazy dog would be cracked by a dictionary attack almost instantly. On the other hand, a passphrase with exactly the same letters: vromjon tobki huhet qecar dzowyf xup selg, would be nearly impossible to crack.

Luckily, dictionary attacks are also very easy to avoid if you use fake words that are easy to memorize because of the way they sound. For example, you can use a passphrase such as bargle zaws gubble meh brudda dulgly. Those who know obscure languages have it even easier because most dictionary attacks are based on English vocabulary and several other popular world languages. For example, kapaċi niekol ħġieġ għax ma tweġġanix could be considered a very strong password.

Another interesting technique for creating secure passwords is using just the first couple of letters from each word to form a long password that is based on a real sentence. For example, you can make a safer password from the quick brown fox… sentence: thequibrofoxjumovethelazdog (although it still contains several dictionary words, which is not optimal). You can also, for example, take the first letter of every word from a longer phrase that you know well: skwklbfhkskppp (the Soft kitty song lyrics). Of course, in all these cases changing some letters into uppercase and adding numbers between the actual words even increases the security (for example, The7Qui0Bro1Fox2Jum3Ove4The5Laz6Dog).

Note that password-breaking tools also replicate user tricks such as replacing some characters with numbers that look similar (e.g. 1 = i, 2 = z), reversing words (e.g. drowssap), adding a number at the end, etc. Therefore, passwords such as dr0w554P123! are easily cracked.

The false sense of security

Another very common mechanism used by web applications and other systems to increase password security is forcing the user to regularly change their password. Such mechanisms usually store the hashes for old passwords and therefore do not let the user reuse any of their previous passwords.

Unfortunately, such password requirements introduce a very false sense of security because users find easy ways to go around them. Let’s be honest, what do we do when the system asks us for a password reset? We usually add the next consecutive number at the end and just keep replacing it every three months when asked (password1, password2, password3…).

This technique does not increase password entropy and does not in any way prevent dictionary attacks. Therefore, more and more big players including Microsoft are moving away from recommending regular password changes. Even large institutions such as FTC are now recommending against this, so don’t implement this mechanism in your web application.

The danger of password reuse

Even if you come up with the most secure password, it becomes insecure if you use it on every website and in every application. With the number of global data breaches, there is a big chance that your password for some sites has been compromised. If you think this is unlikely, you may be surprised: just enter your email address on Have I Been Pwned.

Luckily, most sites do not actually store unencrypted passwords (although even the biggest players on the market have been guilty of it). This means, that in the case of a data breach, it’s only the password hash that is compromised. However, in many cases, the hashes are not secure. Many web applications use old and easy to compromise hash algorithms such as MD5. In such a case, the attacker needs much less time to find the password on the basis of a hash. Of course, the simpler your password, the faster it will be compromised.

Unfortunately, there is no way to check for password reuse in your web application. Therefore, you must simply educate your users and trust that they follow your suggestions.

Security of password managers

To combat password reuse, we resort to password managers. They became more popular in recent years and there are quite a few to choose from for every platform. Many of them are very easy to use and cross-platform. This means that you can, for example, store your password database (secured with a single long and very complex password) in the cloud and access it from your PC, from your mobile, and from anywhere else via a web interface. Password managers combat password reuse and they can also generate complex unique passwords for you, although…

THE AUTHOR
Tomasz Andrzej Nidecki
Principal Cybersecurity Writer

Tomasz Andrzej Nidecki (also known as tonid) is a Primary Cybersecurity Writer at Invicti, focusing on Acunetix. A journalist, translator, and technical writer with 25 years of IT experience, Tomasz has been the Managing Editor of the hakin9 IT Security magazine in its early years and used to run a major technical blog dedicated to email security.

Post Your Comment

Subscribe Our Newsletter

We hate spam, we obviously will not spam you!

Services
Use Cases
Opportunities
Resources
Support
Get in Touch
Copyright © TSP 2024. All rights reserved. Designed by Enovate LLC

Copyright © TSP 2024. All rights reserved. Designed by Enovate LLC