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.
@@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.
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.
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).
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.
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.
@@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.
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
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.
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!
@@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....
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.
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.
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
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.
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.
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.
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
The benefit of password hashing isn't dependent on the collision or secondary preimage resistance of the algorithm. As far as I'm aware, both of those algorithms are still highly resistant to being inverted.
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.
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. 💀
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.
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).
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.
@@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.
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
@@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
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?
@@MassimoRough 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 :)
@@MassimoRough 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.
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...
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.
this video is really really good, i like how you slowly go up the ranks explaining the problem(s) with the previous one, the only problem i see with this video is the S tier shouldve just been 2fa
Sign in with facebook... NEVER , EVER do this, and so as any services associated with social media. It's not about their credential security, but the possibility that your account can be destroyed completely by "violating community guideline", and result in complete loss of all other accounts that rely on that platform. You don't want to have everything ruined just because you said one single word against the platform's politicla alignment right?
I'm just watching the video, respect and interest the channel is rising from the informative and well-made video... "You can use other authentication services..." and my respect goes lower than the Earth's mantle.
CS Student here! I liked the video very much because it allows you to understand what is real life password managing without the heavy/complex theory it carries behind! A smooth way to be introduced in the subject. congrats bro
You forgot peppering! It's A+C or B+C. Meaning they must both have the asymmetric encryption key and they must break the salted password once decrypted.
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
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!!
You can also get creative with the salting process. Something I did for a personal project was to get the salt by just hashing the username, and then based on the sum of the base 10 digits in the hash of the salt, the hash itself would be inserted after the SUM'th digit in the password string (looping over if SUM > password_digits), and then hashing it all over again. I also used sha512 for this. It's really not much better than just regular hashing if this algorithm is known to the attacker, but if it's not (and it shouldn't be known lol), then this essentially requires brute force to crack it, because it's a salt technique without a db-stored salt ;)
Is there a reason you didn't mention peppering? That's quite an important technique, as it renders dictionary attacks completely useless, even with really bad passwords.
@@kiyu3229 A practical use case of peppering would be the following: First of all, you generate a random string (preferrably quite long). Then, your store that string securely somewhere (not in the database). Storing it in your .env file or wherever you store API keys might be an option. After you've done that, you append it to each new password BEFORE hashing and finally storing it in your db. This way, even if the hacker knows your hashing function and all the salt values because your database has been compromised and has a lookup table with hashes for commonly used passwords, they can neither figure out what passwords your users were originally using nor which users use the same password. However, it is extremely important that you also append the pepper value before hashing user inputs from login forms, as otherwise, the passwords will never match and nobody will be able to log in anymore. Thus, implementing this on a project where users have already signed up is difficult.
I know I'm two years late to complain about this, but there is nothing more inconvenient for logging on than logging in with a third party like google or facebook. Google constantly wants to inject itself into every part of your internet experience. Logging in to a service that uses a google acount logs you into the acount in the browser and other services, and starts syncing stuff. (The way this works changes all the time so good luck avoiding this kind of stuff). Also it mixes up acounts all the time (signing into your student mail and ending up on your personal mail with no way to end up on your student mail besides logging out of your personal mail.) Unnecesary integration of services makes me unreasonably frustrated
7:56 kinda reminds me of lockpicking. Locks don't really prevent theft. Thieves can (theoretically) pick any lock given enough time/resources. But would it be worth it? The goal then of locks is to make it so that getting to your valuables won't be worth it to thieves. Something like that at least
Also, put a version number on the user table for the encryption method used. It can just be a number you assign. That way if you have to change to a more secure method later, existing users can still log in with their existing passwords stored in the old method, and passwords can be automatically and discretely updated to the new method the next time the user logs in.
you can also protect in transit attacks with a one-time hash with a random string at the time of login called a pepper. it mixes well with salt. so if you accidentally connected to a wifi in the airport that was a hacker, they can see your in transit hash, but every time you logged in it would be different. reversing it is pointless because it will not point to any know lookup.
Actual S-Tier: Use Slow Hashing in combination with encryption, with the encryption key in a hardware token, so the unencrypted hashes are encrypted at rest, which means that if an attacker gets the encrypted hashes, they need to break trough 2 layers of security, while also allowing you to upgrade the security of your stored encrypted hashes, or change the encryption key, without knowing the password itself.
Simple approach: Store in plaintext *Advanced* method: Storing a salted slow-hashed password encrypted with a key on a separate server with a different OS and application, requiring 3-factor-authentication from the CEO himself and 5 other persons to be unlocked and regenerate the key every 30 seconds, while the salt of the hash is on a hard drive buried 2 km below the earth and the hashing algorithm itself is programmed differently for every single password.
i find the idea quite humorous, that there may be some guy out there, who made sure to use only randomly generated high security passwords, but the hash happens to be the same as "12345"
Awesome work, thanks for that clarifications! It's insanely easy to understand using this video. Will suggest everyone who needs to understand how it works.
I called S tier ahead of time. There's also peppering, which I've heard sounds useful, but is not recommended because it only adds another possible point of vulnerability for too little security benefit. There's also a "magic link" login, where you provide your email, and the site sends an email to that address with a special, temporary login link.
Me personally, 3rd party authentication goes below F-Tier, since that alienates a huge portion of a potential userbase. _Especially if you use Facebook and _*_especially if that is your only 3rd party authenticator._*
Another way to not need a password is a private key (either a file on you disk or a ubikey). Especially for ssh the recommendation is to not use a password, but just a private key
another S-Tier would be to verify via E-Mail. We have stored the E-Mails, so authentication via E-Mail could be done. This would require the hacker to breach the database of the E-Mail Service Providers (Proton Mail, Outlook, Gmail, etc.) or even private E-Mail Servers. Though most likely there are other issues, probably because if a hacker has access to the database, he might just take over the E-Mail Server sending those verifications...
Ultimately, this "login ticket" or "magic link" approach is equivalent to the "Sign in with Google" that the video describes as S tier. Its weakness is loss of access to the email account, such as when a student graduates, an employee changes jobs, or an ISP subscriber moves.
@@DamianYerrick Not equivalent, you can own your email server but you probably can’t own google. A backup email approaches has been used for years and you can also update your email.
Really amazing video! It's so clear that everyone could understand it, but still gives the intendend information. Congratulations! New susbscriber gained ;)
one question. for the encryption method can you not store it on a database not connected to the password database and the manualy let someone type in the decribtion key once then copy and paste it for every login? dont sounds like there is way to automate this whitout hacker getting acces to the key but deos the manual method work? sounds like iits a good method if your site only has a small amount of people logging in. only confirming logins in waves also sounds faster because of copy and past. after loggin people in the person would then clear the clipboard. how would this method rank on this list?
Third-party auth is selfish and socially dangerous. It helps you avoid liability, but makes your users reliant on the third party, who is usually a predatory, data-mining super-corp. This increases the global leverage of that entity, and also increases the cost to the user if their account with that entity is compromised, since the one breach automatically extends to all of the places that entity auths for. Moreover, it means that a general breach at the authorizing entity allows the attacker to enter your service on behalf of the users of that service, even if they don't have an account with you.
Just left a similar but much more poorly worded comment in the same vein. I don't think it's the absolute worst choice to delegate to a third party (theoretically more resources to dedicate to a secure password) but I don't understand why the video doesn't address its obvious security flaws.
That last one doesn't mean more secure. It just means when it happens you can say it's not your fault. And that's fine but because you have no clue how they're storing passwords you also have no clue if it's more secure than something else you could be doing.
You should look into augmented password-authenticated key exchange (PAKE) , one of the older examples (with some support in various libraries, but unfortunately not in web browsers) is TLS SRP. More modern alternatives are AuCPace and OPAQUE. It has additional safety and security guarantees.
The problem is some people don't use Google and some people don't use Facebook, making this not work for everyone. In fact you might say that these two things, these two platforms, are vulnerabilities in and of themselves, which means while you're protecting your own product, you're exposing your customers to attack by forcing them to use these.
This is the best video on password security I have seen! One question though: What is the problem mentioned at 4:00? How does does this compromise passwords?
@@cube2fox Listening more closely to what the video and talking about, and doing a bit of googling, I see I was actually wrong. It seems that actually it just generates two things that have the same hash, rather than generating one string that has the same hash as an input string. So, as for the problem mentioned at 4:00, I don't think this helps to compromise passwords.
You're right, it demonstrates generating a collision, rather than generating an input that has the same hash as another given input. I didn't cover this because it was a little too detailed, but generating an input with the same hash as another input is called a second preimage attack. In general, the community should move away from hash functions as soon as an algorithm is found that can generate collisions, even if it still works for passwords (i.e even if it still can resist a second preimage attack, like MD5). It's better to use a more robust algorithm. In the same sense, it's best to throw away a lock whose bolt is halfway cut.
I think there is one aspect that hasn't been considered in this video. Where should the hashing take place? Most implementations seem to do it on the server but my intuition would say that the client would be more secure. Attackers having access to your database is a common threat, but such an attacker might also have access to your servers and might install a virus, that then leaks the plain text passwords before they ever reach your database. An attacker might then try that password to gain access to a bunch of other services.
I think, if you do it that way an attacker only need to send the hashed password as it is in the database, it will work because it will not be hashed server side, no ?
I know you know but I just wanna say that MD5 still has it's uses, namely just to give unique IDs to media without relying on a random integer which is much more likely to collide, or an incrementing integer which would allow users to possibly access private data easily by just guessing numbers.
Wait, doesn't that „sign with “ only shifts the problem to ? They might be big tech, but they're not gods, their security is not perfect either. So if someone breaks in , they gain access to as well. And probably not only yours, but everywhere, where it's used. „But they're more secure. 2FA and so on.“ OK, so…why don't you do that as well?
Big tech might not be god, but their security budget is absolutely divine compared to what you can pony up. And yes, it does make a difference, you do not have the money to hire security experts Google has on payroll.
Great video, I think an addon to third-party auth which I see a lot lately is OTPs via phones, I think it's definitely the way forward if we're talking about S tier user authentication
Great explanation. What I don't follow is this: how can there be billions of guesses per second if most modern websites will lock your account after 3-5 unsuccessful attempts?
This ignores the transportation of passwords, perhaps it's a topic by itself... but as storing public keys is an option transportation of authentication data is in scope.
4:42 if the hacker has access to the credentials database then they surely have access to the actual data that's protected by the password and don't need the password in the first place...
I was wondering, wouldn't it be possible to "store" a password in a fast hash, sha512 for example, but to make it more resistant against brute-forcing store the hash of the hash? It would cost way less time to calculate the hash, and be virtually impossible to reverse the hash, right?
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.
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...
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*
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
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).
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....
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.
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.
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
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.
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!
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....
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.
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.
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.
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.
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
The benefit of password hashing isn't dependent on the collision or secondary preimage resistance of the algorithm. As far as I'm aware, both of those algorithms are still highly resistant to being inverted.
@@zirconiumdiamond1416 you mean second-preimage resistance. obviously normal preimage resistance *is* relevant to password hashing.
Without salting they can attack the whole database at once. The weakest will surely break. With salting they need to attack each user separately.
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.
G Tier is to "open source" the password database contents in plaintext.
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
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.
Truth be told, this is your best video yet. Awesome stuff and very well articulated.
ظمك
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).
I really wouldn't sleep better at night knowing I have created a single point of failure for every login I have
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.
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.
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
Also: peppering, client-side certificates, or certain protocols that doesn't ever send the user's password to your server.
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
Such a professional explanation and excellent articulation, how doesn't this have more views??
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?
@@MassimoRough 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 :)
@@MassimoRough 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.
This video is pure gold, always come back to it when want a recap on do's and don'ts in password storing. Thank you Alex
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!
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...
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.
this video is really really good, i like how you slowly go up the ranks explaining the problem(s) with the previous one, the only problem i see with this video is the S tier shouldve just been 2fa
love the summary at the end! This was so good
Sign in with facebook... NEVER , EVER do this, and so as any services associated with social media. It's not about their credential security, but the possibility that your account can be destroyed completely by "violating community guideline", and result in complete loss of all other accounts that rely on that platform. You don't want to have everything ruined just because you said one single word against the platform's politicla alignment right?
That color mixing analogy for hashing is genius. I'm going to use that from now on
this is probably the first time I've understood what salting actually does, bravo
I'm just watching the video, respect and interest the channel is rising from the informative and well-made video...
"You can use other authentication services..."
and my respect goes lower than the Earth's mantle.
Crystal clear and to the point explaination in a minimal time.Great work!
CS Student here! I liked the video very much because it allows you to understand what is real life password managing without the heavy/complex theory it carries behind! A smooth way to be introduced in the subject. congrats bro
i really like the yellow & dark grey video design. not too bright at night and not too dark in daylight. nice choice.
S tier: ”Let someone else deal with the problem”!
Not sure I would call that S tier since now you don’t really have control over the security.
You forgot peppering! It's A+C or B+C. Meaning they must both have the asymmetric encryption key and they must break the salted password once decrypted.
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
Hey man are you planning on making a part 3 of Equity Compensation & Taxes? I found it really useful actually and I'd love to see the 3rd video on it
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
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!!
If you don't mind, could you tell me the name of the course, please?
Amazing video, you really explain this topic well, using this iterative method of "problem -> solution -> problem -> solution ->..."
Love how S tier is just making it someone else’s problem
lmao
I just really enjoyed the effort and method of communication on the topic. 5 -Stars
You can also get creative with the salting process.
Something I did for a personal project was to get the salt by just hashing the username, and then based on the sum of the base 10 digits in the hash of the salt, the hash itself would be inserted after the SUM'th digit in the password string (looping over if SUM > password_digits), and then hashing it all over again.
I also used sha512 for this.
It's really not much better than just regular hashing if this algorithm is known to the attacker, but if it's not (and it shouldn't be known lol), then this essentially requires brute force to crack it, because it's a salt technique without a db-stored salt ;)
Is there a reason you didn't mention peppering?
That's quite an important technique, as it renders dictionary attacks completely useless, even with really bad passwords.
Hash, Salt, and now Pepper?
What are we making?
@@Known_as_The_Ghost Good soup. Alphabet soup.
How does that Work?
@@kiyu3229 A practical use case of peppering would be the following:
First of all, you generate a random string (preferrably quite long). Then, your store that string securely somewhere (not in the database). Storing it in your .env file or wherever you store API keys might be an option. After you've done that, you append it to each new password BEFORE hashing and finally storing it in your db.
This way, even if the hacker knows your hashing function and all the salt values because your database has been compromised and has a lookup table with hashes for commonly used passwords, they can neither figure out what passwords your users were originally using nor which users use the same password.
However, it is extremely important that you also append the pepper value before hashing user inputs from login forms, as otherwise, the passwords will never match and nobody will be able to log in anymore. Thus, implementing this on a project where users have already signed up is difficult.
9:00 If a website only offered these two options for logging in, I would tell them to sod off and never register.
I know I'm two years late to complain about this, but there is nothing more inconvenient for logging on than logging in with a third party like google or facebook. Google constantly wants to inject itself into every part of your internet experience. Logging in to a service that uses a google acount logs you into the acount in the browser and other services, and starts syncing stuff. (The way this works changes all the time so good luck avoiding this kind of stuff). Also it mixes up acounts all the time (signing into your student mail and ending up on your personal mail with no way to end up on your student mail besides logging out of your personal mail.)
Unnecesary integration of services makes me unreasonably frustrated
7:56 kinda reminds me of lockpicking. Locks don't really prevent theft. Thieves can (theoretically) pick any lock given enough time/resources. But would it be worth it? The goal then of locks is to make it so that getting to your valuables won't be worth it to thieves.
Something like that at least
Also, put a version number on the user table for the encryption method used. It can just be a number you assign. That way if you have to change to a more secure method later, existing users can still log in with their existing passwords stored in the old method, and passwords can be automatically and discretely updated to the new method the next time the user logs in.
thanks for the simple explanation, I've heard of salting before but never knew what it meant. now it all completely makes sense!
Slow hashing especially for websites becomes a new attack vector, DoS
Really great video. Especially the cinematics!!
The preview of your video was 100% speculative, and yet 200% worth it.
Delegating passwords to big tech giants is not a secure option. Forget tier S
I think his notes were just a bit messy and he missed the crossbar of a fancy F
you can also protect in transit attacks with a one-time hash with a random string at the time of login called a pepper. it mixes well with salt. so if you accidentally connected to a wifi in the airport that was a hacker, they can see your in transit hash, but every time you logged in it would be different. reversing it is pointless because it will not point to any know lookup.
Huh... I did not know about slow hashing techniques!
Thanks for the video!
Your videos are awesome! I'm speedrunning your channel and I'm learning a lot, awesome content man! Subscribed!
Using third-party login however has privacy issues. As user, I avoid that option wherever possible.
I'm really impressed by the quality of this video! it's so thorough yet concise!
Actual S-Tier: Use Slow Hashing in combination with encryption, with the encryption key in a hardware token, so the unencrypted hashes are encrypted at rest, which means that if an attacker gets the encrypted hashes, they need to break trough 2 layers of security, while also allowing you to upgrade the security of your stored encrypted hashes, or change the encryption key, without knowing the password itself.
Simple approach: Store in plaintext
*Advanced* method: Storing a salted slow-hashed password encrypted with a key on a separate server with a different OS and application, requiring 3-factor-authentication from the CEO himself and 5 other persons to be unlocked and regenerate the key every 30 seconds, while the salt of the hash is on a hard drive buried 2 km below the earth and the hashing algorithm itself is programmed differently for every single password.
i find the idea quite humorous, that there may be some guy out there, who made sure to use only randomly generated high security passwords, but the hash happens to be the same as "12345"
Awesome work, thanks for that clarifications! It's insanely easy to understand using this video. Will suggest everyone who needs to understand how it works.
this was a very informative and aesthetically-pleasing video :)
I called S tier ahead of time.
There's also peppering, which I've heard sounds useful, but is not recommended because it only adds another possible point of vulnerability for too little security benefit.
There's also a "magic link" login, where you provide your email, and the site sends an email to that address with a special, temporary login link.
Me personally, 3rd party authentication goes below F-Tier, since that alienates a huge portion of a potential userbase. _Especially if you use Facebook and _*_especially if that is your only 3rd party authenticator._*
0:27 correct horse battery staple
It's xkcd reference!
My man, that S tier is giving the problem to another person. Reminds me of the log4j problem.
Another way to not need a password is a private key (either a file on you disk or a ubikey). Especially for ssh the recommendation is to not use a password, but just a private key
In HTTP, client-side certificates exist too, though they are rarely used.
Fun fact: a private key is effectively just a looooooooooooooooooooong ass password.
@@macethorns1168 But the difference is that it isn't stored on the server, hashed or otherwise.
Great video to watch as a refresher!
Great video! I wish you talked about passkeys (no password at all) in the S tier as well
another S-Tier would be to verify via E-Mail. We have stored the E-Mails, so authentication via E-Mail could be done. This would require the hacker to breach the database of the E-Mail Service Providers (Proton Mail, Outlook, Gmail, etc.) or even private E-Mail Servers.
Though most likely there are other issues, probably because if a hacker has access to the database, he might just take over the E-Mail Server sending those verifications...
Ultimately, this "login ticket" or "magic link" approach is equivalent to the "Sign in with Google" that the video describes as S tier. Its weakness is loss of access to the email account, such as when a student graduates, an employee changes jobs, or an ISP subscriber moves.
@@DamianYerrick Not equivalent, you can own your email server but you probably can’t own google. A backup email approaches has been used for years and you can also update your email.
Really amazing video! It's so clear that everyone could understand it, but still gives the intendend information. Congratulations! New susbscriber gained ;)
one question. for the encryption method can you not store it on a database not connected to the password database and the manualy let someone type in the decribtion key once then copy and paste it for every login? dont sounds like there is way to automate this whitout hacker getting acces to the key but deos the manual method work? sounds like iits a good method if your site only has a small amount of people logging in. only confirming logins in waves also sounds faster because of copy and past. after loggin people in the person would then clear the clipboard. how would this method rank on this list?
Your channel is very underrated, also you got my sub, I hope you will make more vids
Amazing explanation! You make the subject very easy to understand
This was a really good video, congrats!
Third-party auth is selfish and socially dangerous. It helps you avoid liability, but makes your users reliant on the third party, who is usually a predatory, data-mining super-corp. This increases the global leverage of that entity, and also increases the cost to the user if their account with that entity is compromised, since the one breach automatically extends to all of the places that entity auths for. Moreover, it means that a general breach at the authorizing entity allows the attacker to enter your service on behalf of the users of that service, even if they don't have an account with you.
Just left a similar but much more poorly worded comment in the same vein. I don't think it's the absolute worst choice to delegate to a third party (theoretically more resources to dedicate to a secure password) but I don't understand why the video doesn't address its obvious security flaws.
This is great! I'm relatively new to computer science and coding and you explained this so well!
That last one doesn't mean more secure. It just means when it happens you can say it's not your fault. And that's fine but because you have no clue how they're storing passwords you also have no clue if it's more secure than something else you could be doing.
"Third party authentication" mean ZERO privacy. If a user wants to use a site without any connection elsewhere, they can't.
You should look into augmented password-authenticated key exchange (PAKE) , one of the older examples (with some support in various libraries, but unfortunately not in web browsers) is TLS SRP. More modern alternatives are AuCPace and OPAQUE. It has additional safety and security guarantees.
The problem is some people don't use Google and some people don't use Facebook, making this not work for everyone. In fact you might say that these two things, these two platforms, are vulnerabilities in and of themselves, which means while you're protecting your own product, you're exposing your customers to attack by forcing them to use these.
If the salt is in the database with the hash how does this stop hackers from obtaining both values and using them for comparison? 5:42
I think the semi-A tier should be safe password validation & rate-limiting.
I was really expecting peppering to be mentioned in this video
This is the best video on password security I have seen!
One question though: What is the problem mentioned at 4:00? How does does this compromise passwords?
Rather than figure out the original password, you just need to figure out one that has the same output from the hash function.
@@Vaaaaadim So you feed a hash into that algorithm, and one second later you get a password with the same hash?
@@cube2fox Listening more closely to what the video and talking about, and doing a bit of googling, I see I was actually wrong.
It seems that actually it just generates two things that have the same hash, rather than generating one string that has the same hash as an input string.
So, as for the problem mentioned at 4:00, I don't think this helps to compromise passwords.
You're right, it demonstrates generating a collision, rather than generating an input that has the same hash as another given input. I didn't cover this because it was a little too detailed, but generating an input with the same hash as another input is called a second preimage attack. In general, the community should move away from hash functions as soon as an algorithm is found that can generate collisions, even if it still works for passwords (i.e even if it still can resist a second preimage attack, like MD5). It's better to use a more robust algorithm. In the same sense, it's best to throw away a lock whose bolt is halfway cut.
Congrats for being the best teacher on TH-cam
I think there is one aspect that hasn't been considered in this video. Where should the hashing take place? Most implementations seem to do it on the server but my intuition would say that the client would be more secure.
Attackers having access to your database is a common threat, but such an attacker might also have access to your servers and might install a virus, that then leaks the plain text passwords before they ever reach your database. An attacker might then try that password to gain access to a bunch of other services.
I think, if you do it that way an attacker only need to send the hashed password as it is in the database, it will work because it will not be hashed server side, no ?
What a perfect explanation. Thank you
Thank you for the effort put into this video. This is beautiful
Lololol! Amazing. This is my life right now. It's not even an exaggeration.
Very good, short and informative video
I know you know but I just wanna say that MD5 still has it's uses, namely just to give unique IDs to media without relying on a random integer which is much more likely to collide, or an incrementing integer which would allow users to possibly access private data easily by just guessing numbers.
Wait, doesn't that „sign with “ only shifts the problem to ? They might be big tech, but they're not gods, their security is not perfect either. So if someone breaks in , they gain access to as well. And probably not only yours, but everywhere, where it's used.
„But they're more secure. 2FA and so on.“ OK, so…why don't you do that as well?
Big tech might not be god, but their security budget is absolutely divine compared to what you can pony up. And yes, it does make a difference, you do not have the money to hire security experts Google has on payroll.
Fantastic video. Thanks for the hard work of putting this together
insanely good content, keep it up! very very very underrated
Great video, I think an addon to third-party auth which I see a lot lately is OTPs via phones, I think it's definitely the way forward if we're talking about S tier user authentication
Great explanation. What I don't follow is this: how can there be billions of guesses per second if most modern websites will lock your account after 3-5 unsuccessful attempts?
Because he's talking about if the database got leaked. The attacker can mess with the database locally on their system.
This ignores the transportation of passwords, perhaps it's a topic by itself... but as storing public keys is an option transportation of authentication data is in scope.
your videos are awesome. very well animated and explained.
Great content 👍 , subscribed. Please post more valuable contents like this. Thanks in advance
best video for understanding how hashing works !!
I love a Tier List as a teaching device.
4:42 if the hacker has access to the credentials database then they surely have access to the actual data that's protected by the password and don't need the password in the first place...
I was wondering, wouldn't it be possible to "store" a password in a fast hash, sha512 for example, but to make it more resistant against brute-forcing store the hash of the hash? It would cost way less time to calculate the hash, and be virtually impossible to reverse the hash, right?