Web Security: Hashing, Salting, and Encryption
As a web developer or engineer it is imperative that your users’ information is safe and secure in a database and during communication with your front end. But adding extra security to your code can add complexity to how your system works. Here is some basic terminology that every developer needs to know at a minimum before handling user information.
Passwords and sensitive information should never be transmitted as plain text. It can and will be stolen, no matter how many users you have on your system. A hash generates a unique fixed length output representation of a given input. A website should maintain a known secret key, and combine both the password and key to generate a scrambled output. Even if a bad actor were to acquire the hashed value of the password, they would still not be able to work out what the password is if a proper salt is used. Hashing is deterministic and therefore is not good enough on its own and not a replacement for encryption. But at a bare minimum it is a step up from transmitting raw text.
If you notice in the code above, there is a variable called salt that is a 128 byte array. What in the world is this? Salting is the addition of unique, random characters known only to the site at the beginning of the string that you want to hash. The salt is typically then stored by the site and used when validating the hash. The reason that a salt is needed is because inputs could potentially be hashed to the same string, but since the salt is random the hashes will then be unique.
Pro tip: You can hash and sal multiple times to increase the difficulty in breaking the security.
Encryption is a function of cryptography and is similar to hashing, except encryption is designed to be undone, while hashing is not. Let’s take a look at an example of how to encrypt data in an ASP.NET c# environment. The using aes variable in the example is what is doing the encryption. Aes is a reference to the AES encryption algorithm which you can read more about here.
Symmetric and Asymmetric Keys are a great security practice for keeping data safe. Continuing with the above example, AES is a symmetric algorithm meaning that you need to use the same key to encrypt and decrypt the data. As with everything in this post, never store a cryptographic key in plaintext or transfer a key between machines in plain text. It’s not sage. Instead, consider using a secure key container to store any cryptographic keys. In the below example we create an EncryptionMethod object that is initialize to the URL identifies of the cryptographic algorithm used to generate the AES key.
There are so many resources out there that can help you if you are trying to add more security to your platform. And the best practices can really save you and your company later down the line. Personally I have never had to write production encryption code, but doing research on the topic makes me want to know more about the topic!
Tweet me if you work with encryption and any challenges that you face!