Password vulnerabilities and mitigations

Passwords are one of the most common forms of authentication in today’s very technological world, and for good reason. They are easy to set up and use, and for a lot of applications, are perfectly adequate. Unfortunately, as more and more applications require users to create accounts to utilize their full capacity, the weaknesses of passwords have begun to show themselves. These weaknesses can range from human error, such as forgetting your password or using an incredibly weak and easily inferable one, to insufficiencies with device or application security that allow passwords to be stolen. Some methods to overcome this, such as 2-factor authentication, can be inconvenient to users as well as developers, and other methods, such as biometrics, are not practical and have their own risks. Despite this, there is a solution that can greatly reduce the risks of password loss or compromise: SSOs, or Single-Sign-On solutions.

Let us touch upon some of the issues with passwords first. For one, they’re easy to forget. This happens to even the best of us and users attempts to mitigate this on their own can have security risks. Examples include writing it down on a piece of paper, which unless it’s locked in a safe means that people may be able to find it or even accidentally stumble upon it. Further a user may even jot it down in a Word or Text document, which unless it is stored in a secured file, means that their plaintext password is now floating around somewhere on their machine, or even in an unsecured cloud based application that can be compromised from the internet.

Both of these examples require a malicious actor to have either access to the machine or be in physical proximity of the workspace. However, a much more dangerous side effect of forgetting passwords is our tendency to use ones that are easily remembered, such as 123456 or qwerty or even combinations of our names, graduation dates, or birthdays. The issue is that an easily remembered password can also be an easily guessed password. If a hacker wanted to compromise our account, they could just enter our email and then our password from anywhere in the world.

We exacerbate this situation through our tendency to reuse passwords across multiple sites, with 73% of online accounts being protected by duplicate passwords. This means that if a hacker compromises our password it doesn’t just give them access to one of our accounts, but instead almost any account that we used that password for.  Looking at this from a developers standpoint, let’s say a user has a perfectly adequate password, but still uses it on multiple platforms. Your website may be perfectly secure and very difficult to compromise, but a user may have another account on another platform that is not secure. If the shared password on that account is compromised, the hacker now has access to the user’s account on your application as well.

Aside from human error, there is also the issue of technical security and how it is becoming increasingly difficult to keep passwords secure as attackers’ methods become more sophisticated. Most of the time, passwords are encrypted (emphasis on ‘most of the time’), which is basically encoding them so they aren’t stored in easily readable plaintext, however not all encryption is the same, and even with encryption, passwords can still be very vulnerable to attack.

Say someone attempts to compromise a password, either by intercepting it in transit or exploiting the database where it is stored. They will most likely only retrieve the password hash, which is the encrypted form of a plaintext password. There are a variety of ways to break these hashes, as well as a variety of hashing methods to counter these exploits. For example, an older but still used hash function is MD5, which produces a 128-bit hash value. Compare this to SHA-1 or SHA-2, which generate 160 and 256-bit hash values respectively, making them quite a bit harder to crack than MD5. Going back to our previous example of your secure website versus someone else’s insecure website, you may be implementing SHA-2 while they could still be using MD5.

But how are these hashes actually broken? The important factor to understand is that even complex hash values can be unraveled by the lone hacker if poor password policy is in place. For example, a dictionary attack involves just throwing pseudo-random words and phrases at the hash until matching values are found. This means passwords such as ‘Secure Password’ are much easier to crack than ‘Rceesu Dwspsroa’, despite having the same letters, only rearranged. If there isn’t decent password policy enforced by the developer, complex hash values can still be feasible to break.

Another aspect of password security is how many characters are included. Simple math shows us that both length and the amount of characters required can exponentially increase the amount of possible combinations that a password can be. This is why sites implement character limits and require different kinds of characters, as complex enough passwords can render basic hash cracking methods, such as brute forcing, inert.

Hence, the solution for password security seems to be to use a long, complex password that is regularly updated, to use a different password on every account and to store these passwords in the latest hash values. But once again, we encounter the same issues as before. Who wants to remember one such password, least of all sometimes dozens for all their different accounts, and who is willing to go through that much effort to ensure they have decent, unique passwords everywhere? On top of that, how many developers want to ensure every use case for password security has been addressed while also enforcing strong password policy that could confuse or inconvenience users? This is where SSO’s come in.

Single-Sign-On solutions mitigate issues associated with proprietary passwords. First though, let’s touch on the basics of what an SSO is. An SSO is a sign in process that is performed by an external party instead of the client website and can authenticate users across several independent applications. This means a user only needs to create one password to access whatever accounts share the same SSO, which can drastically reduce several of the risks associated with passwords.

This is because an SSO solution can ensure adequate password strength, such as the amount of letters, numbers, and characters associated required, as well as ensuring that passwords are stored safely using secure hashing, independent of the applications in which they’re used to sign into. Further, if a password is compromised, such as a user accidentally telling someone, instead of having to change their password locally everywhere they used it, they can change it with their SSO instead, and any account associated with that SSO will now have the updated password.

This is a major convenience for users, but also for developers. Instead of having to manage passwords on their own application, they can simply implement an SSO to take care of that task for them. Now, a fantastic example of an SSO is humanID, not only due to its ease of use and security, but because it goes through great lengths to protect user data and privacy as well.

Furthermore, humanID actually forgoes the use of passwords entirely, instead verifying users’ identities using their phone numbers. While not many SSO solutions do this, it eliminates many if not all the issues with passwords, primarily human error, but also technical as the phone numbers are still hashed and secured as part of the process. In the end, applications that implement humanID as their login solution no longer need to be concerned about storing passwords securely as they no longer have to develop their own infrastructure or have to trust another entity to do so. They also no longer need to be concerned with managing user password strength or implementing two-factor authentication, as well as managing risks of user’s shared passwords being compromised on other platforms.