How to Securely Store Passwords for Apps and Digital Products
How to Securely Store Passwords for Apps and Digital Products
Apps and digital products that require login information always pose a security challenge when it comes to safety. Whenever you store passwords, you risk someone breaking into your database or stealing these passwords. Besides the security risk, the reputational damage could be immense to your company and product.
As you lay out your app architecture, it is important to ensure that passwords are stored securely. There are several methods of achieving this, some good, and some not so great. In this article, we will go through some methods to ensure that apps and digital products can store passwords securely. For software engineers and product architects, this article serves as an eye-opener in digital safety and web security. Let's dive right in.
What to Know About Password Storage
What's the ideal scenario if a hacker should access your servers or databases? The entire aim of such operations is always to gain access to your resources to steal usernames and passwords. These can be through malware or phishing attacks. Usernames are easy to guess and if the password and usernames are stored in a common database, the risk level is elevated. Worse still, many users often use the same username/password combo for different applications, thus posing a huge security risk.
As a general rule, it is important to ensure that all your databases and containerization systems such as Docker are fully secure. Hackers can't steal passwords if they can't access the system to begin with. Additionally, all password databases should be checked against known public dictionaries and deny protocols set in place. Thus, the user can be informed in time and they can find something more suitable.
The topic of cryptography is quite complex for college students just getting into computing. If you find yourself in this demographic, a "write my essay service" can help you work on such a topic effectively. You can access sample papers, drafts, outlines, or even solid citations in different formats.
Now, let’s explore different tiers of password protection for apps and digital products.
Plaintext - Entirely Unsecured
For the longest time, developers didn't pay the required attention to the correct way of storing passwords. Plaintext storage is the worst and most rudimentary way to store passwords. Rumor has it that nearly 30% of websites use plain text databases to store their usernames or passwords. Keep in mind that it isn't uncommon for mobile devices such as Android to pick up malware.
This is just like normal data, where any hacker can read the text in plain language. Thus, with unauthorized access to the database, the hacker can steal all the passwords effortlessly. Remember that hacking has advanced to great lengths and thus plain text passwords represent an easy challenge to hackers.
Encryption - Always Use With Caution
Encryption, in simple terms, is turning a word, phrase, or string into code that cannot be easily deciphered. Encryption is right above the basic level of password protection. When a hacker tries to break into your password database, they will get a bunch of mumbo-jumbo as data. an encryption key is used to securely access the data.
However, encryption provides a one-on-one mapping between input and output. That implies that if the hacker were to gain access to the encryption key, the data would be at risk. The malicious actor might decrypt the data and then you're right back to F-tier plain text security.
Encryption certainly is more appealing than plain text storage and can be an added deterrent to hackers. However, it also makes it easier to access decryption keys from an adjacent server or config file. It also makes the likelihood of an inside job all the more likely. A nefarious employee with access to the decrypt keys can exploit people's passwords.
Hashing - Recommended Minimum
We've already mentioned an ideal scenario where a hacker should not be able to even gain access to a database password file in the first instance. That means not storing the password at all; encryption still has a form of storage to it as already elaborated. Hashing is the next level when it comes to securing passwords.
Hashing works by using an algorithm working one-way to convert passwords into fixed-length strings. But then, you don't need to know the password, rather, you just need to know the sign-up instance.
For example, you can take a password and generate a fingerprint or hash from it at the point of sign-up. If an instance of the fingerprint is encountered again in the future, the algorithm knows that this represents the same password. Thus, the login is secured but the original password can never be retrieved. The hash process itself involves a lot of aggressive mixing and mashing to produce an entirely new output. Think of it as mixing three different colors to get an entirely new color. It would be quite difficult to segregate the original three colors. Hence, the one-way functionality. The hash functionality is demonstrated below:
It's a little similar to encryption with the exception that the algorithm works one way and can never be reversed. But what if two strings hash to the same thing, i.e. two different passwords with a similar hash? That's a property of hash function Algo's which makes it nearly impossible to generate two strings whose hashes collide. That's called "collision resistance".
Choosing the right hash function is therefore important, and a good hash will never output the same thing twice. Older hash functions such as MD5 and SHA-1 while collision-resistant, have become outdated. For example, MD5 has been proven to be flawed by researchers who managed to generate a collision for the same MD5 hash. Newer functions such as SHA-2 have even stronger collision resistance.
So, with hashes, no longer is there a key that can decrypt the entire password database. This is a step above the previous level. However, for the simpletons who prefer to use a mundane password such as "123456" or their date of birth, a hacker can still generate a similar hash. That can be matched to your database and thus voila, the password will be broken. A hacker can also just go through a list of the most popular passwords and generate hashes to be compared with your database. That's called a dictionary attack and if a large database of hashes is generated, these are called rainbow tables.
With this vulnerability, even the mighty hash function might not offer foolproof support. Thus, we move on to the next tier of protection.
Hashing + Salting - Highly Recommended
While hashing raises the bar when it comes to securing passwords, it still isn't the most secure. Processing power has vastly improved, thanks to the introduction of lightning-fast GPUs, CUDAs, and OpenCL libraries. Millions of MD%/SHA1 hashes can be generated in an instant through brute force. A hacker can therefore match the hashes generated.
The hash can be made even more secure by adding a "salt" to it. The salt is a short, random string that is prepended to the password before the new string is hashed. Rainbow table attacks will be made less effective since the probability of a hacker cracking the salt-hash combo is slim to none.
The user can prepend the remembered salt to the password provided during signup. Without the salt, the user wouldn't be able to log in to the database. Rainbow tables are rendered nearly useless since they only contain the non-salted hashes. This also eliminates the likelihood of hashes that are generated from the same password. Also, you won't need to worry about hashes that are similar but created from different passwords.
Salts can be static, meaning that one salt is used per single hash. Or, they can be dynamic, where a random string generator creates an instance of a new salt each time at login. While static salt needs the hacker to only try a single salt string and be lucky, with a dynamic salt, the hacker needs to nearly specify a new hash table for each user in the database. That added cost/work factor makes the hacking operation very expensive. This approach is nearly foolproof.
Slow Hashing - Going Higher
With sheer will and brute force, a hacker can still try to break the code on salt hashes. This is especially so where older computational mechanisms such as MD5/SHA1 are being used for hashing. These hash functions are also designed to be fast since they find other uses other than in password management.
Newer hash functions such as bcrypt, script, and Argon2 are designed to be painfully slow and consume lots of power and memory. That defends against the overwhelming power of hardware such as GPUs. You can specify the desired work factor and reduce the billions of hashes per second to mere thousands per second or lower. While that still leaves room for attackers, the goal is to hinder attacks just enough that the operation reaches a stalemate.
Again, the topic of cryptography brings complex challenges to students who aren't familiar with it. A paper writing service for college with expert writers can help you tackle some of the toughest assignments in cryptography and hashing.
Zero Password Storage - The Final Level
At the highest level, it is always just better to not store passwords at all if such an option exists. And yes, that option does exist. Authentication services such as "Sign in with Google" or "Sign in with Facebook" have already done the hard work for you. Thus, the developer doesn't need to create a username/password database. That lets you sleep better at night knowing that you aren't storing any passwords in your database.
System devs and database admins need to ensure that they make their apps and digital products completely secure. In this article, we've gone through the different mechanisms used to store or manage passwords.
At the lowest level, we covered plaintext password storage which is the worst method that can be used for such operations. Anyone can access the data with a meager effort. We also saw that encryption wasn't ideal as a two-way mechanism. Then we moved to hashing which is a one-way mechanism for generating strings that can't be reversed but can still be exposed due to rainbow tables. We later explored hashing and salting, slow hashing, and zero storage mechanisms.
With evolving hardware and craftiness of hackers, no method is ever 100% effective. Developers/database admins need to constantly stay on top of trends and evolve their ideas to ensure they keep ahead of malicious actors.