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.
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.
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.
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....
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.
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.
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
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.
@@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
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.
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
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
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.
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.
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.
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.
Wow... So S tier is just give the passwords away for free? Centralizing data is *never* a good idea! It just makes it more convenient to access that data. The more distributed the data is, the harder it gets to access all of it.
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.
Outsourcing authorization has a ... couple of issues. Firstly, it depends on both you and your users trusting the third party. Secondly, if the third party source relies on one of the other methods, you've just moved the problem, not solved it. And thirdly it means that if someone DOES crack your third party password, now they've got access to your accounts on a whole host of systems. The true S tier is 2FA, where logging in requires you to both know something (usually a password) and to HAVE something (usually an authenticator, but it could be something biometric like fingerprints or retinal scans). 2FA also almost automatically comes with a third party auth system, because 2FA is difficult enough that unless you're dealing with national security level data/access it's better to let a company that specializes in exactly that do it for you.
2fa doesnt solve the problem stated in the video. it just adds another layer of security for logging in. it doesnt prevent the attacker from cracking the password, and use it on another site to login with the same email (where you dont have 2fa enabled/forced). and totp (time based on time password) (google authenticator) has the same problem as a password. the server has to store the totp secret (which is basically the "password" for generating the 2fa code). the better 2fa solution is to use a hardware key.
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.
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
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.
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
Really amazing video! It's so clear that everyone could understand it, but still gives the intendend information. Congratulations! New susbscriber gained ;)
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?
You didnt discuss peppering, which adds a "hidden salt" to the hash which isn't stored in the database - it is simply added to all the passwords. This works at the same time as a salt, so it definitely bumps it up a tier.
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.
Old video but for what it is worth things haven't changed much. I agree data that you don't have is data you cannot leak, but putting that off to a third party you have no control over isn't a great idea either. Just in general a limiting 3rd party dependencies should be a target. The S tier should be multi-step authentication. The old phrase was something you know, something you are, something you have, pick two (or more). Know is a passphrase/code or answering a security question. You are is biometrics: fingerprint, eyescan, face rec, ... You have is something like a key card, nfc on a phone, text or email to separate service. For secure systems, I prefer user certs. The private key is the thing you have and you encrypt them with a personal passphrase. Server side we only ever have the public key. If that gets leaked, it doesn't matter, it is public information.
Another one that could come under S tier "Magic-link" or email authentication. You simply send a one time code or link to the users email address that they used to sign up, and they enter/click that to log in. Many services already do this along side passwords and call it the "forgot password" button. Why have the extra attack vector of a password in the first place then? Just use the link all the time.
I built such a system in the 2010s for a web store; we called the email message containing a code a "login ticket". Its help page explained that customers could use it either as a password with login ticket backup or as a login ticket with password backup. You still need to give the account some sort of password to allow recovery when the customer loses access to their email account, such as when the customer graduates (losing school email), changes jobs (losing work email), or moves (losing ISP email), or when the customer's email provider puts the server's IP address on a spam blocklist.
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 like TOTP single-factor for login without storing passwords. If the user can't choose what their secret is, they can't give me a secret that I shouldn't have. If you have a slow enough rate-limit, there's nearly no chance of someone guessing a code.
Really nice video and explanation. What about mutual authentication with certificates? That doesn't need passwords neither. And MFA? It is another good alternative. For the hashing + salt, I would say that the attacker could read the salt an preappend it to the hash, resulting in the same second case encrypted
There is actually a different S tier (appart from not storing the password) and that is buy combining the slow hash functions with salt AND peper, which is a single random character that is appended, which differs each time and is not stored anywhere.
I came down here to see if anyone had mentioned using a pepper, but this was not the definition of a pepper that I was expecting. The pepper is generally a relatively long string (sometimes unique per entry, sometimes global) that's stored separately from the passwords (either in the source code, or sometimes in a hardware module), which requires an attacker get access to two separate systems. I did look it up and you're not wrong that a definition for an un-stored random character for a pepper that needs to be re-discovered each time exists... I really couldn't figure out the benefit, it seems like it's just a multiplier on the work factor? (as you'd have to run a hash each time until you re-discover the correct value?) But just increasing the work factor would achieve the same thing... It could be argued that this adds some level of pseudo randomness to the hash matching speed to help defend against timing attacks, but most good hashing functions defend against that anyway.
@zapspeed I agree its a bit odd. I think its a more low tech solution to increase resilience against brute-force. I can also be more resistant to potential (yet to be discovered) weaknesses in the hashing algo... but is a bit far fetched.
3:44 Can't say I've ever heard the term "Collision Resistance" before. Most of the time when this concept is being talked about, I hear it called the avalanche effect. Not a criticism, mind you, just quite new to me is all.
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.
Just imagine a world where people had internet ID, the same way they have any other real-world ID. My goodness, it's so simple to solve this problem it makes my eyes bleed.
I have a broad question. Aren’t most or nearly all hacking attacks the result of the user being careless or sloppy with their security or falling for something like a phishing attack? I’d like to hear this topic explored.
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?
outsourcing authentication is not the bees knees. you're not in control, and if they get hacked--and they're a bigger target--you may find yourself powerless to do anything, even after the fact.
God tier security is sitting at home, 8 hours a day, comparing input passwords from users with their original password. You never store them digitally, ever, just remember them in your mind and letting people in if they gave you the right password. A human bouncer to your website. Literally unhackable. /s
You forgot SSS tier, manual slow hash, all passwords are stored on a physical piece of paper and a real person has to check the sign in attempt manually against the paper
The very first database app I wrote as a kid used hashing and salting. Glad I was following a good tutorial. Though iirc the password was hashed, then salt was added to the hash, then it was hashed again.
Im no database expert but is there a reason you couldn't do the hash by including the email/username? Preventing rainbow tables and the need to even store emails? The only problem would be that the company couldn't send you account specific info ?
I am sorry if this is a dumb question, but say the hacker has access to the database, wouldn't he also have acess to the salt values so salting wouldn't make a difference because he could just append the salt value to all of his passwords on his list and still be able to bruteforce the password? (edit: this comment was meant for just salting + hashing not slow hashing)
There is also the zero-knowledge proof system where the users prove that they know the password without sending it. However, the weakest link is user-generated password.
Imho third party authentication destroys de user experience. If by any chance they get hacked your site may be exposed by a mistake you didnt make. What about if the third party loses the login service or if they shut down for maintainance or by mistake? You depend heavily on another company.
i wonder why is it not possible to randomly generate a salt for each user when they attempt to log in? like yes you generate the first salt when the user creates the account but couldnt you then generate a new random salt depending on how many times the user logged in? but probably this would also have some back door cause could read at which iteration we at aka how many times the person logged in
What about using a private key / public key algorithm where the public key is computed from the private key, and the private key is the result of a slow salted hash. This would have the benefit that even at login, the password and private key wouldn't even have to leave the user's device.
Wouldn't physical keys like those pen drives with decryption keys be considered S tier? Since the only way to acquire the password would be retrieving all the data from the pendrive or stealing it?
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
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.
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.
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....
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.
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
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.
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
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.
I really wouldn't sleep better at night knowing I have created a single point of failure for every login I have
Truth be told, this is your best video yet. Awesome stuff and very well articulated.
ظمك
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
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
Crystal clear and to the point explaination in a minimal time.Great work!
love the summary at the end! This was so good
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.
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
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
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?
@@knownas2017 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.
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
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.
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.
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.
Wow... So S tier is just give the passwords away for free? Centralizing data is *never* a good idea! It just makes it more convenient to access that data. The more distributed the data is, the harder it gets to access all of it.
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.
thanks for the simple explanation, I've heard of salting before but never knew what it meant. now it all completely makes sense!
I like the services that instead of storing a password just send you an email with a link in it every time you want to login.
Maybe S tier is passwordless method . Thanks for great work 🎉
just watch two more minutes and delete your comment
I got fed up with all these complicated storing methods i couldnt remember so I ended up getting a full body tattoo like that guy from Prison break
My man, that S tier is giving the problem to another person. Reminds me of the log4j problem.
Outsourcing authorization has a ... couple of issues. Firstly, it depends on both you and your users trusting the third party. Secondly, if the third party source relies on one of the other methods, you've just moved the problem, not solved it. And thirdly it means that if someone DOES crack your third party password, now they've got access to your accounts on a whole host of systems. The true S tier is 2FA, where logging in requires you to both know something (usually a password) and to HAVE something (usually an authenticator, but it could be something biometric like fingerprints or retinal scans). 2FA also almost automatically comes with a third party auth system, because 2FA is difficult enough that unless you're dealing with national security level data/access it's better to let a company that specializes in exactly that do it for you.
Facts fact facts facts.
2fa doesnt solve the problem stated in the video. it just adds another layer of security for logging in. it doesnt prevent the attacker from cracking the password, and use it on another site to login with the same email (where you dont have 2fa enabled/forced).
and totp (time based on time password) (google authenticator) has the same problem as a password. the server has to store the totp secret (which is basically the "password" for generating the 2fa code).
the better 2fa solution is to use a hardware key.
Correct horse battery staple...great xkcd reference!!!
Lololol! Amazing. This is my life right now. It's not even an exaggeration.
The modern problems with OAuth/SSO/federated logins makes S tier look hilarious in hindsight
this was a very informative and aesthetically-pleasing video :)
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.
best video for understanding how hashing works !!
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
I'm really impressed by the quality of this video! it's so thorough yet concise!
This was a really good video, congrats!
S+ teir: scatter the password information onto 35 monoliths spanning the globe.
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.
salting, but the salt is the nickname ran through the hash function, and then you encrypt the whole database with the word minecraft
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
I was really expecting peppering to be mentioned in this video
Mike Pound is proud of you
Really amazing video! It's so clear that everyone could understand it, but still gives the intendend information. Congratulations! New susbscriber gained ;)
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?
Awesome video and very clear explanation
You didnt discuss peppering, which adds a "hidden salt" to the hash which isn't stored in the database - it is simply added to all the passwords. This works at the same time as a salt, so it definitely bumps it up a tier.
Now that passkey is a thing, we finallx reached S tier
Loved that xkcd reference
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.
Thank you for the effort put into this video. This is beautiful
I love a Tier List as a teaching device.
Old video but for what it is worth things haven't changed much. I agree data that you don't have is data you cannot leak, but putting that off to a third party you have no control over isn't a great idea either. Just in general a limiting 3rd party dependencies should be a target.
The S tier should be multi-step authentication. The old phrase was something you know, something you are, something you have, pick two (or more). Know is a passphrase/code or answering a security question. You are is biometrics: fingerprint, eyescan, face rec, ... You have is something like a key card, nfc on a phone, text or email to separate service.
For secure systems, I prefer user certs. The private key is the thing you have and you encrypt them with a personal passphrase. Server side we only ever have the public key. If that gets leaked, it doesn't matter, it is public information.
S tier do be a trick question, because while as a software dev you offload the work to Google, Google still runs into the same problem 🗿
Another one that could come under S tier "Magic-link" or email authentication. You simply send a one time code or link to the users email address that they used to sign up, and they enter/click that to log in. Many services already do this along side passwords and call it the "forgot password" button. Why have the extra attack vector of a password in the first place then? Just use the link all the time.
I built such a system in the 2010s for a web store; we called the email message containing a code a "login ticket". Its help page explained that customers could use it either as a password with login ticket backup or as a login ticket with password backup. You still need to give the account some sort of password to allow recovery when the customer loses access to their email account, such as when the customer graduates (losing school email), changes jobs (losing work email), or moves (losing ISP email), or when the customer's email provider puts the server's IP address on a spam blocklist.
Cool video straight to the point and informative :)
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 ?
Totally saw the last one coming.
I like TOTP single-factor for login without storing passwords. If the user can't choose what their secret is, they can't give me a secret that I shouldn't have. If you have a slow enough rate-limit, there's nearly no chance of someone guessing a code.
Really nice video and explanation.
What about mutual authentication with certificates? That doesn't need passwords neither. And MFA? It is another good alternative.
For the hashing + salt, I would say that the attacker could read the salt an preappend it to the hash, resulting in the same second case encrypted
There is actually a different S tier (appart from not storing the password) and that is buy combining the slow hash functions with salt AND peper, which is a single random character that is appended, which differs each time and is not stored anywhere.
I came down here to see if anyone had mentioned using a pepper, but this was not the definition of a pepper that I was expecting.
The pepper is generally a relatively long string (sometimes unique per entry, sometimes global) that's stored separately from the passwords (either in the source code, or sometimes in a hardware module), which requires an attacker get access to two separate systems.
I did look it up and you're not wrong that a definition for an un-stored random character for a pepper that needs to be re-discovered each time exists... I really couldn't figure out the benefit, it seems like it's just a multiplier on the work factor? (as you'd have to run a hash each time until you re-discover the correct value?) But just increasing the work factor would achieve the same thing...
It could be argued that this adds some level of pseudo randomness to the hash matching speed to help defend against timing attacks, but most good hashing functions defend against that anyway.
@zapspeed I agree its a bit odd. I think its a more low tech solution to increase resilience against brute-force. I can also be more resistant to potential (yet to be discovered) weaknesses in the hashing algo... but is a bit far fetched.
Very informative. Thank you
3:44 Can't say I've ever heard the term "Collision Resistance" before. Most of the time when this concept is being talked about, I hear it called the avalanche effect. Not a criticism, mind you, just quite new to me is all.
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.
S-tier: make it somebody else's problem. I like it!
Thanks for sharing knowledge 💫
Just imagine a world where people had internet ID, the same way they have any other real-world ID. My goodness, it's so simple to solve this problem it makes my eyes bleed.
you never store salts in the same database, you stire it in a secure storage , usually a system of their own.
I have a broad question. Aren’t most or nearly all hacking attacks the result of the user being careless or sloppy with their security or falling for something like a phishing attack? I’d like to hear this topic explored.
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?
outsourcing authentication is not the bees knees. you're not in control, and if they get hacked--and they're a bigger target--you may find yourself powerless to do anything, even after the fact.
God tier security is sitting at home, 8 hours a day, comparing input passwords from users with their original password. You never store them digitally, ever, just remember them in your mind and letting people in if they gave you the right password. A human bouncer to your website. Literally unhackable. /s
S+ Tier: don't build any applications
S++ Tier: don't use computers
S+++ Tier: don't live
You forgot SSS tier, manual slow hash, all passwords are stored on a physical piece of paper and a real person has to check the sign in attempt manually against the paper
Tornado says hi
Thank you for a clear explanaition
SRP aka secure remote password is an option if you want oauth level security without oauth providers.
Awesome explanation🎉🎉
Perfect, great work.
So, in A tier, you make your login page slow on purpose so that potential attackers won't be able to brute-force. Seems like a compromise solution.
The very first database app I wrote as a kid used hashing and salting. Glad I was following a good tutorial. Though iirc the password was hashed, then salt was added to the hash, then it was hashed again.
What if you just encrypt the password WITH the password and salt
Im no database expert but is there a reason you couldn't do the hash by including the email/username? Preventing rainbow tables and the need to even store emails? The only problem would be that the company couldn't send you account specific info ?
I am sorry if this is a dumb question, but say the hacker has access to the database, wouldn't he also have acess to the salt values so salting wouldn't make a difference because he could just append the salt value to all of his passwords on his list and still be able to bruteforce the password? (edit: this comment was meant for just salting + hashing not slow hashing)
Yes, but it's way harder
There is also the zero-knowledge proof system where the users prove that they know the password without sending it. However, the weakest link is user-generated password.
from my experience of using hashes, sometimes they can be decrypted sometimes they cannot
Imho third party authentication destroys de user experience.
If by any chance they get hacked your site may be exposed by a mistake you didnt make.
What about if the third party loses the login service or if they shut down for maintainance or by mistake? You depend heavily on another company.
thank you very much, very helpful
Correct horse battery staple, baby
i wonder why is it not possible to randomly generate a salt for each user when they attempt to log in? like yes you generate the first salt when the user creates the account but couldnt you then generate a new random salt depending on how many times the user logged in? but probably this would also have some back door cause could read at which iteration we at aka how many times the person logged in
What stops hackers from just grabbing the entire raw table, and decrypting it on their end in their leisure?
Number One Option is just to use codes (but it only works for statistics)
very informative.. thank you sir!
So good. Great job
fantastic video..loved it
What about using a private key / public key algorithm where the public key is computed from the private key, and the private key is the result of a slow salted hash. This would have the benefit that even at login, the password and private key wouldn't even have to leave the user's device.
Those exist, though I don't remember the name.
Like SSH?
Wouldn't physical keys like those pen drives with decryption keys be considered S tier? Since the only way to acquire the password would be retrieving all the data from the pendrive or stealing it?