Did you know that the secure web services you log in to with a password do not actually know the password you use to log in with? Why is it done that way? And how is that even possible? Armed with the knowledge from our article on Hash Functions and Information Security, we can provide answers to these questions.
An unsophisticated login procedure
Let’s first look at what an unsophisticated login procedure would look like. We log in to a web service in the usual way with an account name and password:
Our unsophisticated web service has a table in its database with all the account names and their associated passwords:
The web service first looks up the account name from the completed login form in its database. If the name exists in the database, then the service also compares the password from the login form with the associated password in the database. If the passwords match, the registration is carried out. Otherwise, the registration is denied. At first glance, this is a secure login procedure. Only those who are in possession of a valid account name and know the associated password can gain access to the corresponding account. All others are denied. So far, so good! But what exactly is unsophisticated about this procedure?
The problem is that the passwords are stored in a database. This means that they are potentially known to everyone who has access to the database, including the web service operators and their employees. Furthermore, it is now common practice for many companies to outsource the actual operation of the web services they offer to US cloud computing providers such as Amazon Web Services or Google Cloud. Therefore, we can assume that, in principle, the operators and employees of these cloud computing providers also have access to the database and thus to our password. In addition, of course, criminals could also gain unauthorised access to the data in the database.
Moreover, it is no secret that most users of web services reuse the same password for several services. Therefore, whoever has been able to obtain the password for a target’s Facebook/Twitter account or online travel agency will, with a bit of luck, also have the password for their email, online banking, personal organiser, a dating platform and the intranet of the company where the target works. The economic incentive to steal passwords from the database of any web service is correspondingly high, even if this web service itself is not a lucrative target! The question is: How do we solve this problem?
A more sophisticated login procedure
Let’s recall: The web service described above has a table in its database with all account names and the associated passwords:
We adapt this table in the following way. Instead of storing the passwords, we apply a cryptographic hash function of our choice to the passwords:
What a cryptographic hash function is, has been described in the article on Hash Functions and Information Security. Then, instead of the passwords, we store the resulting hash values in the database:
This changes the login procedure only slightly. We still log in the usual way with an account name and password:
The web service first looks up the account name from the completed login form in its database again. But in the next step, the new procedure differs. If the name exists in the database, then the hash function is applied to the password from the login screen. Only then is the resulting hash value compared with the corresponding hash value in the database. Once again, the passwords are no longer compared with each other, but only their hash values. If the hash values match, the login is carried out. Otherwise, the login is denied.
Apart from the use of the hash function, nothing has changed in the login procedure. From the properties of cryptographic hash functions, it follows that comparing the hash values is just as good as directly comparing the passwords. But now, the passwords themselves are no longer stored in the database of the web service. Anyone who gains access to the database – authorised or unauthorised – no longer has access to the passwords but only to their hash values. The economic incentive described above for stealing the passwords from the database of a web service is thus eliminated because the passwords are now no longer contained in the database.
How does this work in practice?
We hope that we have been able to better explain how it is possible and why it is common practice that secure web services do not even know the passwords that we use when logging in. In practice, the security of this procedure is further increased by generating the hash values with a specialised cryptographic hash function (bcrypt) and additionally linking them with a database-wide secret character string (salt) before applying this hash function. However, we do not want to go into this at this point.
Have you forgotten your password?
If you have forgotten your password for a web service, you can request a password reset from most web services. You will then receive an email with a link that will take you to a form where you can set a new password. We now know why this is handled so awkwardly: the web service does not know your old password. Unfortunately, not all companies follow this established security practice yet. If you indicate by email or in a telephone call with a support team that you have forgotten your password and are then actually told your password, you can conclude that this company does not adhere to modern information security standards. At the latest, then, you should definitely make sure that you do not use this password in any other context. To consistently use a separate password for each web service, you should use a password manager. Then, you no longer need to remember lots of individual passwords and have the added bonus of being able to create high-quality random passwords instead. There are web browser plug-ins for popular password managers that even fill in the login screens of your web services for you. Rarely do convenience and security meet so beautifully.
