How are passwords stored securely?
Authentication is a core aspect of web applications. Whether online shops like Amazon, online games like World of Warcraft or the PayPal account, they all require a user to first register and then log in when using the application. The password is the recognition feature that tells the application: “This is user xy”. Unfortunately, in the course of penetration tests we repeatedly come across applications that do not take the handling and protection of user passwords seriously enough, or simply implement them incorrectly. That’s why we’d like to clear up a few myths about password storage:
Password hashing on client side as source of error
The procedure works as follows: The user logs in and the password is sent from the client to the server where it is checked for correctness. The password is often “made unreadable” by the client or, as the technical jargon says, “hashed”. The idea would be that an attacker who overhears the communication would not be able to read the cleartext password. Theoretically a good approach but the transferred hash inevitably becomes the password of the application. The server therefore expects the hashed password for the user’s login. If an attacker is able to capture the hash, he can use this hash to log on to the application. This type of attack is also called Pass the Hash (Pth).
The right measure in this case: An encryption of the communication with algorithms according to the current state of the art. This ensures that an attacker cannot read any plain text, which means that neither the password hash nor the password itself can be read.
Prevent Rainbow-Table Attacks
By now it should be part of the general state of knowledge that plaintext passwords should not be stored in a database, not least because the security measures used do not offer sufficient protection. But even hashed passwords can be cracked: Hash functions are so-called one-way functions, which means that the same input always leads to the same output, but in reverse it cannot be inferred from the output to the input. A resourceful attacker can, however, calculate arbitrary character strings in advance as hashs and save them in a kind of dictionary. He then has a reference book with hashs that stand for a particular word, where he can look up found hashs. These attacks are called rainbow-table attacks and allow an attacker to crack hashed passwords.
The “salt” in the soup
In order to protect yourself from this attack, it is necessary to add a so-called “salt” to the hash.
This allows the same input value to be hashed with different salts, making creating a Rainbow table infinitely cumbersome.
Saving passwords correctly is a complex challenge. We recommend to train the respective developers with specific workshops in the area of secure development, so that the responsible persons are not only familiar with the current security concepts, but also receive technical implementation guidelines in the respective development languages.
Our specialists will be happy to help you – contact us!