Boring stil sounds complicated. For a 15 minute video, you had to fast forward through MFA and didn’t even mention protection from repeated login attempts, keeping logs of every access, session expiration… It really is what happens when you roll your own auth, it’s hard to do everything right.

@mamneo2

Ай бұрын

Incroyable.

@salim5219

Ай бұрын

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.

"Auth is nightmare" ..proceeds to show how to build one💀

@monad_tcp

Ай бұрын

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

@VoltLover00

Ай бұрын

Proceeds to do it incorrectly you mean...

@itisabird

Ай бұрын

@@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.

@MrBoiks

Ай бұрын

@@VoltLover00 how so?

@okie9025

Ай бұрын

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

It should be noted that SHA256 and other SHA functions are not well suited for password hashing and storing because of the efficiency of attacks. Functions like Argon might be more adequate solutions.

@matt1988ish

Ай бұрын

bcrypt.

@segsfault

Ай бұрын

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.

@Mr_Yeah

Ай бұрын

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

@jan.tichavsky

Ай бұрын

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.

@brad1785

Ай бұрын

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

Bro changed to neovim during the video and thought we won't notice.

@geomorillo

Ай бұрын

oh no neovim...

I spent so much time on my first SaaS to understand that a boring authentication doesn’t mean it’s bad. Simple doesn’t mean bad either. Thanks for your video. It killed many of my concerns and I wish I had watched it a long time ago hahah

I started working as a programmer 45 years ago. I've been thru all jobs in the hierarchy, but now, I'm back at what I like the most : designing and programming solutions for the users. I really appreciated the video. I would really like to see the server code to handle the little demo you provided. I used your video in a presentation to the team/clients to explain why we do need more than a simple cleartext password, but don't need/want a big external framework. They still haven't approved the plan, but they commented that the video extract that I shown them were easy to understand.

best part about this video is the warning about OAuth and companies shutting you out... It's really important for devs to push back on business owners encouraging unhealthy levels of power to be given to few companies. simply cause ""but i want da google login"

@JayLooney

Ай бұрын

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.

Using a 3rd party does not make logging-in issues easier. Imagine if someone doesnt remember if they signed in with google or if they signed in with Facebook. So they do the wrong one and now they have two accounts on your site. And now that is your problem when they contact you and ask you why all of their stuff is gone.

If you gave this video the same energy (voice & tone I think I mean) that your "The cloud is over-engineered and overpriced (no music)" video, then this video would thrive way more. As some positive critic to your video here, is that you sound very tired, compared to the last one. However the content that the video convey is top notch. Great video either way! I learned tons!

@egoworks5611

Ай бұрын

Great criticism and great video

@sl554

Ай бұрын

Totally agree - 1.5x speed is perfect for this video

Also when implementing passkeys take the time to change some (quite bad) default parameters. Namely the platform and resident key parameters. The current standard requires passkeys to be resident keys, thus not requiring a username and allowing single click logins. This excludes hardware keys as they have limited storage (8 to 25 slots) for those keys. By setting resident keys to optional or encouraged you get best of both worlds, allowing passkey storage on device, password manager and security keys. The only drawback being programming in an optional username field.

Every piece of information is well explained and connected. I also love your approach to avoiding unnecessary complexity. Thank you for doing this.

Sha-algs aren't made for hashing passwords, you should use something that made for that, like argon2 or bcrpyt. Cracking a sha256 hash, while right now is unfeasable if salted, still makes you more vulnerable to wordlist attacks, as you can test more than 1.000.000x as many hashes per second compared to bcrypt

@tenxenu7730

Ай бұрын

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.

@alvesvaren

Ай бұрын

@@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

@RegrinderAlert

Ай бұрын

@@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.

2 minutes in and we're running out of Tenor gifs on the entire internet

This is a big topic to cover in this amount of time. It gives me an appreciation for what Django gives me out of the box. I know it isn’t right for every project, but it lets me focus on building differentiating features rather than building auth *again*.

At some point people have to realize we cannot optimize for factor X, X being idiots.

@yurisich

Ай бұрын

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

Your content is so good! Please keep going ❤

Thnx for this one Tom. I really did learn quite some things. I have always developed backend stuff so this was a good introduction on how to do auth. Keep up the good work!

Your vids are so professional and easily understandable, keep up the good work

4:30 UUIDs are not crytographically random and should not be relied upon for salting (or other cryptographic functions like initialisation vectors, etc.)

I use AWS Cognito with the built-in hosted UI as a default auth for my apps. I just need to implement a few endpoints (I have a template for this) to navigate to/from the hosted UI. It's great, I don't need to worry about MFA, social sign on, email verification, cost or the liability of leaking data. If AWS gets hacked, I'll be the least interesting product that's affected. Liability is also the main reason many companies choose to outsource authentication. Don't have to put out a press release if AWS/Auth0/Okta/etc is hacked, but you do if your own self-hosted database is.

loving the videos man keep it going! The cloud one was very nice

I love the demo website! Do you have the source code on github or something?

Secure remote password protocol (SRP) is a method I've been wanting to implement myself for some time now. An SRP based OAuth would be so neat in addition

i've been trying to figure out all of the stuff i need to consider when rolling my own auth, and all of the tutorials i would see would be language specific or a library or really just seems like it's skipping a step (i don't think any of the ones i've read/watched mentioned salting). thanks for the higher level overview. is there a link to the source of the site in the video? you have the site in the description but not the source. it would be really helpful for me getting my head around it. also just curious do you have a preference on how you store the authentication state on the client? a cookie with a uuid? a jwt?

@RegrinderAlert

Ай бұрын

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

"The checks will have to be tied together with the source in both the chip and software to block log output from being there" Something like that. You can always add logs to x86 or Arm after if you have that understanding. If they have added encryption and more things in their version that was added after and their software looks for that, that action of looking for those things to be there will be in the chip logs if you replace the chip with yours. You can make it tedious to do and add encryption everywhere and what not, but it is there on the other end looking. The core of the computer is run by Canada and any software can be run without the extra added bits. You will always be able to figure out what is missing in your chip and either remove the request or add what is being looked for. The purpose to adding a log and a signal to activate it is you can bypass any of these checks completely as it will be a signal activating that request and not any keyword requiring a system. "It is not tied to a system."

Great video! I always found it interesting that we even bother with passwords for the first example. If you're going to implement a password recovery, why not just send a unique token to the user's email rather than storing and verifying a password at all? It might be an extra step each time to go to your email, but it offloads the burden of password management to your email provider and removes extra code that you'd have to write in order to cover both password authentication and "forgot password" flows.

"I'm going to implement 3 types of authentication" 15 minute video + introduction and other video parts. Where was this when I was in uni 😂 great video! Also I think it's interesting that the (no music) video got more than 3x the views as the first one. Perhaps there was a psychological thing where people 1) thought the video must be good since it was worth reupload, or 2) the video creator must make good content because they responded to feedback. Not advocating it butttttttt could make more videos with a bit loud music and then make (no music) again. :P In any case the views on both are well deserved. Great content! Also also it is SO annoying when folks insist on using a f***ing sledge hammer for a tiny nail. These videos feel therapeutic in a way because of that 😂

Passkey implementation so tough bro had to switch to nvim and JavaScript 😂 Nice content btw... Auth definitely is a headache all the time. What do you think abour solutions like NextAuth or Clerk?

Glad to see someone like me that likes all three: Kotlin, Asciidoc and Antora ❤

looking forward to when you upgrade your home server

There is technically a fourth way that someone can prove who they are. they can be someWHERE. its actually one of the more common, tho least acknowledged methods. How often does a firewall reject traffic from anything other than some set of provided IP addresses? Those are implicitly this fourth methodology. Its actually really cool.

@RegrinderAlert

Ай бұрын

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

the adhd jumpcut gify meme editing really brings the topic home

Great video, I've been getting into this in the past several months and it's super nice to have it all laid out like this. Would you be able to share a sanitized copy of the code to this demo website?

I really like password authentification the best, my password manager is already secured with a hardware key, and then just passing my secure generated password is the most comfortable.

what about magic link authentication? the user only provides an email and a token for authentication is sent to the user email address (in the form of a link). The user is authenticated after clicking the link.

Amazing channel bro I love your video style and you presenting your code.

POV: When you can't decide between authentication or authorization. : AUTH

For my current project, up until now I’ve decided to use only codes received from SMS/email for authentication. At the expected scale of 1k+ users it’s going to cost a pretty penny, but I think it’s worth not having to worry about storing passwords.

I use pocketbase for some of my side projects. A Firebase like service that you run yourself on a simple VPS. A part from the VPS costs it free. Quite happy using it!

@proharbiswas3056

Ай бұрын

it cant scale horizontally

@AlexVasiluta

Ай бұрын

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

@choleralul

Ай бұрын

@@proharbiswas3056 i have max 5 users so Im good

@odra873

Ай бұрын

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

Passkey method is my preferred as well. I use it whenever when I can with a physical device.

"Auth is a nightmare" ..proceeds with the clearest explanation ever.

Authentication is not that terrible when you have a user that needs to log in to do an action. I always find it much harder when its just system-to-system calls. Like how to manage and maintain it and how to decide if some other system should be allowed to do specific actions.

Do you have a video like this on two-factor authentication? I'd love to see how TOTP is implemented on the backend.

Passkey is using a password manager but making sure you can't ever type the password if needed

Most perfect answer is: Don't reinvent the wheel. Auth is just more than authentication. What about password resets, 2FA, etc. etc.? I like to refrain from third parties that I cannot host on my own due to privacy for my users. I like to build APIs using headless CMS systems that come with all that right out of the box, such as Directus.

The problem with passwords is the user. Most users use the same password everywhere which means their password is already known by 3rd parties. You are right the big companies are terrible to work with. Some governments are solving this problem by offering an authentication option. You already use your drivers license as ID in real life. In some places you can use it online.

greatly structured video

Any chance you could post the sourcecode used for the linked website? It would be very helpful for devs looking to roll this out on their own, as per your recommendations. Thanks for the great video.

I wish you talked about MFA in this video and implemented it.

I feel like , simple otp confirmation with mobile/email is the best way to authenticate. Any thoughts?

Haven't watched yet but the Firebase logo in the thumbnail is pretty funny.

My final project need multiple authentication with email that one assignment made me fail.

Really good video and information, thank you!

I have a lot tp say about this content because is top tier... But i need to sleep first :^) (3am) You got me man! Ty 🤝

Interesting point of view. Would you mind link the entire codebase? Thanks

Really good stuff my guy ❤

Great video! Congratulations!

The problem with auth is that the issues are never simple things like which hashing algorithm you use, where/if you store passwords, do you use JWTs or opaque tokens, etc. The problems are always hidden in the cracks inbetween, AKA your own code. The reason why most people use 3rd party auth handlers like Firebase Auth is not because it's too much of a hassle to setup your own password auth + oauth flow (it really isn't), but because Firebase is simply more secure. The client SDK automatically rotates refresh tokens and throttles auth actions, the admin ADK automatically provides rate limiting, password resets, one-time logins, MFA, oauth, etc. If you are really scared of vendor lock-on or Firebase getting killed by Google, you can always run a self-hosted Supabase instance, or if you just need auth and nothing else, Keycloak.

@ndzumamalate

Ай бұрын

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

Excellent video thank you!

Cool video my man, How did you find how to implement the passkey.. all i find is providers?

@RegrinderAlert

Ай бұрын

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

Nice and relevant topic for me. I watched it on my home theatre system and there was no plosive filter so the “p”s hit me hard through the subwoofer 😵

Great job man, finally i understand how salting works

@Bigjunior987

Ай бұрын

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!

It's rather simple if you think about it in basic terms. And not so hard to write a working one. The biggest problem is overcomplication and library/module bloat

Why not use a passwordless login link sent via email?

A big security advise is to hash the password at the client, before sending it to the backend, that will ensure that the data being transported doesn’t expose the user input and applying a backend unique seed to rehash will be a O1 operation that ensures every password check takes the same time and process to avoid timing attacks.

@RegrinderAlert

Ай бұрын

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.

@teamgartz-motorsports6881

25 күн бұрын

@@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.

@RegrinderAlert

24 күн бұрын

@@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.

@teamgartz-motorsports6881

24 күн бұрын

@@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.

I’ve been working on a project for my MC economy, and authentication was annoying but fairly easy to implement. Permissions, though, are beyond a nightmare, genuinely hate it, lol. Always do auth yourself, it just gives you more flexibility to implement what you want, how you want it. I *was* going to implement my user-credential login via the OAuth2 user-credential flow (same-site only), but, OAuth2 compliant is … a lot of work, and boring docs to read 😅

I actually contemplated integrating OAuth into my project as well but after this video I feel like there may be a giant risk coming along with that due to the project being a bit... problematic in its nature.

Can you share the rep? I would love to share this solution with my OOP students. They are first year, and it is really hard to find such compreenshive content.

wow thanks for the content so helpfull for me (i'm just dont like to make any auth and never make any auth 😂) but i will try, thanks for the concept and the explanation

to me the hard part has not been the backend that much but handling auth state in the client. that can get really trivial the first times

Good to see you're trying to undo the years of cruft and unnecessary complexity of web development. Too many dependencies, pulling in a whole library like underscore to use a single function that could be quickly implemented within the project. Too quick to reach for a third party service, framework, or library.

Amazing video, good job.

"don't need Auth0, we can roll our own secure scalable authentication system" - proceeds to fail at password hashing 101 by using a fast hash and then claims that it is a good thing! This video is will lead to a major vulnerability.

This is awesome thanks dude

Never, and when I say never, I mean NEVER underestimate your users. N E V E R!

Could you explain to me how the front-end makes the register request regarding the password, do you pass the salt in it?

@RegrinderAlert

Ай бұрын

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

Is source code for the test website also available?

"auth is a nigthmare"-glirmply grlarp glezin

You speak my heart bro....😢😢

Oh man true, I used to reply on Laravel auth package, then I switched to nextjs and it was a nightmare to me, ended up cloning a ready next auth template

Excellent!

The argument on dependencies is a crucial one nowadays. Ever needed to debug issues related to push services like FCM or APNs? It's a fucking nightmare and Google/Apple don't give a flying fuck about your problems. We should collectively fight forced dependencies like this much more.

A little correction for 7:12, OAuth2 is not for authentication, it is for authorization. There is OIDC which is a superset for OAuth2, OIDC is responsible both for authentication and authorization.

Informative content

very informative video

Why not use bcrypt?

Could you share the git repo so we can see the actual magic?

Damn this is great, thank you

are you familiar with how biometrics can be implemented? enough to make a video? thank you.

Why not magic links? I.e. Email a link with a cookie. I don’t see any real downsides with it compared to password tbh

Supabase is selfhostable though unlike firebase so they can't just turn you off if they don't like you

This video does a great job explaining the concepts of how auth works, but if you’re building anything of consequence, you absolutely should use a proper auth provider. They provided a ton of additional features that you’re missing here. Impossible travel, bot detection, suspicious ip, new device check, locking users, JWT, refresh tokens, session timeouts, user roles and permissions, and more. You could build that all, but most of those are simple toggles you turn on or off in the auth provider settings. Not to mention that they have been battle tested over the years, and so will be more secure than anything you would likely custom build. I do like the video as it does a great job explaining how a lot of the auth process works, but I cringe thinking about real companies rolling their own auth

shout out to Facebook without them we would not have this great video

Imagine moving 5000 apps from one auth service to another in less than 60 days

Ngl oauth2 and its pseudo standards (read about it) is probably why many choose a service, it wasnt really set in stone nor was it clear enough to be a proper standard. Has that changed would be my main question here ngl

great content

Sorry but this is just a bad take. Yeah setting up a hashing on the password is easier than supabase or auth0 or clerk. But then how do you save the session? How do you properly encrypt it? How do you make sure there are no clrf or other attacks in between. Refreshing tokens? Machine to machine?. Yeah doing ONLY this is easier than setting up supabase, but that is also only 10% of the problem for the same work. Where I can add supabase and have all that 🤷

What’s so difficult about comparing a hashed password ?

@dealloc

Ай бұрын

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.

you are a genius

Can’t you just use keycloak, then you need to implement only oauth in a keycloak-compatible way. Keycloak can connect to nearly everything, supports diverse forms of 2FA all out of the box. Yes it brings its own complexity but I find it is manageable and you don’t have to deal with all the finicky details yourself.

@dorcohen3522

Ай бұрын

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