One challenge I faced this week was encrypting passwords and how to properly manage them. It’s interesting to see how many ways this can be accomplished and things we should never do. I have made a couple of applications that require some sort of password storage initially, when I was back in high school, I only used a base64 encoding. Which is laughable, but I was learning and in my mind, that was somehow working because you couldn’t see their password. That’s all that mattered at the time, however all it took was a simple decode(pass) to get back to the original password. Then I started using some sort of hashing that is nonreversible. This was definitely a better option but I never really looked at data breaches and at real-life events that resulted in breaches. So this week I looked more into it, I did a little more research for my current team project. I found lots of interesting information.
One thing with hashing is that a lot of common passwords are simply already out their with their current hash. So simply storing a hashed password for say “password123” in hash like maybe “somerandomhash”, is not good enough anymore. Since running something like sha256(password123) will always result in the same hash, it makes it easier to guess. You then simply compare that hash against the common password’s hash and you find out the password. So I discovered that there are newer techniques to protect against this called salt. The salt method uses a unique text to append to the password when creating the hash. That way you cannot simply search for already decoded passwords.
So this makes it very hard for even with a data breach and direct access to the unique text and hashed password to be decoded. To add even more security you can repeat this process and do something like sha256(salt + sha256( salt + password)). This isn’t necessary however. Another method called pepper is also a very good choice, for example sha256( pepper + sha256(salt + password)). Where pepper is the same random text for all users and salt being unique. The pepper is never stored in the database which makes it even more secure but can be a pain in case of a breach to deal with. This is a good approach but there is other things apparently that you can implement in the communication/transmission of the password from client to server that can also be made more secure.
