KTL SOLUTIONS

Keep Your Data Protected with a Microsoft Partner

Share this post

Data Theft is the stealing of information stored on servers, or other devices with an intent of leaking private or confidential information.

As a general population who may or may not extensively deal with computers, you would think how would it affect you as an individual?

Maybe you are extra careful about shredding your letters and bills with your addresses on them, maybe you tear off the prescription labels showing your personal information before throwing it into trash, and maybe you don’t hand out any papers with your social security number on it, etc. All of these practices are great, and are steps in the right direction. But sadly, you, me and everyone else is equally prone to data theft attacks.

Data theft attacks can happen on individual computers as well as big corporations who you genuinely and blindly trust with your data. Often, it is an insider with malign intentions, or simply a careless attitude, or even worse, a Hacker. Data can be compromised, leaked or even stolen when it is transmitted from server to the client. One would think that once data makes it home (Server Rooms or Data Centers), it is inside the “safety zone”, but that’s not necessarily true.

A few years ago, data was stored in data centers, or databases in a relatively secure environment physically guarded by cameras, guards and using other security measures. But with the invention of cloud, data has no boundaries. Your data can now reside in a data center, which is way out of your safe zone. Sometimes data is distributed around various Data Centers to increase redundancy (thereby increasing Availability). Since data is now across various storage spectrum, data protection is becoming exponentially difficult.

Data Theft happens because data is valuable, what if you make that data worthless? Would anyone still want to steal your data? Even if it is stolen, would that data be any good?  

Confusing? Well, when I say turning data “worthless”, I literally mean making it no-good to the OUTSIDE world. It is still very useful to you and your organization. This is the premise of my blog and I am going to describe a couple of techniques to achieve this using hashing and encryption.

Hashing Passwords

Hashing is a mechanism of turning an input data into a fixed-sized alphanumeric string, known as hash value. Hashing is used to store passwords. So instead of a plain password, its Hash Value is stored in the Database Table. Here is an example of a plain password and its corresponding Hash Value.

Password Before Hashing: MyPa$$word#

Password after Hashing: 8Z1q6CSxeW52Cgc7iTYgim1yf37rV7HHZIGxKHNdVfI=

Hashing is one-way. Once data is hashed it can never be retrieved. Even the owner of the data cannot retrieve it back. This may be the reason why, when you forget a password, you can never request for the existing password (I am referring to sophisticated websites), instead you are asked to reset your password. Because no one knows what your password is, it is stored as a Hash Value which can never be converted back.

Phew, our passwords are now safe! But hold on, not so soon. Ideally speaking, hashed passwords can never be retrieved but there are ways to break hashes, such as Dictionary attacks, Brute Force and Rainbow tables.

Let’s put on our Hacker hats, let’s say as a hacker, I have achieved access to the database table that saves user information. I have the username and the password but the password is gibberish (hashed). I can use some commonly used algorithms to create hashes for common dictionary words, or common password patterns (username, 1234, pass@word, etc) and form a list of hash values and compare these to the hashed password stored in the database. If there is a match then I have successfully cracked the password. This list is called a rainbow table.

My Hacker hat is still on, if I have not cracked the password using Rainbow table, worry not, I will go to login screen or any other interface/entry point and start entering every work from list of real words aka dictionary, although it will take time, it may still yield me a password. This is dictionary attack.

My ultimate resort will be brute force, which is to try everything possible under this sky, which is painfully slow.

As users, you can avoid such attacks by paying attention to the following:

  • Use strong passwords, applications should be built to only allow users to enter strong passwords.
  • Do not use dictionary words as passwords. Even replacing ‘a’ with @ and ‘S’ with $ will not be helpful.
  • Choose longer passwords (7 characters or longer would make brute force exponentially slow)
  • Don’t use same passwords across all sites.

Another technique that developers can use to make passwords more secure is called salting.

Salting Passwords

Salting is adding extra bits of information (aka Salt) to the password before it is hashed. This is used to prevent rainbow table attacks. Rainbow table is a list of commonly used passwords turned into has values, if passwords are stored without salts, then the hacker must go through the list looking for a match.

For salted passwords, the rainbow tables would have to be re-build using salt-password combo pre-hashed. If every password uses a random salt, then rainbow tables will have to build one version for Salt1-Password, another for Salt2-Password … likewise for SaltN-Password. This makes the rainbow table prohibitively long and hampers the probability of successfully cracking the password.

Here are a few rules when working with salt:

  • Never reuse the salt in each hash.
  • Never hard code a value in the code to use as the salt.
  • Don’t use a short salt.
  • Never use the username or any other entered data as the salt—it must be random.

 

Even if the database is compromised at some point, the data stored inside the database is still quite secure.

Validating User Details

Now that we have ensured that the data stored in the database is secure, what do we do when we need to validate that the username or password typed in by the user is correct? A rule of thumb is that you should never decrypt the data stored in the database. Instead, you encrypt the data entered at a login page and compare that to the encrypted data stored in the database. For example, if the two hash values match with each other, then user has entered the correct password.

.Net provides out of box services for Cryptography. The System.Security.Cryptography namespace will provide the cryptographic services we need for hashing and salting. The namespace provides services such as encoding and decoding of data, random number generation, hashing, etc. Here is a sample code for generating salted passwords and validating users.

 

private static string EncryptData(string valueToEncrypt)

{

string GenerateSalt()

{

RNGCryptoServiceProvider crypto = new RNGCryptoServiceProvider();

byte[] salt = new byte[32];

crypto.GetBytes(salt);

return Convert.ToBase64String(salt);

}

string EncryptValue(string strvalue)

{

string saltValue = GenerateSalt();

byte[] saltedPassword = Encoding.UTF8.GetBytes(saltValue + strvalue);

SHA256Managed hashstr = new SHA256Managed();

byte[] hash = hashstr.ComputeHash(saltedPassword);

return $”{Convert.ToBase64String(hash)}:{saltValue}”;

}

return EncryptValue(valueToEncrypt);

}

Calling function EncryptData(“MyPa$$word#”) will fetch you Salted password with Salt appended at the end, separated by ‘:’

Password Before Hashing: MyPa$$word#

Salted Password: HashValue of (Password + Salt) : Salt

5PSDBs3J+BoshR54JwQBP6SNorFR5lTJRB1VoXoWfbc=:WMHxRrjrz7sAn2w55yTd8CXn3q81Va3qSQITe66L5YY=

 

private static bool ValidateEncryptedData(string valueToValidate, string valueFromDatabase)

{

string[] arrValues = valueFromDatabase.Split(‘:’);

string encryptedDbValue = arrValues[0];

string salt = arrValues[1];

 

byte[] saltedValue = Encoding.UTF8.GetBytes(salt + valueToValidate);

 

SHA256Managed hashstr = new SHA256Managed();

byte[] hash = hashstr.ComputeHash(saltedValue);

 

string enteredValueToValidate = Convert.ToBase64String(hash);

 

return encryptedDbValue.Equals(enteredValueToValidate);

}

Now to validate the user you can call ValidateEncryptedData and pass the password entered by the user and the hash value for the password as saved in the database. This function obtains the sale by extracting what is after ‘:’ and then again creates a hash for entered password using this sale. If the two hash values match with each other, then user has entered the correct password.

bool isValid = ValidateEncryptedData(“MyPa$$word#”, “5PSDBs3J+BoshR54JwQBP6SNorFR5lTJRB1VoXoWfbc=:WMHxRrjrz7sAn2w55yTd8CXn3q81Va3qSQITe66L5YY=”);

Encrypt Data

We have so far seen how Passwords can be protected, but there could be other sensitive data such as email addresses, names, etc. We cannot use the same technique of hashing with salt that we used for passwords, since hashing is one-way and we need to retain this data. To protect such sensitive data, we can use encryption technique. I will be talking more on encryption in my next blog, so stay tuned.

 

Related Posts

Checking Your CMMC Progress

Written by Alec Toloczko With Cybersecurity Maturity Model Certification (CMMC) requirements on the horizon, it’s crucial for organizations handling Controlled Unclassified Information (CUI) to adhere

Read More »