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.
@TheHronar7 ай бұрын
bcrypt.
@segsfault7 ай бұрын
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_Yeah7 ай бұрын
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.tichavsky7 ай бұрын
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.
@brad17857 ай бұрын
@@jan.tichavsky maybe, but it's not difficult to use a hashing function designed for passwords
@rickdg7 ай бұрын
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.
@mamneo27 ай бұрын
Incroyable.
@salim52197 ай бұрын
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.
@eltee_dev7 ай бұрын
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
@blipojones21147 ай бұрын
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"
@JayLooney7 ай бұрын
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.
@mbeware7 ай бұрын
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.
@shaunkruger7 ай бұрын
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*.
@aka.theos.7 ай бұрын
Bro changed to neovim during the video and thought we won't notice.
@geomorillo7 ай бұрын
oh no neovim...
@zuighemdanmaar7527 ай бұрын
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.
@_vr7 ай бұрын
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!
@egoworks56117 ай бұрын
Great criticism and great video
@sl5547 ай бұрын
Totally agree - 1.5x speed is perfect for this video
@_modiX7 ай бұрын
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.
@DavidAlsh7 ай бұрын
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.
@thefrub7 ай бұрын
2 minutes in and we're running out of Tenor gifs on the entire internet
@Digo-eu7 ай бұрын
Every piece of information is well explained and connected. I also love your approach to avoiding unnecessary complexity. Thank you for doing this.
@DemiImp7 ай бұрын
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.
@alvesvaren7 ай бұрын
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
@tenxenu77307 ай бұрын
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.
@alvesvaren7 ай бұрын
@@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
@RegrinderAlert7 ай бұрын
@@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.
@alvesvaren4 ай бұрын
@@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
@alvesvaren4 ай бұрын
@@InwardRTMP in some ways it is. your users should be able to trust you with their passwords, so make sure you do it properly
@mjddev7 ай бұрын
4:30 UUIDs are not crytographically random and should not be relied upon for salting (or other cryptographic functions like initialisation vectors, etc.)
@Stalgicmusic7 ай бұрын
I wish you talked about MFA in this video and implemented it.
@draadhaai7 ай бұрын
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!
@yeahaddigirl7 ай бұрын
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
@asemyamak39847 ай бұрын
loving the videos man keep it going! The cloud one was very nice
@NastyWicked7 ай бұрын
the adhd jumpcut gify meme editing really brings the topic home
@NilsBarrZeilon7 ай бұрын
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.
@foobars38167 ай бұрын
"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.
@Tracing00297 ай бұрын
Your vids are so professional and easily understandable, keep up the good work
@eltee_dev7 ай бұрын
Your content is so good! Please keep going ❤
@owlmostdead94927 ай бұрын
At some point people have to realize we cannot optimize for factor X, X being idiots.
@yurisich7 ай бұрын
This was more or less the foundation of the original Internet. It created a very different type of social network compared to today's.
@Growlizing7 ай бұрын
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.
@unpatitoRU7 ай бұрын
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 🤝
@choleralul7 ай бұрын
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!
@proharbiswas30567 ай бұрын
it cant scale horizontally
@AlexVasiluta7 ай бұрын
@@proharbiswas3056you will most likely not need all that scaling, though.
@choleralul7 ай бұрын
@@proharbiswas3056 i have max 5 users so Im good
@odra8737 ай бұрын
@@proharbiswas3056your 0 user side project doesn’t need any scaling at all
@Damariobros7 ай бұрын
Do you have a video like this on two-factor authentication? I'd love to see how TOTP is implemented on the backend.
@mx3387 ай бұрын
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.
@Wurstfinger-rl1zi6 ай бұрын
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.
@prathamshrestha15427 ай бұрын
My final project need multiple authentication with email that one assignment made me fail.
@edhahaz7 ай бұрын
Passkey is using a password manager but making sure you can't ever type the password if needed
@svaponi7 ай бұрын
Interesting point of view. Would you mind link the entire codebase? Thanks
@snorman19117 ай бұрын
Why not use a passwordless login link sent via email?
@doublej427 ай бұрын
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.
@derismekentz17 ай бұрын
Amazing channel bro I love your video style and you presenting your code.
@JulianLopez-nd9ts7 ай бұрын
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.
@tibicsoki4577 ай бұрын
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.
@fillipefeitosa43317 ай бұрын
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.
@ItsNateY3K7 ай бұрын
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?
@RegrinderAlert7 ай бұрын
JWTs shouldn’t be used for same-site auth.
@spotlightsrule7 ай бұрын
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.
@z1_shivam7 ай бұрын
You speak my heart bro....😢😢
@davidcalloway90627 ай бұрын
Why not use bcrypt?
@Panacea97 ай бұрын
"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."
@Umweltliteratur7 ай бұрын
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.
@apshinyn7 ай бұрын
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?
@jervi_sir7 ай бұрын
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
@JulianHarris7 ай бұрын
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 😵
@Dawo-bq4nf7 ай бұрын
Great job man, finally i understand how salting works
@Bigjunior9877 ай бұрын
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!
@tonytins7 ай бұрын
Passkey method is my preferred as well. I use it whenever when I can with a physical device.
@okie90257 ай бұрын
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.
@ndzumamalate7 ай бұрын
This is the comment on the opposing view, not trying to bash him but putting it in a way that gives a solution aswel.
@alexwolfeboy7 ай бұрын
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 😅
@dxgamer54807 ай бұрын
Could you share the git repo so we can see the actual magic?
@projectpiano52317 ай бұрын
"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 😂
@MichaelStaalOlsen5 ай бұрын
Is your code available in a repo? I can see the website is down.
@NextLevelNoob7 ай бұрын
greatly structured video
@Ma1ne23 ай бұрын
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 👋
@tofix1127 ай бұрын
Is source code for the test website also available?
@felixengelbrektsson22697 ай бұрын
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
@KJCurtis65957 ай бұрын
are you familiar with how biometrics can be implemented? enough to make a video? thank you.
@giuliopimenoff7 ай бұрын
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
@JonathanRose247 ай бұрын
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
@teamgartz-motorsports68817 ай бұрын
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.
@RegrinderAlert7 ай бұрын
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-motorsports68817 ай бұрын
@@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.
@RegrinderAlert7 ай бұрын
@@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-motorsports68817 ай бұрын
@@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.
@2u841r24 күн бұрын
15:17 link not working
@RemotHuman7 ай бұрын
Supabase is selfhostable though unlike firebase so they can't just turn you off if they don't like you
@supriyomonndal61997 ай бұрын
I feel like , simple otp confirmation with mobile/email is the best way to authenticate. Any thoughts?
@JoseSouza-nc2yg7 ай бұрын
Could you explain to me how the front-end makes the register request regarding the password, do you pass the salt in it?
@RegrinderAlert7 ай бұрын
A salt is generated on the server and never leaves it (unless when a breach occurs).
@mudi2000a7 ай бұрын
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.
@dorcohen35227 ай бұрын
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
@IvanKleshnin7 ай бұрын
4:50 have you really proposed to store salt in the same place as password? 🤯 It adds no security whatsoever in such case.
@RegrinderAlert7 ай бұрын
Of course it does. You miss the point of salts all together 😂
@IvanKleshnin7 ай бұрын
@@RegrinderAlert if salt value(s) are leaked with passwords - all password are compromised. And if they are stored in the same table - they will leak together. What is not clear about this?
@RegrinderAlert7 ай бұрын
@@IvanKleshnin They are not. Because only the password hashes are stored.
@theSlavenIvanov7 ай бұрын
Great video! Congratulations!
@Toleich7 ай бұрын
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.
@AdowTatep7 ай бұрын
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 🤷
@borkborkbork7 ай бұрын
Really good stuff my guy ❤
@Daniel-do2mh7 ай бұрын
Really good video and information, thank you!
@mitch7w6 ай бұрын
Excellent video thank you!
@doyouwantsli96807 ай бұрын
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
@a3147 ай бұрын
Glad to see someone like me that likes all three: Kotlin, Asciidoc and Antora ❤
@karlstenator7 ай бұрын
Can has video on magic links auth? 🐱🍔
@WolfElectronicS4 ай бұрын
This is what they call Gif-Based Learning
@ThisNameNowTakenIs7 ай бұрын
Cool video my man, How did you find how to implement the passkey.. all i find is providers?
@RegrinderAlert7 ай бұрын
Official documentation and spec from the FIDO Alliance. Literally first Google result.
@grootspook7 ай бұрын
This is awesome thanks dude
@leetkhan7 ай бұрын
What’s so difficult about comparing a hashed password ?
@dealloc7 ай бұрын
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.
@abtuly6 ай бұрын
shout out to Facebook without them we would not have this great video
@vikingthedude7 ай бұрын
I love the demo website! Do you have the source code on github or something?
@moveonvillain10807 ай бұрын
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?
@ryval45947 ай бұрын
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
@arjentix7 ай бұрын
You can also use salt and hashing on the client side, so that raw password is never transmitted to the server
@RegrinderAlert7 ай бұрын
That’s horrible advice. Don’t do that.
@arjentix7 ай бұрын
@@RegrinderAlert can you elaborate please?
@RegrinderAlert7 ай бұрын
@@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).
@arjentix7 ай бұрын
@@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
@RegrinderAlert7 ай бұрын
@@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.
@Daniel-i8v2i6 ай бұрын
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
@Daniel-i8v2i5 ай бұрын
Note to anyone reading this: don't use Kratos, the documentation is a nightmare and it's a PITA to implement
@Cooliofamily7 ай бұрын
Imagine moving 5000 apps from one auth service to another in less than 60 days
@2u841r24 күн бұрын
10:57 From whom? what?
@matthewcarter16247 ай бұрын
Damn this is great, thank you
@Bigjunior9877 ай бұрын
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
@kylekurzhal7 ай бұрын
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.
@orterves7 ай бұрын
Have a look at Ory self-hosted
@6099x7 ай бұрын
They’re hosted service is also pretty good if you eventually don’t want to self host anymore
@knkootbaoat67597 ай бұрын
looking forward to when you upgrade your home server
@NazimLeulmi7 ай бұрын
Informative content
@clementdato63287 ай бұрын
The only thing that sounds simple in the concept of authentication is, nothing, not even its spelling is simple 😂
@steamer2k3197 ай бұрын
Haven't watched yet but the Firebase logo in the thumbnail is pretty funny.