Authentication is a developer nightmare 

Incroyable.

This is a bit simplified, you need logs and need some more logic for multiple login attempts, but there aren't very many websites that require MFA and I don't think you need it for a small project.

actually building your own oauth server is the easiest and safest way of doing it.

Proceeds to do it incorrectly you mean...

@@VoltLover00 Here we have a prototypical StackOverflow user: saying that everything is wrong without saying why and how to do it right. People like you are the reason why sites like SO are dying: nobody wants to interact with you anymore.

@@VoltLover00 how so?

@@monad_tcp incorrect. The safest bet is almost always to use Keycloak or an auth provider.

bcrypt.

Also this is because a password hashing algo should include some work factor which would slow down dictionary or rainbow-table attacks, If Argon2 isn't available then PBKDF2, Scrypt or Bcrypt should be used instead.

Which is why you shouldn't implement such things yourself (like in the video) but use existing implementations. For example, PostgreSQL has pgcrypto for hashing passwords

last time I checked SHA256 was still secure without known vulnerabilities. You are more likely to get hacked by security bug in your software package or have the user exploited by social hacking rather than cracking the hash.

​@@jan.tichavsky maybe, but it's not difficult to use a hashing function designed for passwords

oh no neovim...

If you're just using them as an Auth Provider (authn) it's not necessarily a big deal if they shut you out as you could just switch auth providers or even have a small "roll your own version" like this video on standby just waiting for the day the primary auth provider fails. -- It becomes a big problem if you're depending entirely on a third party to perform as your Identity Provider (authz) because then they have all of your account data, all of your permissions configuration, etc. -- And getting cut off from that is extremely problematic and not really recoverable unless you're maintaining a complete replicated system on-prem.

Great criticism and great video

Totally agree - 1.5x speed is perfect for this video

Are you suggesting that it’s unfeasible right now due to hardware limitations but that in the future salted and hashed passwords can be easily cracked by just guessing BOTH the pw and the salt? I would just generate a 30+ char salt and hash it with the pw and keep increasing the salt char limit as hardware limits grow. If a bad actor wants access to my stuff THAT bad id rather waste his time and resources trying to unhash that than point their attention to easy targets.

@@tenxenu7730 Well there's no reason not to use a hashing function made for passwords. But as the salt is stored in the database, it doesn't help agains wordlist attacks or just brute force attacks at all (only protects against rainbow tables basically). You can test millions of password combinations per second with SHA256, while only hundreds per second of bcrypt

@@tenxenu7730The salt is stored (and therefore leaked) together with the password hashes. So increasing the salt length does absolutely nothing. You are missing the whole point of password hash functions and the attack scenario they try to mitigate.

This was more or less the foundation of the original Internet. It created a very different type of social network compared to today's.

JWTs shouldn’t be used for same-site auth.

That’s dumb since you can spoof whatever source address you want. Hardly a proof of anything.

it cant scale horizontally

​@@proharbiswas3056you will most likely not need all that scaling, though.

@@proharbiswas3056 i have max 5 users so Im good

@@proharbiswas3056your 0 user side project doesn’t need any scaling at all

Official documentation and spec from the FIDO Alliance. Literally first Google result.

This is the comment on the opposing view, not trying to bash him but putting it in a way that gives a solution aswel.

Hope you keep on reading on which hashing algorithm to use (e.g. not SHA-256 but something like bcrypt), secure password recovery flows (not as done here) with timeouts, add password/account change notifications, require reauthentication for critical account actions (like deletion, password change, changing the email), implement confirmation emails when the email is changed, have good password policies (requiring passwords longer than 12 chars, don't require special characters but instead encourage users via a strength meter that takes into account various factors a good password, check passwords against commonly breached passwords and block those, ensure unicode characters are supported, you implemented rate limiting, soft lockouts, IP-adresse based rules such as sudden location changes, ensure no cross site request forgery attacks are possible and much much more! Password login is NOT easy, understanding how salting works does not qualify you to build your own login system. It's a start and an important one, but please keep digging and understanding what else you need to do to build a secure authentication system!

That’s horrible advice. You gain absolutely nothing (transport encryption exists) and lose the ability to use salts. And the pepper (you call it seed) can’t exist for the exact same reason - so your approach doesn’t work either.

@@RegrinderAlert do a SHA256 over whatever was typed, then send that value in your post or whatever protocol is used. At the backend you get the value, use a salt + encrypted value then encrypt again and then store in the database. Do the same process to check. The value transported size and checking time and complexity are constants regardless of the size or characters that the user used. There are many kinds of attacks being covered here. Don’t say it’s a bad advice just because you don’t understand it, ask for more details when you can’t figure out. Btw, salt is a random value that is not secret, and seed is random value that is secret.

@@teamgartz-motorsports6881 There is no point or added security whatsoever to nesting encryption like that. And assuming a breach, better assume your encryption key for that database content is compromised as well. Then you are back to having no advantage over best practise. You are just making yourself vulnerable to timing attacks so please stop doing this. You have no clue what you are doing. It’s not bad advice, it’s horrible advice. Let us researchers bother with the question of “what’s a best practise?” instead of being arrogant and thinking you can do it better by adding extra steps with no concern for fundamentals. And btw, no, seed doesn’t necessarily mean what you are claiming. It’s highly depending on context.

@@RegrinderAlert well I hope you learn before working with security implementation, as clearly you would store clear text because if anything can be compromised anywhere why not just go for it. Transporting data encrypted is always better than plain. Or do you also disable HTTPS in your security advices? Do you also would not recommend JWT? Anyway you do you. But I admit that I’m curious how in your mind processing unpredicted size plain text passwords is safer against timing attacks in comparison with fixed size string/binary comparison. Btw, you can assume whatever you want, seed or salt are not technical definitions just loosely commonly used word conventions, that’s why it depends on the context and makes your petty word fixation fruitless.

A salt is generated on the server and never leaves it (unless when a breach occurs).

Sidechannel attacks, phishing, breaches, compromised networks, human errors.. are just _some_ methods that can be used to extract password. The point is not about comparison, the point is everything around it that makes them less secure.

Ofc he can, but he would rather coming with ridiculous home cooked solutions that open your system to a battery of attacks. He has 0 experience with live systems and it's glaring across all of his video