I had one store my credentials on my machine in a plaintext file in the appdata/roaming/Mozilla directory

lmfao alot of times they focus on the design and other stuff while forgetting about security

oh my god it's exactly same case for one of the games I play. They use HTTP connection to an IP address that doesn't even have a domain name, it's just plain IP address, and worse thing is they put both email and password in the url... I mean I'm not even that good at web development and security but I know that is like the most insecure way of doing it

thats because there is a really really old feature that allows you to login from a URL, and even though the dumbness of this is beyond my understanding, it is still A WORKING FEATURE in most browsers.

thats a Z tier

It's also single point of failure

In that respect it's no /worse/ than doing it yourself.

@@jnharton No no, "either Sign In With Facebook or don't use my site at all" is _significantly worse_ than even storing passwords as plaintext. If you give your users _multiple provider options_ for third party auth, then you're fine.

When we use a Third-Party Authentication service, that service produces an Auth-Token which is stored for the session user is logged-in the device, and has some expiry to it. So, it's something like a password, and that auth-token (which acts as a password) is reset after each session.

I enjoy multiple third-party authentication options up until the point that I have to implement them. Polymorphic database rows are... unclean...

More than that. Split your authentification system from your application. That what's done with Google or Microsoft or any external authentification. What you just need to know is if the authentication system really have authenticated your user. For that purpose, it has to emit an authentication ticket that it signs with a private key. You can verify that signature with the public key of the authentication system, guaranting the emiter identity.

@@warny1978 if your website only allows me to login using one of the big companies, I likely won't ever log into it.

@@warny1978yet msft still gets hacked

Yeah basically have an api for your api, that way only an RCE or SSRF will work Might be able to do some rotating api key auth though for the SSRF

if you have an SQL Injection in the first place you probably fucked up....

I feel like S Tier should be using multi-factor authentication on top of A Tier, for the exact reasons you described.

@@WhyFi59 Absolutely. Using secondary factors, especially physical ones, will make it MUCH harder to do non-targeted attacks.

How can you trust "them" at all??!!

@@kishirisu1268 You really should not be using SMS as a secondary factor. Sure it can be a secondary factor, but it isn't _really_ something that you have, in the way that simply using an authenticator app like Google Authenticator og FreeOTP or Aegis is. Even better would be using a hardware key with biometric authorization. But that's to make targeted attacks difficult. If someone is physically at your location, holding you hostage, then nothing will help you.

I think the main advantage of this route of using a 3rd party authentication method like signing with Google will be as described by the video that you get to sleep in peace. Even though the 3rd party SAMLs are not immune to attacks, the responsibility of losing the passwords of your users will not come upon you rather will be upon Google for this example. Sharing my 2 cents of what I've believed since years: No lock is one such which cannot ever be broken, you only need a bigger hammer.

We pull the pepper from a credentials storage that is separate from the database credentials storage but is used at deploy time only.

Peppers are a headache to manage. You cannot rotate them, since you don't have the original passwords to regenerate the hashes. One leak and it becomes a dead weight, so you end up being way more careful about its storage and access for a questionably small gain in security over slow hashes.

@@Dc4nt They are very useful against SQL injection attacks and database hacks which are very common. It makes reading your database pointless. You can rotate them with a small effort. You rotate them using 2-3 versioned password columns. Users eventually have to login with their password again. Then is when you re-pepper and store it under a new version. After a short while you can invalidate all logged in sessions and re-pepper for any user logging in again. Most invalidate logged in sessions within a few days anyways. Upon breach you can invalidate them all in an hour.

@@brooklyna007 I suppose what I'm trying to get at is whether the operational overhead of working with peppers is worth the added protections they provide. Sure you can build in enough infrastructure to make rotation feasible, get it to a state where you might even call it "easy", I just don't think it's worth it when you can just import bcrypt, write a few lines of code, and be better than most homegrown systems from the past 2 decades.

​@@Dc4ntI can understand the reluctance. But remember that GPGPU vs CPU power isn't scaling together. The current suggest bcrypt settings take a bit over a second. That is already a bit of an issue if you're loading a lot after sign in. In short time the strategy might not be feasible. So adding that pepper infrastructure is a way to keep the settings at a sane speed so people can sign in at a reasonable speed while adding protection for more common attacks.

then some mf makes a pull request 😈

I once had a website just randomly dump the user database, including e-mail adresses and plaintext passwords, at the bottom of the page in json encoding. 💀

H tier is to hard code passwords in the source code. 😂 I've seen this too!

I Tier is storing the pws in source code. H tier is storing the encoded pws.

J tier is showing all the passords on the login / signup page

I think the simplest explanation is that it's "one way" because infinite inputs can result in the same output, therefore if given a output, you cannot find out which one of the infinite possible inputs it came from. In your example with "cat" -> "3", it's "one way" because there are more than one 3 letter combinations that would result in "3". Of course, if this were the only property we needed, then we can have a more extreme "algorithm" that returns the same output no matter what you input. Note that this indeed makes it impossible to figure out the input from looking at the (constant) output. Hash algos in practice have more constraints, one of which is that we actually want to have most expected inputs to produce different outputs. Yet the prior constraint must remain; every output must still have infinite possible inputs. This may sound like a paradox but it is actually not. The nuance that allows this is the word "expected". We want different inputs that are actually used to produce different outputs, while each output can potentially come from infinite inputs, but those would not be the ones we statistically encounter. Therefore the hashing algo strikes a balance between getting inputs to produce the same output vs getting them to produce different outputs. (same output is what we call "hash collision") The result is the combination of desirable properties: we can distinguish different inputs by looking at their outputs (most of the time), but we can't literally inverse the function to get inputs from outputs.

Well said.@@lekhakaananta5864

The important detail here is that completely unrelated inputs can produce the same output. Imagine if 'cat' and 'dog' both result in '3'. Other than the inputs being composed of characters from the latin alphabet and having the same length, they have nothing in common. So knowing the output tells you virtually NOTHING about the input

perfect example my fellow cat enthusiast

I usually get people to imagine adding up the places in the alphabets of each letter times their place in the sentence. So for "cat" it is 3*1 + 1*2 + 20*3 = 65. That makes it more intuitive why collisions are hard to find. But then you have a word like "gale" that is hard to find but hashes to 7*1 + 1*2 + 12*3 + 5*4 = 65 as well. So is 65 "cat" or "gale"? Then I mention fixing the output size by taking the remainder when divided by the fixed size and mention how that allows infinitely many such collisions if we consider all possible strings.

THIS

In other words the amount of compute effort is multiplied by N where N is the number of users.

It really depends on exactly what the situation happens to be. If someone can compromise the whole server via figuring out admin credentials or through a software exploit, you might be thoroughly fucked. Salting helps the most when the attacker has only the usernames and the encrypted passwords, because "reversing" the hashing algorithm isn't terribly helpful if everyone used a different salt. Having the salts and knowing the algorithm could expose the credentials' security to a dictionary attack. It would be a lot of work, though.

@@jnharton Salting always increases the effort to hack from a mathematical point of view/. If you only have access to a database or database table then peppering can do a lot. If you've compromised the whole system peppering is useless.

@@brooklyna007 Yes.

Those are also greatly exaggerated. I once generated a random password and then did md5 on it. No one at my work place could crack it with any Tool they used.

It's worth noting that many of those hash functions are pretty useful for checking downloaded files. They easily detect file corruption, bad downloads, and make maliciously altered files much less successful. Sure, there might be a handful of collisions, but it's still tricky to produce a file that has the same hash and still be able to sneak in malicious alterations.

@@GnomeEU Woah, your work place is the whole world?! That's crazy.

@@ultimaxkom8728 wanna bet 100 bucks that you can't crack my md5?

it is wrong to say all hashing will eventually fail due to ever growing computation speed, since it is very easy to increase breaking cost than advance computer technology how good will the computer be when we are already close to single atoms? maybe a trillion times faster in future? or another trillion times after that? it is useless to against a hashing that takes 10^100 more effort to break in, you can even make it harder if you want i feel the weak point is always weak security system and weak passwords or leaking your password

As opposed to the bad ones :)

@@Dorumin I'm sure I could generate arbitrarily many bad use-cases. Like, making sure you REALLY REALLY want to open a file by applying many iterations of encryption to every individual file on your disk. If you really need to load that executable, you can wait a couple minutes, right? And that config file, same deal? Actually, I might love awful use-cases too....

Thr last one is just 3rd party authentication.

​@@jnhartonnot necessarily, you can utilize zero-knowledge (ZK) protocols, look into the Socialist Millionaire Protocol (SMP)

@@jnharton If the hash algorithm is know AOT, you can salt, hash, whatever else client side, and then send that to the server, so the server never gets the plaintext password in the first place (really though you need the server to then hash (+ salt, whatever) the hash it got from the client, so if the client is spoofed to give a doctored hash (equal to one cracked from the server) it would be hashed again and still be wrong (eg. double hash the password, once client, once server))

SRP6a does the last of these. The password never leaves the client, so even if the server is taken over completely by a malicious actor they can't get your password, they can only know if you used the correct password, but they can't know what you used. It's pretty dang cool

Sounds good, which data is 'sensitive', more importantly which is not?

@@stephenlee5929I would consider sensitive data to include things like first name, last name, geo address. birthdate, elem/middle/high schools, pet names, and anything else that taken singly (or as a cluster) might uniquely identify the user. Such information might plausibly have been used to synthesize a password, build a set of security questions+answers, or be used as a hint or reminder. This could be expanded to include anything you would normally keep private (known only by you, your immediate family, or especially close friends)

@@stephenlee5929Generally speaking stuff like a blog post or comments can be considered public or semi-public and therefore not intrinscially sensitive. The same goes for profile photos, forum avatars, and anything that would normally be shown to any other user without restriction.

ظمك

In an ideal world, an authentication/identity provider third party would have some way to identify you in the real world rather than simply being an ordinary account from a third part that functions as a master login.

Because you did not bother to share this video on your social media platforms. Instead you put an upsetting comment to the author, do you think this attitude stimulates him?

@@MaksMikhnevych from my point of view it clearly articulates that his hard work produced an excellent video, hence, the view count shouldn't be representative of it's quality. Sorry if it came off as otherwise. My comment got a heart though... so I think it's probably fine :)

Computerphile previously did the same thing. Look up "how not to store passwords." I think they have more views.

Every comment boosts this vid on the algorithm so we are all helping him here :)

@@MaksMikhnevych Not sharing this video on social media might have the same cause as not being able to use S tier authentication: a user might not even have an account on social media.

If you can keep the pepper secure you can also keep the password database secure (just use the secure secret to encrypt the password column). The pepper is more about the security of the database then the security of the stored password. The requirement is that even if an attacker is able to read everything in the system (the database as well as any other stored secret as any pepper or db encryption keys) the stored password should still be useless; assuming an uncompromised secret pepper defeats that assumption in the security requirement. The assumption is reasonable as it is common that the server is eventually compromised. The idea of a pepper can make sense when implemented in hardware: then it is different from encryption because the software layer can not read the unencrypted data but only query for an hash evaluation. In this case a remote attack can not recover useful information (if the hardware implementation does not leak information about the pepper). But in any software implementation a remote attack that can compromise the db can as well compromise the pepper.

Use if pepper could only lower the length of a salt, but doesn't make it more secure (so you need less storage), if not the case described by Pietro. If it is known, what I think, than it is the same as a salt, but the same salt for everyone. It helps against normal rainbow tables, but with only pepper, you can still generate a rainbow table for this database.

​@@Pietro-qz5tmBut who would risk losing access for all their users (or at least many users at a time even if things are distributed) based on a single hardware failure? Maybe for an embedded device or for 2FA based on SIM but other than those cases such extreme single-point hardware failure risk would be not be good practice for most modern systems.

@@schwingedeshaehersPeppers can also protect against sequel injection attacks where access is only to the database and not to credentials because reading the table doesn't give enough data to *even begin* a brute force attack. But if attackers have compromised enough of the system to get the pepper then it adds nothing.

@@brooklyna007 at depends on how it is designed, but I see currently no way of using it. Your password should be hashed by the time it reaches the DB, which makes every SQL injection with the password part hard, and the pepper doesn't change anything with the user name

yup, it's coming! sorry for the delay. make sure to subscribe so you know when i release it!

@@StudyingWithAlex Thanks!! Keep up the good work bro, this channel is great so far

In HTTP, client-side certificates exist too, though they are rarely used.

Fun fact: a private key is effectively just a looooooooooooooooooooong ass password.