In a previous post I wrote about storing password hashes in a database, which raises the question of how to convert an existing legacy password storage system to use hashes (or even no passwords!) without annoying the people who use your system.
Dial ‘S’ for Secret
Let’s assume that you have inherited a database which stores passwords in cleartext in a column called Password. This is not a good scenario. For one thing, it is a temptation to access information we wouldn’t normally have access to, by using that person’s credentials. For another, due to a human trait called “using a computer,” people reuse passwords all the time. I do it myself and I’m writing a post about security (out of 1,089 items in my 1Password vault, 82 items contain reused passwords).
Maybe these credentials work in different places, like a Netflix or Amazon Prime account. Or how about an online bank account? This is known as credential stuffing, and is very illegal, even though it happens repeatedly.
Don’t annoy the users
The easiest thing to do would be to implement a new hashing algorithm (with a random salt), kick out all users who are signed in, and force them to change their passwords when they try to sign in again. This is the most secure, but it is incredibly annoying.
Another possibility would be to implement a new hashing algorithm (with a random salt), send an email to all users telling them that they are required to change their passwords when they try to sign in again, and then force them to do so. This is slightly less annoying than the first suggestion, but it is still incredibly annoying.
A third possibility would be to implement a new hashing algorithm (with a random salt), send an email to all users telling them that they are required to change their passwords as soon as possible, but allow them to connect with their old passwords first before prompting them to change it the next time they are signed in. This is less annoying because you have notified them by email, and they are permitted to sign in first.
A fourth possibility would be to implement a new hashing algorithm (with a random salt), send an email to all users explaining that their passwords will need to change, with a link in the email to reset their passwords. This is the least annoying of the four options thus far, because the email is a call-to-action. In other words, you are telling them that there is a problem, and you’re giving them an action to perform to remedy the problem.
We could remove passwords entirely, by relying on a concept called Single Sign-On (SSO), where a third-party system provides an authentication token that proves who the user is. We’ve seen this kind of thing with Facebook and Google buttons on websites. We would still have to store a token, but this is far more secure than storing a password or password hash (with a random salt).
I’m sure you have some ideas of how to do this as well, so let’s hear them in the comments.
Photo by Hugo Barbosa on Unsplash.
There is another option that annoys users less by making it transparent. Basically, a hybrid approach. The application will examine the stored password to determine its hashing method. If it is the old hashing method, then use the old method to determine the password submitted is correct. If correct, then hash the submitted password with the new hashing method and store. Eventually, all passwords will be updated to the new hashing method.
This method assumes you can accept the risk of the old hashes for the period of time it takes for all users to logon. If you have maximum password ages, this limits this duration. Any accounts beyond this limit are likely no longer valid users. An audit should follow to validate if these account should continue to exist.
Comments are closed.