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.

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.

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.

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 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:

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.

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.

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.

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.

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.