.png)
Password management is all about finding the right balance. Security administrators have to find ways to combine sufficiently high security policies with a user-friendly experience, which is not always easy. Third-party authentication through popular platforms (Facebook, Google, Apple, GitHub, Twitter, …) can help to avoid these issues, but in some cases, you’ll still want or need to manage passwords yourself. In this blog we take a closer look at what makes a strong password, and how these can be stored securely.
When it comes to strong passwords, there's one factor that stands above the rest: length. The longer the password, the more impervious it becomes to brute-forcing attempts. This is a technique often used by hackers, where a script or program goes over every possible combination of characters in an attempt to match existing passwords.
Just a few extra characters can make a significant difference in stopping unauthorized access, or at least making it much more difficult. For example, a simple password like “apple” can be cracked in just 10 milliseconds. On the other hand, “pineapple” would take 19 hours to guess, and the much longer “ILoveApplesInMyFruitSalad” would take an astonishing 6 septillion years (!) to decipher. You can test how hard a (variation of) your own password is with this online tool.
The Open Worldwide Application Security Project (OWASP), a nonprofit that focuses on improving software security, suggests using passwords with at least 8 characters. We highly recommend enforcing this rule in your applications and platforms as well.
To further enhance security, it's essential to implement account lockout policies. After a certain number of failed login attempts (e.g., 3 or 5), it's advisable to lock the account temporarily. This helps prevent brute force attacks, where an attacker repeatedly attempts different passwords to gain unauthorized access. Account lockout policies should also include mechanisms to unlock accounts after a specific time period or through user-initiated account recovery processes.
There’s another element to keep in mind when determining a password policy: simplicity. Many companies fall into the trap of enforcing complex password rules. We’ve all encountered sites or applications whose passwords have to be at least 12 characters long while using both uppercase and lowercase, a number, and a special character.
The intention behind it may be good, but this idea often backfires. The more complicated passwords get, the more likely users are to forget them, or worse: write them down on a post-it and attach it to their screens.
Instead, we recommend focusing on the password's length as the primary requirement while avoiding rules that will be too restrictive for your users. Keep the message of xkcd's famous comic Correct Horse Battery Staple in mind. A string of four random, (semi) uncommon words can be more secure and easier to remember than a complicated string of characters.
Managing passwords securely is no easy task, but a necessary one that is unfortunately often done with insufficient care.
Speaking of less is more: requiring users to frequently change their password may seem like a good proactive measure to increase security, but it can also lead to unintended vulnerabilities. Chances are that your users will probably use a slight variation of their “old” passwords, only changing one character.
This lowers the overall security level of your application or platform in the long term. Instead, encourage your users to choose strong, memorable passwords and rotate them only when necessary or if suspicious activity is detected. Like we pointed out earlier, an effective policy is all about striking a balance between security and convenience.
Finally, keep in mind that the strength of a password also depends on how easy to guess and common it is. If a password previously appeared in a leak or a rainbow table because it is commonly used, it will be compromised a lot faster. These cases are difficult to secure against, but there are some additional checks that you can perform. We recommend testing new or changed passwords by comparing them with large lists like this password directory whenever there has been a large breach.
Passwords should not be stored in the same way as other data. If you are unfortunate enough to be the victim of a security breach, your data should be illegible to anyone trying to decipher it. The best way to achieve this is through hashing.
Hashing involves a one-way transformation of data into an unreadable string. This ensures that any passwords will remain indecipherable, even if the data is exposed. Keep in mind that, unlike encryption, hashing is irreversible because it only works in one way.
There are lots of hashing algorithms out there, and we suggest using at least a moderately complex algorithm. This will delay hackers when they try to match a password with the resulting hash. For those who want or need to implement hashing themselves in Java, you can refer to the following tutorial on Baeldung. This tutorial provides detailed guidance on implementing password hashing in Java.
At the time of writing, we recommend steering clear of outdated algorithms like MD5 and SHA-1 in favour of more modern and proven algorithms like SHA-3, SHA-256 or bcrypt. These algorithms will eventually be replaced as well, so keep an eye out for up-to-date recommendations.
As worthwhile as hashing your passwords is, it’s simply not enough anymore. Hash functions are deterministic: the same input will always result in the same output.
This means that, when hackers see that several users have the same hash, they know those users also use the same password. Some bad actors also use the rainbow table that we mentioned earlier, which contains a large database of precomputed hashes that lets them find common passwords much faster.
To mitigate these risks, you can add a “salt” to your hashes, which is a unique string that that is attached in front of or behind the password. This makes the process seem non-deterministic. If you generate a unique string every time that a user creates or updates their password and add it before applying your hashing algorithm of choice, no two password hashes will look the same.
OWASP recommends generating salts using a 32-byte or 64-byte secure random function. This makes them hard to predict, just like passwords: the longer it is, the better. You don’t need to encrypt or obscure your salt; you can store them in cleartext right next to your password. One thing to keep in mind is that you cannot make salts easily accessible to the public, so don’t use usernames or email addresses.
Ensuring robust password policies is essential, as discussed earlier. However, all these password policy recommendations can be rendered virtually useless if attackers manage to obtain passwords through other means, such as data breaches or social engineering attacks.
This single point of failure in password-based security can be addressed through Multi-Factor Authentication (MFA). It adds an additional layer of security by requiring users to provide multiple forms of authentication, typically something they know (like a password) and something they have (like a smartphone or hardware token).
Even if an attacker manages to acquire a user's password, they would still be unable to access the account without the second factor of authentication. This makes it difficult for unauthorized individuals to gain entry to protected systems or accounts, providing a critical defense against data breaches and unauthorized access.
To learn how to integrate MFA into your applications, you can refer to the technical tutorial on Two-Factor Authentication with Spring Security, available here: Two Factor Auth with Spring Security | Baeldung.
Managing passwords securely is no easy task, but a necessary one that is unfortunately often done with insufficient care. To summarize the key recommendations discussed in this blog, we've outlined five essential practices to strengthen password security and enhance user authentication.
Cyber security is always changing. Vulnerabilities pop up regularly, and new technologies like quantum computing are on the horizon. Make sure to stay up to date with the latest developments and adjust your tools and techniques when necessary. We recommend checking out the websites of OWASP and NIST to stay informed.
