Passwords play a critical role in information and network security. Hackers can decipher passwords through brute force attacks. Brute force attacks are attacks in which attackers keep on guessing the password until they find the right one. We have to make sure that our passwords are not compromised even if the database is compromised. In this article we will find out how to safely secure and store our passwords by going through a series of steps of Encryption, Decryption, Hashing, Salting, and finally we talk about tokenization.

‍

Encryption and Decryption of passwords

• Encryption is the process of changing out plaintext into an alternative ciphertext to hide the original meaning. Decryption is the process of getting back our true plaintext from the ciphertext. But why do we salt the passwords instead of directly hashing it?

‍

• Here we are going to encrypt passwords on the client-side before sending it to the server-side.

‍

• After securely sending out an encrypted password to the server-side. We decrypt the encrypted password to get back our initial plaintext.

‍

Salting and Hashing the Passwords

• Salting is a process of adding a random secure string to the plain text password before hashing.
• Hashing is the process of converting the password into an unrecognizable string of characters.

‍

• But why do we salt the passwords instead of directly hashing it? Although hashing is a safe way to store our passwords, when the two users have the same passwords their hashes generated are identical. This allows the hacker to crack them by brute force attacks or by using rainbow tables. To solve this problem we are salting the password before hashing.
• For hashing and salting the password we are using the argon2 hashing algorithm. Argon2 was selected as the winner of the 2015 password hashing competition.
• We store the password into the database by hashing and salting it.

‍

• User Login to their account at the client-side by giving their details and password. The password gets encrypted and sent to the server-side, there we decrypt the password and compare the password to the password stored in the database. Argon2 helps in comparing the passwords, and the salt value will be internally stored into a hashed value.

‍

Tokenization for authenticating users without password

Entering the password every time when logging in is neither secure nor user-friendly. So when a user logs in, after successful authentication, a token will be returned. As the user accesses the application’s services, such as APIs they should pass an access token to authorize that the user is a valid user. If the token is verified using the secret key the user is able to access the resource.

‍

Json Web Token

JWT is used for authenticating a user. When the user is logged in, each subsequent request includes the JWT, which allows the user to access services that are permitted by that token. Basically tokens are used to validate the sender’s identity.

JWT is also used for Information Exchange as we can to send data in payloads.

‍

Structure of JWT

XXXXX.YYYYY.ZZZZZ

• X refers to the header
• Y refers to the payload
• Z refers to the signature

‍

Json Web Token is made up of three parts.

1. Headers: Headers contain hashing algorithms such as key value pairs and the type of JWT.

‍

2. Payload: The payload contains data as JSON objects which need to be transferred using tokens.

‍

‍

3. Signature: Signature is a secret key which is mainly used to verify the sender of the JWT. To sign a token it will take headers and payload along with a cryptographically-strong random string.

‍

Verification of Token

After successful creation of the token, we will store it in a browser cookie. Each request made by the client needs to carry the token. The server verifies this with the secret key originally used to generate the token.

‍

Conclusion

Here we talked about the need of encrypting the plain text password before sending it to the server from the client as we should not expose our passwords. Before storing we also salt and the password. We also saw that for continuous access of the application, we generate and share a token to user, who sends it along with API requests to authenticate/authorize themself. The server verifies this with the secret key originally used to generate the token.

‍