Password Storage Tier List: encryption, hashing, salting, bcrypt, and beyond
ฝัง
- เผยแพร่เมื่อ 4 มิ.ย. 2024
- If you're building an app or product, you need to store your users' passwords securely. There's terrible ways to do it, like storing them in plaintext or encrypting them, slightly better ways like hashing or hashing and salting, and even better ways like bcrypt, scrypt, or argon.
Sources:
gist.github.com/epixoip/a83d3...
github.com/corkami/collisions...
00:00 Intro
00:26 F Tier: Plaintext
00:55 D Tier: Encryption
01:50 C Tier: Hashing
05:22 B Tier: Hashing + Salting
06:55 A Tier: Slow Hashing
08:45 S Tier: Don't Store Passwords
09:18 Recap
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
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...
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.
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
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.
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.
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
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
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....
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).
Truth be told, this is your best video yet. Awesome stuff and very well articulated.
ظمك
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.
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 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!
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?
@@MaksMikhnevych from my point of view it clearly articulates that his hard work produced an excellent video, hence, the view count shouldn't be representative of it's quality. Sorry if it came off as otherwise. My comment got a heart though... so I think it's probably fine :)
Computerphile previously did the same thing. Look up "how not to store passwords." I think they have more views.
Every comment boosts this vid on the algorithm so we are all helping him here :)
@@MaksMikhnevych Not sharing this video on social media might have the same cause as not being able to use S tier authentication: a user might not even have an account on social media.
Love how S tier is just making it someone else’s problem
lmao
I really wouldn't sleep better at night knowing I have created a single point of failure for every login I have
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
Crystal clear and to the point explaination in a minimal time.Great work!
love the summary at the end! This was so good
Technical nitpick: rainbow tables are a method of using less storage for your pre-computed hashes, they can be used with dictionaries with permutations if you choose your reduction function well. But a database of dictionary word: hash pairs is not a rainbow table.
Your videos are awesome! I'm speedrunning your channel and I'm learning a lot, awesome content man! Subscribed!
i really like the yellow & dark grey video design. not too bright at night and not too dark in daylight. nice choice.
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
this is probably the first time I've understood what salting actually does, bravo
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
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.
thanks for the simple explanation, I've heard of salting before but never knew what it meant. now it all completely makes sense!
That color mixing analogy for hashing is genius. I'm going to use that from now on
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'm really impressed by the quality of this video! it's so thorough yet concise!
Really amazing video! It's so clear that everyone could understand it, but still gives the intendend information. Congratulations! New susbscriber gained ;)
Thank you for the effort put into this video. This is beautiful
Fantastic video. Thanks for the hard work of putting this together
Amazing explanation! You make the subject very easy to understand
Great video to watch as a refresher!
This is great! I'm relatively new to computer science and coding and you explained this so well!
Amazing video, you really explain this topic well, using this iterative method of "problem -> solution -> problem -> solution ->..."
your videos are awesome. very well animated and explained.
this was a very informative and aesthetically-pleasing video :)
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 ;)
insanely good content, keep it up! very very very underrated
What a perfect explanation. Thank you
Very good, short and informative video
Awesome video and very clear explanation
You earned a sub. This is educational and digestible!
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.
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
This was a really good video, congrats!
Really good video dude. Thank you
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?
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.
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.
Extremely useful, thanks!
Thank you for a clear explanaition
The preview of your video was 100% speculative, and yet 200% worth it.
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?
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.
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.
Awesome explanation🎉🎉
Thanks a lot for your time to teaching us
Very informative. Thanks!
best video for understanding how hashing works !!
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.
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.
Your channel is very underrated, also you got my sub, I hope you will make more vids
Cool video straight to the point and informative :)
Perfect, great work.
Great video! I have a little question. How good and/or secure are the authentication apps on second devices, for example, the google authentication app that generates a new 6-number code every few seconds?
very Informative and simple to understand.
Very informative. Thank you
Thanks for sharing knowledge 💫
very informative.. thank you sir!
Thank you, I've learned really important information 🙂
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.
Great video!
So good. Great job
Perfect like usual
Thank you this was reaally good stuff.
Great content 👍 , subscribed. Please post more valuable contents like this. Thanks in advance
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._*
Using third-party login however has privacy issues. As user, I avoid that option wherever possible.
This was an amazing video
Congrats for being the best teacher on TH-cam
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
Thanks! Well explained differences.
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.
Thank you for sharing knowledge
Great video! I wish you talked about passkeys (no password at all) in the S tier as well
Thank you for the video, it is really helpful and informative in my learning! May I ask...where would you classify Tiger hash function under [Apart from all the hash functions stated in your video], and why will you classify it as such?
Tiger is a hash function. This makes Tiger by itself C tier. Tiger with salt is B tier. Tiger stretched with PBKDF2 is A tier.
extremely helpful❤
thank you very much, very helpful
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
Awesome video