On 6:20 a hacker would still be able to check if a email belongs to a registered user by looking at the duration of the request. If a user with the email exists you run the action sendMagicLinkEmail which probably makes the request taking longer. This can be prevented by not waiting for this function to be finished or by adding a random, large enough time delay on every run.
Not true if the backend is using a queuing system. You can kick off a job to accept the provided email and in that request lifecycle the server knows nothing about the outcome. The same job is performed.
Once again... a web developer shows hes not a network administrator. There are four game breaking reasons why we DONT use email direct auth that would take to long for me to explain here, but DoS is the first, Spam Flagging/Bulk Mail BL denial, Unreliability of email transmission, as well as customers loss of email access..... need i go on... The concept was thought about 40 years ago... and thrown in the bin for very good reasons.
I absolutely hate this trend. Everyone uses (or should be using) a password manager these days. Now, I have to spend an extra 20 seconds waiting for the email, clicking the link, waiting for the site to load again, EVERY SINGLE TIME. My browser extension could've auto-filled my email and password and had me logged-in in a few seconds.
Totally agree. We have specific solutions for every kind of auth needs. And this one simply don't fit yours. Fortunately Kyle don't made that mistake of starting the subject like _"stop doing this..."_
I like it. I can wait 30 seconds and do something else. I prefer to give less sensitive data that is likely to get breached in the hands of poorly secured centralized companies, and this includes giving data to any cloud based password manager. This is also great for companies and allows them to spend more time and money perfecting their product instead of protecting user credentials against potential threats from internal employees or external hacks.
9:39 here also the method is called `verify` because it not just decodes the payload but also verifies the signature. In this case the secret is really needed because we must verify the authenticity of the data that is encoded in the payload, but the payload information again is available publicly, it's just base64 encoded string
I would like to see a tutorial on how to do a OTC email (one time code) for getting your email address verified, but honestly I really only prefer magic link auths as an option, not as a requirement!!
The main thing about this isn't the email bit. It is the 'magic token'. That token can come from anywhere. (e.g. a separate site, perhaps a hub for a family of sites, can generate and redirect to pass the magic string to the server.)
But it might confuse/annoy the users even more if they register for website X and recieve mails from website Z. It certainly would make me more suspicious and I'd suspect a phishing attempt and not click the link.
Is this really more secure? As far as I know, usually emails are not signed and encrypted which would make the sent mail prone to a man in the middle attack, isn‘t it? 🙂
But aren't the emails themselves unsecure? E-Mails sent via SMTP are not exactly encrypted. It should be relatively easy to start a man in the middle attack unless the Email is encrypted with something Like PGP, which ist not realistic. Or am I missing something Here?
@@jackknash you make a valid point. But not for email-only auth, but rather against token-based password reset emails. I get that they're the go-to these days, but email IS in fact painfully insecure Also, password resets are rare and the attack vector Blightning talks about is a man in the middle attack. If everyone logs in via email, you can farm account access to any and all active accounts within weeks
@@77dreimaldie0 my point as you said is that they're the go-to anyway, it just removes additional steps users need to do. Regardless if you're making something that requires security, you should always allow 2FA for your stuff if you require accounts being secure.
Email is a protocol based delivery system which means it’s not guaranteed. Even with 2 factor authentication one has the option of how your authenticated by means of phone, text, push notification and also email so if there’s an email issue you would just choose another authentication method but this has to be done behind a username:password combination otherwise how would one solve not being able to receive emails… call customer service.
Hello, how do you prevent somebody uses the login form to spam somebody elses email acount with thousands of emails ? I would keep password authentication along with email and in adition sending the token in email as a second level.
@@thepublicservices That can be an issue, but sites already require email verification for new accounts, password reset, new device login, and other sensitive actions. In every case, it makes sense to have some kind of security measure to either throttle or stop suspicious or unnecessary repeating the events.
The only thing I dislike about a magic link auth via email is that it is very inconvenient for the user, but it's viable once when the user is first signing up (mainly to verify the email). There's also the chance that someone's email gets compromised but there's not much we can do there.
Personally, I prefer to still enforce secure passwords with MFA layered on top. I just feel like this is a single layered security option, where as a password and MFA at least has two points. This is still a practical auth method, but still makes me uncomfortable.
Like others, I don't like the main trend here. But I never thought of using that secret key hashing system. One extra step to write that to fs turns that into a keygen script. Could use something like inquirer to make it customizable too.
I’ve been thinking about this, and replied on the video itself, but it could work with saving a temporary randomly generated code. Bound to nothing more than System.Random. Yes. It is still bound to time, but quite a bit more random than salted codes.
8:35 actually you don't need to pass the correct key. The JWT payload is a public information and this is actually one of the reasons why you should never ever ever store any private information in it. The possibility to pass the key there on the site is available for you to verify the signature, and also just in case you need to adjust payload for the development purposes.
why? it is only viable for a duration of the token and it is hashed. There are no tools to crack it now. May be in the future. These tokens are billions of times safer than any of the humans behavior in any case
I think it's really cool access only with email. I would like to validate only once or when it clears the section or cookies, so I don't have to go to the email every time I use my app. That is, it is the first time you access, validate the email, only ask for validation again if you clear the section or local cookies
@@TheHegi As always: It depends on the app and overall concept, but in general (i.e. with some exceptions) you are right about this being insecure. Exceptions were this might be sufficient are for example services with unsensitive data (e.g. some throwaway email service), services which provide access to data with a low lifespan (e.g. some image converter where a direct download link to the result is sent to the user) or services which are exclusively used on already approved devices (although I cannot think of an example for this one). Especially on the first two exceptions email based auth might be more secure as you prevent users from choosing a quick insecure password or reusing their standard password. I'm actually currently working on an app where this email only auth suffices the security considerations. For a more traditional use case of user accounts (e.g. social media, SaaS products, etc.) this of course is a pretty dumb idea and a huge security flaw. Web Dev Simplified totally missed on pointing this out (it seems to me this is due to lack of knowledge in this field).
I see a limitation to this workflow, namely the need to go to your mailbox each time you log on to the site. I dont think it's the best user experience.
This is probably the reason why i would not use it. Say you're at a friends house at their PC/Device. You want to casually log in. If you have an email address running on a webhoster and only have it setup to receive emails through your phone. You'd then need to copy the link to the friends device so you can click the link on that device. I like the idea, but it's bad practice when it comes to user experince. E.g. think of doing this kind of authentication with a netflix account. I would hate it as a user.
The better way would be to store the JWT against a random key and send the link with the key in the email. When users click the link, we can exchange the key to the JWT token and delete the key from the database. This way, we can avoid anyone looking at the logs / URL to replay the API and get the token.
@@TheHegi are you sure? This method does not contain a MFA layer. Where my email accounts do. Having this feature solely would mean that gaining access to any device with my email account logged will have the capability to login.
Why not combine both system? Once a user login with their email and password on a new device never used before, it'll send an email verification link (or code to paste). But when a user is trying to logging from a device that he already previously used to sign in before, no email link will be sent. That way he can use his password to authenticate on known devices, instead of doing way more action that are, login into the email account clicking on the email then click on the generated link. And if the hacker knows the account's password he would stil need to have access to the email because he will try to login from a new device.
I was thinking a better solution will be, to ask for password while registering, then while login in, their should an option of `user password` or login with only `email` which means if they forget there password it will be easy to login and if they still remember the password it will as well be okay
*"But when a user is trying to logging from a device that he already previously used to sign in "* Proper device detection is another great headache to add to a secure authentication system. The only things you can test on the server side are the user agent string of the browser, a "remember me" token you have set previously and maybe the IP address. IP checks are bad -> Proxies, dynamic ip address assignment to customer from ISP, DHCP in a LAN. User agent is bad - there are many plugins for all major browsers to manipulate those. Token is basically the same as the passwordless system described here, without the email part.
I thought this would be the one similar to microsoft auth where if you use no password option, it shows on screen 2 numbers like 30 and then on your phone you open microsoft auth, select right number and scan your fingerprint/write pin to confirm. I saw similar ideas even in banking and this is the one that I think is even better than email link, thou this option is way more accessible.
It's a very similar concept, the only difference is that instead of generating the hashes on microsoft server, they generate the hash (number) on the user's device which saves cost of sending email to millions of users. Now the attacker had to get the email and the number generator to actually breach it.
I guess my first thought would be a man in the middle issue. But there again it's the same for a forgotten password I guess. And I don't know enough to know the feasibility of that sort of thing now-a-days.
Some password-less websites don't email a link, but email a 6 digit code which you enter to confirm your login. I think that is a bit more professional than causing the customer to open three tabs/windows to login (login, email, authed). How can this be implemented instead? Seems like a more elegant solution in some cases and uses the same infrastructure to get it set up.
I disagree that this method is more secure than email/password. For example, access to a computer or phone with email client. As well as interception of a mail message with a "secret" token in the plain text.
I love the idea, thank you for this video! One disadvantage I immediately think of is users need a configured email client on the same device they want to authenticate on.
I use a password manager, so I login with Ctrl+V and don't memorize long complex passwords. Also Firefox has a master password and I'm not type anything.
The biggest problem with this method is that you have to make sure user receives your email. Many times you can get banned so easily or your mail can go to span folder. This is serious problem. Edit: we use sendgrid too. Still get blocked many times.
Well if you do email/password method you should still send a confirmation email, to avoid someone taking a email that does not belong to them, so the problem you're describing would still be present
@@musamutetwi1948 yeah but I mean you still depend of your emails arriving correctly for users to sign up, and about sign in, how many times do you re-signing on the sites? And If you have also Google Auth the user could still use Google to access to his account I think Magic Link + Social OAuth Providers are a safe combination It really annoy when you need to register on new sites that only accept email/password
11:26 This part is completely confusing as the key there is really just a random string, and it has nothing to do with how it's generated and which algorithm is used to generate it. There IS a difference only if other algorithm is used in JWT strategy as some of the algorithms that use async encryption method require public and private keys rather than just one secret key.
didnt this caused MAJOR security issues back in the day? when phishing scams asked for the url of your hotmail inbox? then they had a session active and access to your account
All of these things weaken security. I've started seeing magic links over SMS. Imagine getting a new phone number and forgetting that a handful of websites authenticated you via SMS only. Now, the new owner of your old phone number is the de-facto owner of your account. They don't even have to do anything illegal to get access, they already have the access without committing any crime, similar to you accidentally opening a misrouted envelope that accidentally ended up in your mailbox. Back in the day, you couldn't even use email to reset your password if you forgot it. People were whining that that led people to writing down their passwords on sticky notes, which was insecure. So they added the ability to reset your password via email. Now, your email is the linchpin to every single account. If your email gets hacked, it's all over. Tell me, how often does someone break into your house to collect password sticky notes, versus someone getting their email account hacked? Then they added biometrics. Great! Now you leave your fingerprint on the sensor of a personal device that authenticates you with your own fingerprint. Very secure. Finally, someone gets wise and starts suggesting one-time codes as a second factor of authentication... except of course those codes are mostly sent by SMS these days. Try logging into your 2-factor account via SMS when you're on vacation in the Caribbean, or somewhere in Europe, where you're having to rely on Google Voice just to get a phone call out. The text messages don't arrive in time. The voice calls are full of static and always cut out on one of the 6 digits. And then there's a limit on how many one-time codes you can request, with some sites locking you out for an hour or two after you get 5-ish codes resent. All of this lunacy has led to most people just staying signed-in to all of their accounts. Which is, of course, all fun and games until you leave to go to the bathroom in the coffee shop and come back to your MacBook being stolen. Did you remember to lock the screen? Are you sure the drive is encrypted? Passwords. Properly rotated passwords, with a time-generated 2FA OTP, are secure. If you can't remember your password, use an offline password manager. Everything else is dumb. Let's face it, the last 15 years' worth of changes to security around user authentication has, with the exception of time-based 2FA and password managers, been more about convenience and less about security. Staying signed in, password reset, security questions, magic links, biometrics, etc. These are all tools of user convenience, not security.
Future goals: You only need one set of credentials that is tied to you personally and not 3rd party like fb, ig, google, random services.. etc etc and is also decentralized. You can sign in or up with any services with your own credentials and all the data is kept with you. Im tired of remembering 100's of different credentials with each application requiring their own set of rules for passwords. Federated login is headed in the right direction but your data is still held with them and there are multiple providers still. Apple, Google, fb ...
Yeah but most people on YT don't show how to do that.... If you have any video explaining how to do that, please give me the name of the video :P I'm tired of those people on youtube saying they show you how to do something for free but then you get into the page they did, and yeah you see a PRICING PLAN payment montly.... which is already for me that vidoe was a BIG AD for that site to make people start using it and pay montly...
While many people point out valid weaknesses to this approach, I think we can improve on this. - Instead of sending email, we can provide authenticator app for users. Not only this reduces cost on sending emails. The attacker having the email is also not an issue anymore since the hash/number generator is on user's device. Pretty much like what is google, microsoft and twilio is doing. To actually breach it, the attacker must also have the user's device.
You have to have a really compelling web app to get users to install an extra auth app on their phone. Company wants to *save* money by having a simpler system, not spend more by developing an auth app. Pre made third party auth app is probably not usable because of security reasons. An open source auth app might be useable, but also costs more money because of the code audit you'd have to do with each new version before using it. At that point one could also ask why only the auth part is in an app and not the complete app?
You need to understand JWT first. (other tutorials, not this one) once you have that: he used a JWT token in the e-mail, so same rules apply. Last but not least: this is a horrible terrible idea for a lot of reasons. Don't try this. Anywhere...
I disagree with the database leakage part. Systems should never store authentication credentials in a database in a way it can be used if it's somehow breached. If it's hashed and encrypted correctly they can't do anything with the data they have acquired because it can't be reversed nor decrypted without a proper combinations of secret keys.
If you are encrypting passwords you are not much better than the system who store then in plain text. I'd argue that you're worse because you though about the problem and you think you solved it, but in reality you didn't. Now if you are salting and hashing passwords then you are on the right path :)
@@TheHegi I was more saying it in broadly speaking way with the whole data. Authentication data is always hashed and any other sensitive data that is required to be accessed by the end user can be encrypted by methods that are virtually impossible to crack. Apologies for my poor explanation.
Hey Kyle, I want to say something to you... Are you secretly looking into my brain? Anytime I think to learn something new, you post a video on that topic♥️
... This is just email-based 2FA, except without the first factor of a password, it's reduced to 1FA. Sure, it's more secure than just 1FA email-and-password verification, but it's less secure than actual 2FA that should be used.
@@TheHegi There's 200 comments, plus countless reply threads. Reading through about 20 of them, I see nothing about this except one other comment that says the same thing I did. Care to explain how this isn't just one factor of 2FA isolated?
hey thx for the video , even with this ,the link is still fragile to some attacks , theres a better way though , what if when the userregister , for him to verify his account he has to send a mail from his gmail account who he have registered with to our website email (for example lets say the user wants to register he send a mail in which he type register) and then from the website we check if an inverified user have sent an email containing register we verify him and all good
The actual authentication and generation of jwt should be done on the server, chrome extension can just act like a UI and send request to authenticate to your backend API
Thinking a bit further ahead from the users point of view: If all websites where to adopt this authentication system, your email account becomes your password manager. You're in deep trouble if the email account is compromised or you forget your password or your email provider deletes your account or closes up shop. Which requires you to do three things: 1) You really have to trust your email provider and the people that work there. Whoever has admin access at the email provider can log in at the service you are using, because they can access your stored emails. 2) So you set up multiple email accounts to prevent loosing everything at once. At that point all your passwords have migrated from the sevice you are using to the email provider. So you still need to memorize a password for every service via the email address. 3) This is the result of points 1 and 2. If you decide to use multiple emails - probably from differend email providers - you are increasing your risk because you increase the attack surface. Now you have to trust each provider as described in point 1. The point about data breaches at the used services because of insecure stored passwords is shifted to the email providers. From the users viewpoint it makes no difference. Most "hacks" are just successful phishing or social engineering attempts or a password stealing malware on the users system. The only good solution I can think of is to: - have the user choose a login name and provide an email address - never have the login name present in any email sent to the user - you have a really small time window where the magic token login link is valid But this still doesn't fully get rid of the email provider trust problem. The real benefits of this "passwordless" system are only for the service, not the user. It's easier to implement and it shifts the blame in case of a data breach to someone else.
@@TheHegi Yup. Everything about this is a bad idea. UX is bad, security is bad, depending on a third party is bad. Like I said, the only thing this is good for is to shift the blame to someone else in case of a data breach.
This is so annoying. I have multiple email accounts for multiple professional purposes and I divide them by profiles in Chrome. I do most of the work on a single profile so every time I need to login on a website that uses this bs I need to open another window, open my inbox, click the damn message, copy the link, close the window, and then paste on the profile I want to access in. Not to mention having to delete the email so it doesn't add up to the pile of trash. Typical of slack to try and reinvent the wheel.
@@trappedcat3615 true, in a third world country no one uses a bullcrap piece of technology anymore. Unless the internet is out of coverage or someone is using 2G which should not be the case.
Another incredibly awesome video! I have been retraining as a web developer for almost a year now, and you have frankly made it all much easier and saved my butt so many times!!! Thank you so much for all you are doing, you are by fav the best teacher I've come accross on here 🙏
One final thought: should sites really bother about password recovery? Or should the user have a list somewhere: text file, Outlook Notes, any auto fill password manager,...? Brick and mortar example: if I forgot where I parked my car I can't reasonably ask the owner of the parking lot to find it....If I lose my wallet or something else of value I'm the one to blame and fix it. Your solution is technically sound but your approach to security in this case is - IMHO - conceptually wrong...
Many crypto apps already use this method for quite some time now due to the number of hacks and scams, notably key loggers. But it's useless if your email was hacked. Make sure to enable 2FA on your gmail.
All of this is rendered useless if your email account password is password123 😂 Or maybe not. I may be overlooking something. Or am I ? I don't know. Ah yes, 2-factor authentication. God help anyone who has that turned off and is using password123 as their main email password though lol Beautifully explained for us all though Kyle. Quality Content. 👌
what is the correct way to save token on nextjs/frontend application. cookies? http-only cookies? or in session storage? please explain why. thank you ❤❤
I remembered doing similar thing using php last year. In my case, a section of our website is only used for internals. The script generates an hmac hash based on two strings (keys), no email or password required, it's very similar to what you've done with jwt and email. The only advantage is that an attacker would have no email and password to go by to hack into our internal unless they get the actual keys (the two strings which could be re-generated at any given moment) or the script which generates the keys.
Yep this type of auth insane and insecure. But Boomers love these email-only auth. Cuz they don't understand password managers and also they usually can't remember anything save their one email password from their 2003 yahoo email which had been in like 59 breaches...
How is this more secure than the email provider security… 😅 I feel like the email provider is now the one who needs to be secure or not and it’s not your application problem anymore…
really good method, I think for this to work well we need some email provider that is dedicated to this kind of thing. so no new fancy feature that brings bugs with, no nothing.
Hey Kyle can you please make a video on how like button or some other things work even though server is down in React.js, like when click on like button in Facebook when internet is down the like button works.
Which book can I use to learn web dev stuff like this? I'm a beginner with no knowledge. • Integration of analytics tools • Integration of CRM or marketing automation tools • An e-commerce platform • Multi-language support • Geolocation API integration • Social media integration • Cookie consent notification • Security features
You must learn the language first before looking into that, even if you had the books you will be completely lost since you wouldn't understand what is going on anyway. In this case learn JavaScript first.
You are totally wrong. This is absolutly not more secure. When you will loose access to your email account, you will also loose access to ALL your accounts.
this is garbage (sorry). Its not more secure and its a massive hassle that nobody is asking for. This was proposed to us (fortune 5 chief arch) and when we asked our members it was one of the most unpopular choices we've ever polled them on.
Shame this is even recommended. You'll run into plenty of problems within production environment, email unreliability is the biggest one. Want a bulletproof login system? Use OAuth and some form of identity provider. Auth0, or use Google APIs to access user information. This handles authorization, then use server-side sessions to handle the authentication if you opt to not use an IdP.
It's a shame this video exists. The damage is already done sadly. I am deeply disappointed in Kyle. He's great when it comes to FE, but he's dangerously short sighted in other areas it would seem. So sad.
Great video. Straightforward, no waffle, no stupid intro graphics.
Tks for sharing
On 6:20 a hacker would still be able to check if a email belongs to a registered user by looking at the duration of the request. If a user with the email exists you run the action sendMagicLinkEmail which probably makes the request taking longer. This can be prevented by not waiting for this function to be finished or by adding a random, large enough time delay on every run.
Again. DIY auth is bad
Not true if the backend is using a queuing system. You can kick off a job to accept the provided email and in that request lifecycle the server knows nothing about the outcome. The same job is performed.
Just queue emails
@@marktownsend7367 that doesn't fix the problem...
@@brazenbull36 doesn't fix the problem
Once again... a web developer shows hes not a network administrator. There are four game breaking reasons why we DONT use email direct auth that would take to long for me to explain here, but DoS is the first, Spam Flagging/Bulk Mail BL denial, Unreliability of email transmission, as well as customers loss of email access..... need i go on... The concept was thought about 40 years ago... and thrown in the bin for very good reasons.
Thank you!
Came here for this comment...
@i said maaayyybeee wouldn't this also apply if you forgot password and used account reset, but lost access to the recovery email?
Ooof somebody’s a grumpy network admin today aren’t they.
web devs aren't meant to be network admins.
I absolutely hate this trend. Everyone uses (or should be using) a password manager these days. Now, I have to spend an extra 20 seconds waiting for the email, clicking the link, waiting for the site to load again, EVERY SINGLE TIME. My browser extension could've auto-filled my email and password and had me logged-in in a few seconds.
Totally agree. We have specific solutions for every kind of auth needs. And this one simply don't fit yours. Fortunately Kyle don't made that mistake of starting the subject like _"stop doing this..."_
@@ed1nh0 your right
I like it. I can wait 30 seconds and do something else.
I prefer to give less sensitive data that is likely to get breached in the hands of poorly secured centralized companies, and this includes giving data to any cloud based password manager.
This is also great for companies and allows them to spend more time and money perfecting their product instead of protecting user credentials against potential threats from internal employees or external hacks.
Also, it costs send email every time you have to login
@@d13-s8b Is the cost greater than storing millions of user credentials, performing security audits, and potentially getting fined for a breach?
What about the cost of sending email every time a user log in?
To be fair this is just the password reset workflow, without the password.
2:05 - True. But Kyle said as much.
9:39 here also the method is called `verify` because it not just decodes the payload but also verifies the signature. In this case the secret is really needed because we must verify the authenticity of the data that is encoded in the payload, but the payload information again is available publicly, it's just base64 encoded string
I would like to see a tutorial on how to do a OTC email (one time code) for getting your email address verified, but honestly I really only prefer magic link auths as an option, not as a requirement!!
The main thing about this isn't the email bit. It is the 'magic token'. That token can come from anywhere. (e.g. a separate site, perhaps a hub for a family of sites, can generate and redirect to pass the magic string to the server.)
But it might confuse/annoy the users even more if they register for website X and recieve mails from website Z. It certainly would make me more suspicious and I'd suspect a phishing attempt and not click the link.
Great video - your work ethic on getting so many consistent high quality videos out is amazing
It's absolutely not. No security research was put into this. And that the audience doesn't even question this is scary
Is this really more secure? As far as I know, usually emails are not signed and encrypted which would make the sent mail prone to a man in the middle attack, isn‘t it? 🙂
It's absolutely not. No security research was put into this video and it shows. Do not do dumb stuff like this... Use OpenID instead. (or SAML2)
@@TheHegi Or use the Email Authentication of Firebase.
@@Shulkerkiste anything but DIY where security is involved. Yes.
@@TheHegi yes
But aren't the emails themselves unsecure?
E-Mails sent via SMTP are not exactly encrypted. It should be relatively easy to start a man in the middle attack unless the Email is encrypted with something Like PGP, which ist not realistic.
Or am I missing something Here?
I mean same deal goes with the "forgot password" functionality stated at 3:38.
@@jackknash you make a valid point. But not for email-only auth, but rather against token-based password reset emails. I get that they're the go-to these days, but email IS in fact painfully insecure
Also, password resets are rare and the attack vector Blightning talks about is a man in the middle attack. If everyone logs in via email, you can farm account access to any and all active accounts within weeks
@@77dreimaldie0 my point as you said is that they're the go-to anyway, it just removes additional steps users need to do. Regardless if you're making something that requires security, you should always allow 2FA for your stuff if you require accounts being secure.
Email is a protocol based delivery system which means it’s not guaranteed. Even with 2 factor authentication one has the option of how your authenticated by means of phone, text, push notification and also email so if there’s an email issue you would just choose another authentication method but this has to be done behind a username:password combination otherwise how would one solve not being able to receive emails… call customer service.
Hello, how do you prevent somebody uses the login form to spam somebody elses email acount with thousands of emails ? I would keep password authentication along with email and in adition sending the token in email as a second level.
It's simple, the server does not need to send repeat request to the email until the first is verified via email.
@@trappedcat3615 easy to lock yourself out if the mail does not arive.
@@thepublicservices That can be an issue, but sites already require email verification for new accounts, password reset, new device login, and other sensitive actions. In every case, it makes sense to have some kind of security measure to either throttle or stop suspicious or unnecessary repeating the events.
Use like Googles reCAPTCHA?
The only thing I dislike about a magic link auth via email is that it is very inconvenient for the user, but it's viable once when the user is first signing up (mainly to verify the email). There's also the chance that someone's email gets compromised but there's not much we can do there.
Totally agree, this method is not convenient for the user
I see your point, but as a user, I prefer this to creating and remembering yet another password. And as a developer, I love its simplicity.
Personally, I prefer to still enforce secure passwords with MFA layered on top. I just feel like this is a single layered security option, where as a password and MFA at least has two points. This is still a practical auth method, but still makes me uncomfortable.
Like others, I don't like the main trend here. But I never thought of using that secret key hashing system. One extra step to write that to fs turns that into a keygen script. Could use something like inquirer to make it customizable too.
I’ve been thinking about this, and replied on the video itself, but it could work with saving a temporary randomly generated code. Bound to nothing more than System.Random. Yes. It is still bound to time, but quite a bit more random than salted codes.
8:35 actually you don't need to pass the correct key. The JWT payload is a public information and this is actually one of the reasons why you should never ever ever store any private information in it. The possibility to pass the key there on the site is available for you to verify the signature, and also just in case you need to adjust payload for the development purposes.
It is bad to expose token directly in the url, maybe try other method
why? it is only viable for a duration of the token and it is hashed. There are no tools to crack it now. May be in the future. These tokens are billions of times safer than any of the humans behavior in any case
I think it's really cool access only with email. I would like to validate only once or when it clears the section or cookies, so I don't have to go to the email every time I use my app. That is, it is the first time you access, validate the email, only ask for validation again if you clear the section or local cookies
Exactly my theme in one of my projects. Thank you very much.
You know that this is insecure as hell, right?
@@TheHegi I do not know yet. I have to study in peace first. But thanks for the hint. It's also more about the workflow.
@@TheHegi As always: It depends on the app and overall concept, but in general (i.e. with some exceptions) you are right about this being insecure.
Exceptions were this might be sufficient are for example services with unsensitive data (e.g. some throwaway email service), services which provide access to data with a low lifespan (e.g. some image converter where a direct download link to the result is sent to the user) or services which are exclusively used on already approved devices (although I cannot think of an example for this one). Especially on the first two exceptions email based auth might be more secure as you prevent users from choosing a quick insecure password or reusing their standard password. I'm actually currently working on an app where this email only auth suffices the security considerations.
For a more traditional use case of user accounts (e.g. social media, SaaS products, etc.) this of course is a pretty dumb idea and a huge security flaw. Web Dev Simplified totally missed on pointing this out (it seems to me this is due to lack of knowledge in this field).
I see a limitation to this workflow, namely the need to go to your mailbox each time you log on to the site. I dont think it's the best user experience.
This is probably the reason why i would not use it. Say you're at a friends house at their PC/Device. You want to casually log in. If you have an email address running on a webhoster and only have it setup to receive emails through your phone. You'd then need to copy the link to the friends device so you can click the link on that device. I like the idea, but it's bad practice when it comes to user experince. E.g. think of doing this kind of authentication with a netflix account. I would hate it as a user.
Would be good to compare the costs off sending a bunch of emails
The better way would be to store the JWT against a random key and send the link with the key in the email. When users click the link, we can exchange the key to the JWT token and delete the key from the database. This way, we can avoid anyone looking at the logs / URL to replay the API and get the token.
yeah no. This solution is bleeding from many-many wounds really...
@@TheHegi That is a serious improvement for authorization link.
Great content as always 👍
Yeah no. No security research was put into this video whatsoever. It's actually doing more harm than good...
The password of my emails gets hacked. Now that person has access to all resources using this method.
Splendid!!
Wait until you realize it's already the case with every account you used your email address already...
@@TheHegi are you sure? This method does not contain a MFA layer. Where my email accounts do. Having this feature solely would mean that gaining access to any device with my email account logged will have the capability to login.
@@EddieDemon and how does forgot my password work on any website? Sends an email... ;)
Why not combine both system?
Once a user login with their email and password on a new device never used before, it'll send an email verification link (or code to paste).
But when a user is trying to logging from a device that he already previously used to sign in before, no email link will be sent.
That way he can use his password to authenticate on known devices, instead of doing way more action that are, login into the email account clicking on the email then click on the generated link.
And if the hacker knows the account's password he would stil need to have access to the email because he will try to login from a new device.
I was thinking a better solution will be, to ask for password while registering, then while login in, their should an option of `user password` or login with only `email` which means if they forget there password it will be easy to login and if they still remember the password it will as well be okay
*"But when a user is trying to logging from a device that he already previously used to sign in "*
Proper device detection is another great headache to add to a secure authentication system. The only things you can test on the server side are the user agent string of the browser, a "remember me" token you have set previously and maybe the IP address.
IP checks are bad -> Proxies, dynamic ip address assignment to customer from ISP, DHCP in a LAN.
User agent is bad - there are many plugins for all major browsers to manipulate those.
Token is basically the same as the passwordless system described here, without the email part.
I thought this would be the one similar to microsoft auth where if you use no password option, it shows on screen 2 numbers like 30 and then on your phone you open microsoft auth, select right number and scan your fingerprint/write pin to confirm. I saw similar ideas even in banking and this is the one that I think is even better than email link, thou this option is way more accessible.
It's a very similar concept, the only difference is that instead of generating the hashes on microsoft server, they generate the hash (number) on the user's device which saves cost of sending email to millions of users. Now the attacker had to get the email and the number generator to actually breach it.
I guess my first thought would be a man in the middle issue. But there again it's the same for a forgotten password I guess. And I don't know enough to know the feasibility of that sort of thing now-a-days.
What are your thoughts on OAuth providers like Google, GitHub or Microsoft? And how does that compare to Email only Auth?
That's an actual secure way of logging in. This thing? Not so much
With OAuth this big corporations steal your data.
@@cherubin7th then use and host keycloak if that's your fear...
that's why database normalization is important. you can linking multiple type of providers within one user domain.
Some password-less websites don't email a link, but email a 6 digit code which you enter to confirm your login. I think that is a bit more professional than causing the customer to open three tabs/windows to login (login, email, authed). How can this be implemented instead? Seems like a more elegant solution in some cases and uses the same infrastructure to get it set up.
I disagree that this method is more secure than email/password. For example, access to a computer or phone with email client. As well as interception of a mail message with a "secret" token in the plain text.
so what will you do with the intercepted token? you would still need to know the serwer jwt secret to do anything at all
I love the idea, thank you for this video! One disadvantage I immediately think of is users need a configured email client on the same device they want to authenticate on.
Then think harder. (or read comments) This should be the least of your worries...
So someone gets access to my email and I start losing my other accounts as well because theres the single point of failure
I use a password manager, so I login with Ctrl+V and don't memorize long complex passwords. Also Firefox has a master password and I'm not type anything.
All of those are security risk - just ask LastPass ;)
Many people don't use a password manager.
The biggest problem with this method is that you have to make sure user receives your email. Many times you can get banned so easily or your mail can go to span folder. This is serious problem.
Edit: we use sendgrid too. Still get blocked many times.
Well if you do email/password method you should still send a confirmation email, to avoid someone taking a email that does not belong to them, so the problem you're describing would still be present
@@manumrtf not for log in
@@manumrtf hey the flow u are describing is for signing up, not logging in
@@musamutetwi1948 yeah but I mean you still depend of your emails arriving correctly for users to sign up, and about sign in, how many times do you re-signing on the sites?
And If you have also Google Auth the user could still use Google to access to his account
I think Magic Link + Social OAuth Providers are a safe combination
It really annoy when you need to register on new sites that only accept email/password
@@musamutetwi1948 2FA can also be done on email level
Are these cards not working only for me or has YT change things?
11:26 This part is completely confusing as the key there is really just a random string, and it has nothing to do with how it's generated and which algorithm is used to generate it. There IS a difference only if other algorithm is used in JWT strategy as some of the algorithms that use async encryption method require public and private keys rather than just one secret key.
didnt this caused MAJOR security issues back in the day? when phishing scams asked for the url of your hotmail inbox? then they had a session active and access to your account
Kinda but not really
All of these things weaken security. I've started seeing magic links over SMS. Imagine getting a new phone number and forgetting that a handful of websites authenticated you via SMS only. Now, the new owner of your old phone number is the de-facto owner of your account. They don't even have to do anything illegal to get access, they already have the access without committing any crime, similar to you accidentally opening a misrouted envelope that accidentally ended up in your mailbox.
Back in the day, you couldn't even use email to reset your password if you forgot it. People were whining that that led people to writing down their passwords on sticky notes, which was insecure. So they added the ability to reset your password via email. Now, your email is the linchpin to every single account. If your email gets hacked, it's all over. Tell me, how often does someone break into your house to collect password sticky notes, versus someone getting their email account hacked? Then they added biometrics. Great! Now you leave your fingerprint on the sensor of a personal device that authenticates you with your own fingerprint. Very secure.
Finally, someone gets wise and starts suggesting one-time codes as a second factor of authentication... except of course those codes are mostly sent by SMS these days. Try logging into your 2-factor account via SMS when you're on vacation in the Caribbean, or somewhere in Europe, where you're having to rely on Google Voice just to get a phone call out. The text messages don't arrive in time. The voice calls are full of static and always cut out on one of the 6 digits. And then there's a limit on how many one-time codes you can request, with some sites locking you out for an hour or two after you get 5-ish codes resent.
All of this lunacy has led to most people just staying signed-in to all of their accounts. Which is, of course, all fun and games until you leave to go to the bathroom in the coffee shop and come back to your MacBook being stolen. Did you remember to lock the screen? Are you sure the drive is encrypted?
Passwords. Properly rotated passwords, with a time-generated 2FA OTP, are secure. If you can't remember your password, use an offline password manager. Everything else is dumb.
Let's face it, the last 15 years' worth of changes to security around user authentication has, with the exception of time-based 2FA and password managers, been more about convenience and less about security. Staying signed in, password reset, security questions, magic links, biometrics, etc. These are all tools of user convenience, not security.
Future goals: You only need one set of credentials that is tied to you personally and not 3rd party like fb, ig, google, random services.. etc etc and is also decentralized. You can sign in or up with any services with your own credentials and all the data is kept with you. Im tired of remembering 100's of different credentials with each application requiring their own set of rules for passwords.
Federated login is headed in the right direction but your data is still held with them and there are multiple providers still. Apple, Google, fb ...
Yeah but most people on YT don't show how to do that....
If you have any video explaining how to do that, please give me the name of the video :P
I'm tired of those people on youtube saying they show you how to do something for free but then you get into the page they did, and yeah you see a PRICING PLAN payment montly.... which is already for me that vidoe was a BIG AD for that site to make people start using it and pay montly...
Sounds to me like you're describing a password manager ;)
this came at just the right time. Thanks for making this video
While many people point out valid weaknesses to this approach, I think we can improve on this.
- Instead of sending email, we can provide authenticator app for users. Not only this reduces cost on sending emails. The attacker having the email is also not an issue anymore since the hash/number generator is on user's device. Pretty much like what is google, microsoft and twilio is doing. To actually breach it, the attacker must also have the user's device.
So, if you lost your device , you will lost everything? . Always need more than 1 way to login
You have to have a really compelling web app to get users to install an extra auth app on their phone.
Company wants to *save* money by having a simpler system, not spend more by developing an auth app. Pre made third party auth app is probably not usable because of security reasons. An open source auth app might be useable, but also costs more money because of the code audit you'd have to do with each new version before using it.
At that point one could also ask why only the auth part is in an app and not the complete app?
So what happens after user logs out? Does he have to link access link from email everytime he wants to sign in?
You need to understand JWT first. (other tutorials, not this one) once you have that: he used a JWT token in the e-mail, so same rules apply.
Last but not least: this is a horrible terrible idea for a lot of reasons. Don't try this. Anywhere...
Is there any way to login with device unique information ?
I disagree with the database leakage part. Systems should never store authentication credentials in a database in a way it can be used if it's somehow breached. If it's hashed and encrypted correctly they can't do anything with the data they have acquired because it can't be reversed nor decrypted without a proper combinations of secret keys.
If you are encrypting passwords you are not much better than the system who store then in plain text. I'd argue that you're worse because you though about the problem and you think you solved it, but in reality you didn't. Now if you are salting and hashing passwords then you are on the right path :)
@@TheHegi Of course they are hashed to a state they can't be reversed.
@@lumiannah that's great. But that's not encryption...
@@TheHegi I was more saying it in broadly speaking way with the whole data. Authentication data is always hashed and any other sensitive data that is required to be accessed by the end user can be encrypted by methods that are virtually impossible to crack. Apologies for my poor explanation.
what if i want to store this token some where secured so the user can login later without signing to their email again ?
What if you don't attempt this ever? Why? Because it's unsecure as hell
Hey Kyle, I want to say something to you... Are you secretly looking into my brain? Anytime I think to learn something new, you post a video on that topic♥️
Probably you should change the password to your brain dude (or miss😊)… I think Kyle might have an unexpired token to your mind buddy… 😅 😂
@@Luxcium If I were a miss, how could Kyle look into something that doesn't exist?🤣
... This is just email-based 2FA, except without the first factor of a password, it's reduced to 1FA. Sure, it's more secure than just 1FA email-and-password verification, but it's less secure than actual 2FA that should be used.
No it isn't. Read the comments to find out why.
@@TheHegi There's 200 comments, plus countless reply threads. Reading through about 20 of them, I see nothing about this except one other comment that says the same thing I did.
Care to explain how this isn't just one factor of 2FA isolated?
@@IceMetalPunk You haven't found a single thread here talking about why is this thing less secure than usr/pwd?
Any research on this ?
hey thx for the video , even with this ,the link is still fragile to some attacks , theres a better way though , what if when the userregister , for him to verify his account he has to send a mail from his gmail account who he have registered with to our website email (for example lets say the user wants to register he send a mail in which he type register) and then from the website we check if an inverified user have sent an email containing register we verify him and all good
can you make a video on email authentication with a password?
Yeah but it kind of sucks. It keeps logging you out...
Can this be implemented in a chrome extension for login?
The actual authentication and generation of jwt should be done on the server, chrome extension can just act like a UI and send request to authenticate to your backend API
can i get the github repo of this?
Nice lecture.
Thinking a bit further ahead from the users point of view: If all websites where to adopt this authentication system, your email account becomes your password manager. You're in deep trouble if the email account is compromised or you forget your password or your email provider deletes your account or closes up shop. Which requires you to do three things:
1) You really have to trust your email provider and the people that work there. Whoever has admin access at the email provider can log in at the service you are using, because they can access your stored emails.
2) So you set up multiple email accounts to prevent loosing everything at once. At that point all your passwords have migrated from the sevice you are using to the email provider. So you still need to memorize a password for every service via the email address.
3) This is the result of points 1 and 2. If you decide to use multiple emails - probably from differend email providers - you are increasing your risk because you increase the attack surface. Now you have to trust each provider as described in point 1.
The point about data breaches at the used services because of insecure stored passwords is shifted to the email providers. From the users viewpoint it makes no difference. Most "hacks" are just successful phishing or social engineering attempts or a password stealing malware on the users system.
The only good solution I can think of is to:
- have the user choose a login name and provide an email address
- never have the login name present in any email sent to the user
- you have a really small time window where the magic token login link is valid
But this still doesn't fully get rid of the email provider trust problem.
The real benefits of this "passwordless" system are only for the service, not the user. It's easier to implement and it shifts the blame in case of a data breach to someone else.
And this isn't the biggest issue by far... You are better off with SAML2 / OpenID...
@@TheHegi Yup. Everything about this is a bad idea. UX is bad, security is bad, depending on a third party is bad. Like I said, the only thing this is good for is to shift the blame to someone else in case of a data breach.
This would make sense if you use MetaMask instead of email.
This is so annoying. I have multiple email accounts for multiple professional purposes and I divide them by profiles in Chrome. I do most of the work on a single profile so every time I need to login on a website that uses this bs I need to open another window, open my inbox, click the damn message, copy the link, close the window, and then paste on the profile I want to access in. Not to mention having to delete the email so it doesn't add up to the pile of trash.
Typical of slack to try and reinvent the wheel.
Why not use email forwarding from secondary accounts to a central account?
You can also use a different browsers for different purposes. Edge, Google, or Chromium.
I dont agree with this method.. Email might not reach for whatever reason. But still, great video and appreciate the explanation!
Sites already require email verification for sensitive actions like account verfication, password reset or new device login, so it is nothing new.
@@trappedcat3615 yes ofcourse..
@@trappedcat3615 true, in a third world country no one uses a bullcrap piece of technology anymore. Unless the internet is out of coverage or someone is using 2G which should not be the case.
Big fan sir ji
Another incredibly awesome video! I have been retraining as a web developer for almost a year now, and you have frankly made it all much easier and saved my butt so many times!!! Thank you so much for all you are doing, you are by fav the best teacher I've come accross on here 🙏
Why not just a simple OAuth ?
100% this. Implement okta or something similar and you'll never have to store a pwd. Similar system but I would rather use over email only.
Because it's way too simple and it's actually secure. Now why would you want that...
Supabase has this option, and I think it is wonderful.
I will always do everything I can not to use such sites. Been leaving 1 star reviews for apps with this system for almost a year now.
Thanks Kyle!
One final thought: should sites really bother about password recovery? Or should the user have a list somewhere: text file, Outlook Notes, any auto fill password manager,...? Brick and mortar example: if I forgot where I parked my car I can't reasonably ask the owner of the parking lot to find it....If I lose my wallet or something else of value I'm the one to blame and fix it.
Your solution is technically sound but your approach to security in this case is - IMHO - conceptually wrong...
Many crypto apps already use this method for quite some time now due to the number of hacks and scams, notably key loggers. But it's useless if your email was hacked. Make sure to enable 2FA on your gmail.
All of this is rendered useless if your email account password is password123 😂
Or maybe not. I may be overlooking something. Or am I ? I don't know. Ah yes, 2-factor authentication. God help anyone who has that turned off and is using password123 as their main email password though lol
Beautifully explained for us all though Kyle. Quality Content. 👌
Ok how do you know my password 😅 I an lucky that I have used a upper case and special character haha Password123$
@@Luxcium lol
Well yes, a lot of things are rendered useless if someone's email is insecure.
what is the correct way to save token on nextjs/frontend application. cookies? http-only cookies? or in session storage?
please explain why. thank you ❤❤
is this a firebase token?
This is a dangerous way to auth a user and I mean by locking your self out of your own account
I remembered doing similar thing using php last year. In my case, a section of our website is only used for internals. The script generates an hmac hash based on two strings (keys), no email or password required, it's very similar to what you've done with jwt and email. The only advantage is that an attacker would have no email and password to go by to hack into our internal unless they get the actual keys (the two strings which could be re-generated at any given moment) or the script which generates the keys.
Love from India ❤️🩹
Magic link has been made obselete with WebAuthn being implemented in most modern browsers 👀
Awsome course
Yep this type of auth insane and insecure. But Boomers love these email-only auth. Cuz they don't understand password managers and also they usually can't remember anything save their one email password from their 2003 yahoo email which had been in like 59 breaches...
This is built into Meteor too.
Nah, I prefer the old way with password, since I use a password manager.
How is this more secure than the email provider security… 😅 I feel like the email provider is now the one who needs to be secure or not and it’s not your application problem anymore…
This only works per device this code is implemented on ? useful in proper or complimentary applications - ie (work)
The other advantage of email-only authentication is that a password-based login presents an attack-surface, something than can be phished for example.
You might want to read the comment from 2 weeks ago starting with "Thinking a bit further ahead from the users point of view" ..
Lovely tutorial, I was wondering how that would work and that's a very nice explanation, thank you! 😀
This is good for things like admin login 💖
Think again...
Multi-factor auth or nothing.
really good method, I think for this to work well we need some email provider that is dedicated to this kind of thing. so no new fancy feature that brings bugs with, no nothing.
it might be a stupid question but what is the name of the intro, i really liked it so please
I disagree.
what if user not in database? where is Registration?
In another tutorial, where it belongs...
best bro++
Thank you man!
Hey Kyle can you please make a video on how like button or some other things work even though server is down in React.js, like when click on like button in Facebook when internet is down the like button works.
Which book can I use to learn web dev stuff like this? I'm a beginner with no knowledge.
• Integration of analytics tools
• Integration of CRM or marketing automation tools
• An e-commerce platform
• Multi-language support
• Geolocation API integration
• Social media integration
• Cookie consent notification
• Security features
You must learn the language first before looking into that, even if you had the books you will be completely lost since you wouldn't understand what is going on anyway. In this case learn JavaScript first.
Please no
You are totally wrong. This is absolutly not more secure. When you will loose access to your email account, you will also loose access to ALL your accounts.
this is garbage (sorry). Its not more secure and its a massive hassle that nobody is asking for. This was proposed to us (fortune 5 chief arch) and when we asked our members it was one of the most unpopular choices we've ever polled them on.
Shame this is even recommended. You'll run into plenty of problems within production environment, email unreliability is the biggest one. Want a bulletproof login system? Use OAuth and some form of identity provider. Auth0, or use Google APIs to access user information. This handles authorization, then use server-side sessions to handle the authentication if you opt to not use an IdP.
It's a shame this video exists. The damage is already done sadly. I am deeply disappointed in Kyle. He's great when it comes to FE, but he's dangerously short sighted in other areas it would seem. So sad.
👍👍❤
Hi dad
This is the most annoying thing ever