“Cryptography is the ultimate form of non-violent direct action.”
― Julian Assange
Today, almost 95% of the deployable commercial applications come with a sign-in form, Hence Passwords remain a primary means of authentication and should be protected when stored on a server when it comes to engineers handling these passwords in the backend, even a small mishandle, can lead to a giant data-theft. Hence, in this post, let's discuss the standard ways to handle sensitive data like passwords and how we can properly store them.
Firstly, let's face it !! Storing the passwords directly in a DataBase is as ridiculous as it sounds, considering the number of data-thefts happening day-in and day-out.
Hence the terms "HASHING" and "ENCRYPTION" comes into the picture:
ENCRYPTION :
Encryption is the method by which information is converted into a secret code that hides the information's true meaning.Encryption is a two-way function; what is encrypted can be decrypted with the proper key
In computing, unencrypted data is also known as plaintext, and encrypted data is called ciphertext. The formulas used to encode and decode messages are called encryption algorithms, or ciphers.
To be effective, a cipher includes a variable as part of the algorithm. The variable, which is called a key, is what makes a cipher's output unique. When an encrypted message is intercepted by an unauthorized entity, the intruder has to guess which cipher the sender used to encrypt the message, as well as what keys were used as variables.
but encryption has an inherent weakness in the applications because the server authenticating the password must have the key to decrypt it. An attacker who steals a file of encrypted passwords might also steal the key, which makes it a cakewalk to retrieve all the passwords.
HASHING:
Thus the most reliable method turns out to be hashing which is a one-way function, With a properly designed algorithm, there is no way to reverse the hashing process to reveal the original password. An attacker who steals a file of hashed passwords must then guess the password.
Here’s how it works: A user enters a password and an ID in a browser and sends it (preferably over a secure link) to the authentication server. The server uses the ID to look up the associated message digest. The password submitted by the user is then hashed with the same algorithm, and if the resulting message digest matches the one stored on the server, it is authenticated.
In this process the server does not store or need to see plain-text passwords. Stealing hashed files does the attacker little good because the attacker cannot reverse the hashing process.
But because people rarely use completely random passwords there is a trick that can be used to help guess the passwords in the file. An attacker can run a collection of a million or so commonly used passwords through a hashing algorithm and get a list — called a rainbow table — of associated message digests for these passwords. It is child’s play for a computer to compare a file of stolen password hashes against a rainbow table. For every match, the table will show the password for that hash.
The remedy to this is to use the SALT (I am not referring to table-salt lol).
A salt is random data/value that is used as an additional input to a one-way function that hashes data, a password.
Add a salt to each password before it is hashed. The resulting message digest is the product of both the password and the salt value and will not match anything on the rainbow table.
Of course, the attacker can always try adding random values to common passwords to find a matching hash, but now the difficulty of guessing the password makes it impractical. The return on investment of such a process is so low that a stolen file of properly hashed and salted passwords is essentially worthless.
Now as a back-end engineer, you are to develop a user model in the database which stores the password.
The implementation of hashing :
Every modern backend language supports this procedure of hashing, I am using node js to show its implementation.
(nodejs is used here, and mongoose framework for designing MongoDB schema)
nodejs contains a inbuilt module "crypto" which takes care of all the hashing
const mongoose = require("mongoose")
const crypto = require("crypto")
const uuidv1 = require("uuid/v1")
// defining the schema of the collection in the database
const userSchema = new mongoose.Schema({
name: {
type: String,
required: true,
maxlength: 32,
trim: true
},
email: {
type: String,
trim: true,
required: true,
unique: true
},
userinfo: {
type: String,
trim: true
},
encry_password: {
type: String,
required: true
},
});
Observe that encry_password is the encrypted password stored in the database.
We have to define a database procedure to take the user password and return the encrypted password.
Below is the authenticate method and secure password method to return an encrypted password.
salt is defined using a npm module called uuidv1, which generates a random value, every time it is called (uuidv1())
// defining database procedures/ functions in the schema
userSchema.method = {
Authenticate : function(plainpassword){
return this.securePassword(plainpassword) === this.encry_password;
},
securePassword : function(plainpassword){
this.salt = uuidv1();
if(!plainpassword) return "";
try {
return crypto.createHmac("sha256",this.salt)
.update(plainpassword)
.digest("hex");
} catch (error) {
return "";
}
}
}
"crypto" provides a wide range of hashing algorithms(createHmac is one of them), "sha256" is the hash function, "plainpassword" is the password provided by the user.
This database procedure returns the encrypted password, which is stored in the database.
Top comments (0)