Tips for API Security : 4 Of 12 Hash password with a pinch of salt

In the OWASP list of top ten vulnerabilities that affect web applications Broken Authentication comes in second.  It means that a potential attacker can exploit the connection between the visitor’s browser and the API server to steal credentials. If the passwords are encrypted using a weak algorithm the attacker can easily reverse the encyprted password to plain text. In tip 2 we have seen a method to address the broken authentication vulnerability, in this post we will examine the ways to harden the passwords before it can be persisted to the database.

In any microservices environment, the registration page of the user interface usually (written using one of JavaScript frameworks) sends the user name and password to the API for registering the user. The API should use a password hasher to hash the plaintext password and only then persist (store) the password into the database table. During the login process the the API receives a user name and password and should hash the received password, using the same algorithm that was used during the registration, before comparing it with the password that is stored in the database.

When hashing a password the registration API should select the most secure hashing algorithm. That is lets say the user registration controller has  the following lines of code to hash the password

$hashedPassword = $passwordHasher->hashPassword(
    $userobj1,
    $plaintextPassword
);

The underling programming languiage should be able to provide the necessary salt for the hash process. Hashing algorithms like SHA512 and md5 required the salt to be provided explicitly. However modern hashing algorithms like bcrypt and Argon2 generate the salt automatically and embedded it into the resultant hash. Salt adds a unique, random string to each password before it is hashed, This ensures that even identical passwords produce different hashes.