Password Storage Tier List: encryption, hashing, salting, bcrypt, and beyond

If you're building an app or product, you _need_ to store your users' passwords securely. There's terrible ways to do it, like storing them in plaintext or encrypting them, slightly better ways like hashing or hashing and salting, and even better ways like bcrypt, scrypt, or argon.

Sources:

00:00 Intro
00:26 F Tier: Plaintext
00:55 D Tier: Encryption
01:50 C Tier: Hashing
05:22 B Tier: Hashing + Salting
06:55 A Tier: Slow Hashing
08:45 S Tier: Don't Store Passwords
09:18 Recap

[WackoMcGoose]

The "use a third party auth system" has a massive asterisk on it, though: it depends on WHICH third-party auth system you use. Forcing your users to sign up for Facebook just to access your website puts you straight down to Z tier on principle.

[Bakers]

I've seen worse than storing in plain text. I once ran into a website that stores your login credentials (email and password) *IN THE URL*

[__christopher__]

Another point: Don't store the authentication data in the same database as the application data. That way if you have an SQL injection vulnerability in the application code, the attacker still can't read the authentication data (because the SQL doesn't run on that database).

[diego_samano]

You miss to point out the disadvantage about using third party authentication methods. That is that security breaches are out of your control. It's likely that attackers try to break into big companies rather than attack unknown companies. Then use that information to propagate the attack. Security is definitely a big challenge.

[eruhinmakhtar]

There’s another technique called a pepper where you basically have a single extra salt that is stored separated from your database that then gets applied to all passwords (sometimes applied in obfuscated source code). The benefit to this is that it makes your database functionally resistant to dictionary attacks because the attacker does not know the pepper and thus will never be able to match a hash

[catten]

2:44 I feel that another analogy could be useful to some who are still confused on how hashing functions are completely irreversible. Here's one I found someone on stackoverflow but can't remember the original post.

Imagine you are making a hash function. You take a string input named S. You return the length in characters of S.
For example, if I input the string "cat", you would get the number 3 back. There is no way to turn 3 back into cat, they
have no relation. This happens at a far more complicated level in hashing, where there isn't a way to go backwards,
because the hash algorithm removes any useful information.
The example hashing algorithm shouldn't be used if it wasn't already obvious, because of the collisions.

[Mothuzad]

You made this video so well that I still watched the entire thing despite already knowing all this and having implemented a slow-hashing-based password system.

Gotta love a good proof-of-work use-case!

[ItsaDigitalHamster]

SHA1 and MD5 were proved insecure because algorithms were found to generate hash collisions (where two messages have the same hash) more efficiently than by brute force. This reduces the work an attacker would need to do to find something that hashes to your password, which allows them to break in. However, it's not just about having a foolproof hashing algorithm - newer algorithms have also always generated hashes of ever growing length. As computing power has exploded exponentially, what was unbreakable 20 years ago is now possible to crack in reasonable time just by trying all the possibilities. So it's not just these two. All encryption/hashable algorithms that would have been fast enough to be practical a couple of decades ago, are now small enough to be breakable on modern hardware.

[ArtemShoobovych]

One more architectural way to store credentials (not necessarily passwords) is to store them in a separate database which is only accessible by other systems, so there are no credentials for the database to speak of. This requires a third "party" in communication between systems, which manages accounts and credentials and rotates them (generates new credentials) periodically, called Identity Authentication Service (IAS). This is widely used in cloud systems (AWS, Google Cloud Platform, Azure, etc).

[okaro]

Without salting they can attack the whole database at once. The weakest will surely break. With salting they need to attack each user separately.

[vunu.]

Truth be told, this is your best video yet. Awesome stuff and very well articulated.

[scottamolinari]

Also, store the "sensitive" data in its own table. So, when a dev has to get user data, they have to consciously go to another table to get the sensitive data. You can also lock down access to it further, if needed and also have encryption at rest too.

[stand]

G Tier is to "open source" the password database contents in plaintext.

[SimonClarkstone]

Also: peppering, client-side certificates, or certain protocols that doesn't ever send the user's password to your server.

[harry_kr]

Such a professional explanation and excellent articulation, how doesn't this have more views??

[MadafakinRio]

This dude is explaining important shit (which a lot of us were interested in but never bothered to look up) while keeping it ELI5.
Good job!

[mohamed-hassan-]

Excellent video with a simple explanation, the simple example you talked about Hashing is AMAZING - the brown color - it's just a smooth, attention-grabbing and not boring at all video, keep up with your good stuff

[DBagg-zzip]

Problem with S tier is possibly losing access to the third party account. Big Tech Company might do something stupid like Nymwars again. Compartmentalization is nice; I'd rather have to respond to the occasional website breach than risk everything. Though, that depends on using a password manager right...

[Relkond]

Google and Facebook both have their own passwords - switching to them doesn’t make the problem go away - it just pushes the responsibility on someone else, which is not a solution.

[michaelboyd]

Going through an encryption course now, and this video replaced an entire chapter for me. Great description, easy to follow application and the why for each is very relatable. Excellent instructional video!!