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.
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.
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
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.
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.
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"
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.
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.
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*.
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!
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.
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.
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.
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.
Sha-algs aren't made for hashing passwords, you should use something that's 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
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.
@@tenxenu7730 The salt is not more secret than the hash itself, and SHA256 basically takes the same time to run on a 30 character passwords as a 2 character password You should just use a password hashing algorithm, not a generic hashing algorithm built for speed instead of security
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
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!
4:30 UUIDs are not crytographically random and should not be relied upon for salting (or other cryptographic functions like initialisation vectors, etc.)
"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.
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.
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!
"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 😂
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.
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.
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.
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.
"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."
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.
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.
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.
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.
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.
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?
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!
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.
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?
Great video really! I remember when I just started out programming and one of my first tasks was to write a small app with authentication. Man I was proud when I implemented that with salt and everything, my boss didn't give a shit and laughed at me naming that weird hash salt 😂 Now I earn 5 times what I used to earn there at a different company 👋
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
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
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.
This is such a dangerous video it skips on so much topics necessary for building a secure password login system. I agree if you only need passkeys building it on your own might be worth it, though passwords need a lot more care to be secure! And if you need to go into offering SAML or OIDC login it gets even more complicated... I honestly don't want to use any service built by this person... Sorry I value my account's security too much
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.
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
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
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.
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.
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?
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
@@arjentix The “raw password” is transport-encrypted anyway, so you don’t gain anything. You only add complexity to the client side (where and how do you store the salt?) and the server side (now needs a different kind of protection against time-based side-channel attacks).
@@RegrinderAlert yes, it's transport-encrypted, but you may need another security layer to protect user data from workers. You don't need to store salt on the client side, you just send it to the server. I didn't get the idea of the side channel attacks on the server side
@@arjentix It’s not another layer of security because it adds absolutely nothing unless your transport-encryption fails. And in that case you are compromised anyways - even using your approach. The server now expects a hash instead of a password - so what? If encryption failed the attacker just uses that to log into your victim’s account instead of a password. And what do you mean, “the client doesn’t need to store the salt”? Of course they do. “They just send the salt” - again, what do you mean? Also, what workers are you referring to? You seem to have a fundamental misunderstanding regarding the topic of password hashing.
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.
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.
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.
Why not just use an open source self-hosted authentication system like Ory Kratos? I don’t see how adding a dependency for this is bad seeing as they’d do a better job with security than almost all developers. Implementing everything perfectly to that degree would be a huge time investment for most companies to replicate in-house and often isn’t worth it
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.
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.
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
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.
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
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"
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.
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.
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*.
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!
Great criticism and great video
Totally agree - 1.5x speed is perfect for this video
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.
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.
Bro changed to neovim during the video and thought we won't notice.
oh no neovim...
Every piece of information is well explained and connected. I also love your approach to avoiding unnecessary complexity. Thank you for doing this.
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.
2 minutes in and we're running out of Tenor gifs on the entire internet
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.
Sha-algs aren't made for hashing passwords, you should use something that's 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
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.
@@tenxenu7730 The salt is not more secret than the hash itself, and SHA256 basically takes the same time to run on a 30 character passwords as a 2 character password
You should just use a password hashing algorithm, not a generic hashing algorithm built for speed instead of security
@@InwardRTMP in some ways it is. your users should be able to trust you with their passwords, so make sure you do it properly
At some point people have to realize we cannot optimize for factor X, X being idiots.
This was more or less the foundation of the original Internet. It created a very different type of social network compared to today's.
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 wish you talked about MFA in this video and implemented it.
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.)
loving the videos man keep it going! The cloud one was very nice
the adhd jumpcut gify meme editing really brings the topic home
Your content is so good! Please keep going ❤
"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.
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.
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!
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
"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 😂
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.
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.
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.
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.
"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."
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 🤝
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.
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.
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.
This is the comment on the opposing view, not trying to bash him but putting it in a way that gives a solution aswel.
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.
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.
Passkey method is my preferred as well. I use it whenever when I can with a physical device.
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?
JWTs shouldn’t be used for same-site auth.
Great job man, finally i understand how salting works
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!
Glad to see someone like me that likes all three: Kotlin, Asciidoc and Antora ❤
greatly structured video
You speak my heart bro....😢😢
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 😅
Amazing channel bro I love your video style and you presenting your code.
Passkey is using a password manager but making sure you can't ever type the password if needed
Do you have a video like this on two-factor authentication? I'd love to see how TOTP is implemented on the backend.
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 😵
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.
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?
Great video really! I remember when I just started out programming and one of my first tasks was to write a small app with authentication. Man I was proud when I implemented that with salt and everything, my boss didn't give a shit and laughed at me naming that weird hash salt 😂 Now I earn 5 times what I used to earn there at a different company 👋
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
My final project need multiple authentication with email that one assignment made me fail.
Great video! Congratulations!
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
Excellent video thank you!
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.
Really good stuff my guy ❤
Interesting point of view. Would you mind link the entire codebase? Thanks
This is such a dangerous video it skips on so much topics necessary for building a secure password login system.
I agree if you only need passkeys building it on your own might be worth it, though passwords need a lot more care to be secure!
And if you need to go into offering SAML or OIDC login it gets even more complicated...
I honestly don't want to use any service built by this person... Sorry I value my account's security too much
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.
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
Why not use a passwordless login link sent via email?
shout out to Facebook without them we would not have this great video
This is awesome thanks dude
This is what they call Gif-Based Learning
Why not use bcrypt?
Imagine moving 5000 apps from one auth service to another in less than 60 days
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
Really good video and information, thank you!
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
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.
Cool video my man, How did you find how to implement the passkey.. all i find is providers?
Official documentation and spec from the FIDO Alliance. Literally first Google result.
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.
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?
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
Is your code available in a repo? I can see the website is down.
The only thing that sounds simple in the concept of authentication is, nothing, not even its spelling is simple 😂
I feel like , simple otp confirmation with mobile/email is the best way to authenticate.
Any thoughts?
Could you explain to me how the front-end makes the register request regarding the password, do you pass the salt in it?
A salt is generated on the server and never leaves it (unless when a breach occurs).
Could you share the git repo so we can see the actual magic?
Is source code for the test website also available?
You can also use salt and hashing on the client side, so that raw password is never transmitted to the server
That’s horrible advice. Don’t do that.
@@RegrinderAlert can you elaborate please?
@@arjentix The “raw password” is transport-encrypted anyway, so you don’t gain anything. You only add complexity to the client side (where and how do you store the salt?) and the server side (now needs a different kind of protection against time-based side-channel attacks).
@@RegrinderAlert yes, it's transport-encrypted, but you may need another security layer to protect user data from workers.
You don't need to store salt on the client side, you just send it to the server.
I didn't get the idea of the side channel attacks on the server side
@@arjentix It’s not another layer of security because it adds absolutely nothing unless your transport-encryption fails.
And in that case you are compromised anyways - even using your approach. The server now expects a hash instead of a password - so what? If encryption failed the attacker just uses that to log into your victim’s account instead of a password.
And what do you mean, “the client doesn’t need to store the salt”? Of course they do.
“They just send the salt” - again, what do you mean?
Also, what workers are you referring to?
You seem to have a fundamental misunderstanding regarding the topic of password hashing.
Damn this is great, thank you
are you familiar with how biometrics can be implemented? enough to make a video? thank you.
Informative content
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.
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
very informative video
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.
That’s dumb since you can spoof whatever source address you want. Hardly a proof of anything.
looking forward to when you upgrade your home server
Auth is 100x harder when you have a web app AND a mobile app with a backend
Never trust 3rd party code. They have no obligations to you.
Haven't watched yet but the Firebase logo in the thumbnail is pretty funny.
Supabase is selfhostable though unlike firebase so they can't just turn you off if they don't like you
What’s so difficult about comparing a hashed password ?
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.
Excellent!
Why not just use an open source self-hosted authentication system like Ory Kratos? I don’t see how adding a dependency for this is bad seeing as they’d do a better job with security than almost all developers. Implementing everything perfectly to that degree would be a huge time investment for most companies to replicate in-house and often isn’t worth it
Note to anyone reading this: don't use Kratos, the documentation is a nightmare and it's a PITA to implement
Let's not forget GDPR :)
What should we look out for?
you are a genius