A user submits their email address or phone number in the web app.
They are sent a magic link to log in with.
The user clicks the magic link and they are redirected to the app, already logged in.
Sounds good on paper, but gets infuriatingly impractical very quickly:
I want to log in at some random computer
I enter my email
I get an email on my phone
I click the link
I am now logged in on my phone
I sigh
Now I have to enter a password anyway, and deal with whatever added security my email account has. What's worse, I now have to input my email password on some random computer (compromised until proven otherwise), instead of a password for some random application I don't even care about. This isn't an improvement in any way.
A better workflow would be:
A user submits their email address or phone number
They are sent a magic link
When they open said link, on any device, their login clears on whatever device they initiated it
I am a Full stack .NET Developer, I like to work with C#, Asp.Net Core, SQL, Mongo DB, Azure, JavaScript...
Always eager to learn new technologies. I am here to share, ask & eventually learn.
I just don't open my email on some random computer. That's the whole point: if the default is having to type in the password of your some service on some random computer, suddenly having to instead type in the password to my main email account is not an improvement; it's a reason to stop using that application and look for alternatives.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Just stumped into this somewhat old post while searching one specific thingy around passwordless auth on Google, hence if I found it other users will and I think some points need to be discussed here.
While I understand the points mentioned above my question is... if you don't trust the random computer then why are you using credentials on them?
This leads to some assumptions, like you expecting Apps to trust computers that you don't trust yourself with the "user comfortability" argument.
Some common statements around cyber-security:
A system's security is as good as the weakest node on it.
You cannot protect the user devices
Following the rules above, if you had a regular email + password login and the random computer (or your main computer) is compromised, both your email and password will be leaked in any dump file across the internet, which hackers will use as dictionary to brute-force other Apps programmatically thus generating a somewhat up-to-date map of Apps you use with this email that match the same password, plus the email address will be sold to SPAM scums (which can lead to scams and/or the annoying task of cleaning 50 emails daily).
Of course you can point to the argument of "you should never use the same password twice" but this is, in my opinion, the silliest thing after the password must contain at least 1 uppercase, 1 lowercase, 1 number and 1 special character while being even worse for the UX, because no one will ever remember the exact same password used here or there.
We have then few good options:
Integrating a 2FA Authenticator service (all I know are paid ones, hence not suitable for free web apps).
Just use a temporal code received in an email instead of sending an auto-auth link.
Improve the passwordless flux if the UX research finds out it's not good enough.
Integrate a well-known passwordless library and keep it up-to-date.
Having passwordless authentication is most of the time, ironically complemented with passwords as easy-to-develop 2FA systems, this is, set user and password, then you receive an email, use the code in the email to validate the credentials.
This is almost a year old now, but I randomly stumbled upon this and figured I'd address it, because it's honestly no less relevant now than it was a year ago.
Here's the point:
As a user, one should weigh cybersecurity vs. practicality when using computers. This includes things like re-using the same password for several unimportant services where the risk of having an account stolen is minimal.
I'm not gonna have a unique super-secure password for my grocery list; what's the worst that could happen? A hacker remove orange juice from my list and I have to drink water instead? Yea, not happening.
So when you offer a service like that, you should keep in mind that a user might be okay to log in to your service on, say, a public library computer, but might not be okay with logging in to their main email account on the same computer.
Asking a user to log in to their mail account on the same computer that they want to use a service of much lower cybersecurity relevance is problematic because you're now forcing them to take a much higher risk when all they wanted was to quickly make sure they had "flour" on their shopping list while their phone battery was dead.
Trying to get users to treat each and every online service like it has the same relevance to their online security is a way to get them to be neglectful of online security on all their services, including the ones that really matter.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
To update this still-relevant topic, nowadays you have plenty of 2FA solutions that you can get for free (keycloak has built-in OTP thingy, one can self-host a Hanko server and so on and so forth).
Leaving this aside, I understand your points, though the places which allow you to use a computer (library, parlour...) also happen to have USB C, lightning and/or Wireless chargers which might prove more useful than a computer to log on just to check your grocery list (seems quite an unreasonable scenario if you ask me).
Assuming that users would be savvy and aware enough to have categorised apps, each group with its own properly differentiated password... is probably assuming too much. Moreover one would need to assume as well that these users will maintain these categories adequately.
Now imagine a much more plausible scenario; you have multiple bank accounts, one of them is unused since long ago, you have less than 10 bucks there just because you need to be in positive so the bank doesn't shut the account, no movements for the past 14 months, or 35 if you will. It would fall into the "not important" category, right? What can someone do? Stole you 10 bucks? meh...
This bank now decides to launch certain campaigns that raise the interests for storing money there (3.79%) way over what your current savings account offer (2%), so you obviously decide to switch one for the other.
What would an average user do? Simply transfer the funds and call it a day.
I understand that you look at the problem from your prisma and "sigh* it's obvious" runs through your head, but we're a minority, even half of the IT people I know would probably forget or not care enough to change the password!
Luckily banks have tones of obligations and some of these are the number of steps to log in, 2FA, biometrics, session duration and so on, because cybersec, software development and legislators assumed that people will use the same password for both their bank and their 9Gag account.
Being -usually- in the project development side, it's not that I will see any project as being in the "important" category of the people and it's not people what we're trying to safeguard in the first place but the data we are storing, just as a side-effect, one ends up protect people from doing the dumbest shit possible with journeys that involve 2FA in some way or another (not necessarily email) when necessary (and specially in Fintec or anything involving people's money or sensible data).
Lastly as I said before, if one gets a pair of credentials that still work is much easier to find other passwords using different techniques and knowledge. E.g. people usually change just 1 or 2 characters when updating the password, most people's password contain their birth year and son on and so forth. Add OSINT to the equation and you got the combo.
I realised this the first time I did this myself. So I send both the magic link and an OTP
So the user can enter the Pincode if he/she is in such a situation
OR
The link can just verify the login attempt. After the attempt has been verified then you log the user in on the device he/she initiated the login attempt. You can use sockets to make this happen
Not without some degree of back-end persistence, which I assume is the main reason it's not how what the article does. You'd need to create some sort of short-lived state in the back-end that gets cleared by opening a link in the email. The login-window could then just do polling, or use some more sophisticated method for waiting for the server to grant it access.
The only state is in the browser. On the server you just need to verify the token, which could be sent by the browser in the authorization header as a bearer token or in the body or in the url as a parameter or search term. (Sending in URL is an unforced error. It exposes the token, so dont do this in practice.) You should also sign with RSA keys vs secret, so you can verify the origin.
Regarding exposing the token. The magic url, which i hope there's a better term for, can point to a url on the server that returns html where the token and any user data are passed via session storage. It doesnt matter about the nonce. Sincei its now dead.
You say the state is in the browser, but there's not just one browser, but two, and they have no way of directly communicating. Or are you talking about the way it's described in the article?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Sounds good on paper, but gets infuriatingly impractical very quickly:
Now I have to enter a password anyway, and deal with whatever added security my email account has. What's worse, I now have to input my email password on some random computer (compromised until proven otherwise), instead of a password for some random application I don't even care about. This isn't an improvement in any way.
A better workflow would be:
I agree.
I just don't open my email on some random computer. That's the whole point: if the default is having to type in the password of your some service on some random computer, suddenly having to instead type in the password to my main email account is not an improvement; it's a reason to stop using that application and look for alternatives.
Just stumped into this somewhat old post while searching one specific thingy around passwordless auth on Google, hence if I found it other users will and I think some points need to be discussed here.
While I understand the points mentioned above my question is... if you don't trust the random computer then why are you using credentials on them?
This leads to some assumptions, like you expecting Apps to trust computers that you don't trust yourself with the "user comfortability" argument.
Some common statements around cyber-security:
Following the rules above, if you had a regular email + password login and the
random computer(or your main computer) is compromised, both your email and password will be leaked in any dump file across the internet, which hackers will use as dictionary to brute-force other Apps programmatically thus generating a somewhat up-to-date map of Apps you use with this email that match the same password, plus the email address will be sold to SPAM scums (which can lead to scams and/or the annoying task of cleaning 50 emails daily).Of course you can point to the argument of "you should never use the same password twice" but this is, in my opinion, the silliest thing after
the password must contain at least 1 uppercase, 1 lowercase, 1 number and 1 special characterwhile being even worse for the UX, because no one will ever remember the exact same password used here or there.We have then few good options:
Best regards
This is almost a year old now, but I randomly stumbled upon this and figured I'd address it, because it's honestly no less relevant now than it was a year ago.
Here's the point:
As a user, one should weigh cybersecurity vs. practicality when using computers. This includes things like re-using the same password for several unimportant services where the risk of having an account stolen is minimal.
I'm not gonna have a unique super-secure password for my grocery list; what's the worst that could happen? A hacker remove orange juice from my list and I have to drink water instead? Yea, not happening.
So when you offer a service like that, you should keep in mind that a user might be okay to log in to your service on, say, a public library computer, but might not be okay with logging in to their main email account on the same computer.
Asking a user to log in to their mail account on the same computer that they want to use a service of much lower cybersecurity relevance is problematic because you're now forcing them to take a much higher risk when all they wanted was to quickly make sure they had "flour" on their shopping list while their phone battery was dead.
Trying to get users to treat each and every online service like it has the same relevance to their online security is a way to get them to be neglectful of online security on all their services, including the ones that really matter.
To update this still-relevant topic, nowadays you have plenty of 2FA solutions that you can get for free (keycloak has built-in OTP thingy, one can self-host a Hanko server and so on and so forth).
Leaving this aside, I understand your points, though the places which allow you to use a computer (library, parlour...) also happen to have USB C, lightning and/or Wireless chargers which might prove more useful than a computer to log on just to check your grocery list (seems quite an unreasonable scenario if you ask me).
Assuming that users would be savvy and aware enough to have categorised apps, each group with its own properly differentiated password... is probably assuming too much. Moreover one would need to assume as well that these users will maintain these categories adequately.
Now imagine a much more plausible scenario; you have multiple bank accounts, one of them is unused since long ago, you have less than 10 bucks there just because you need to be in positive so the bank doesn't shut the account, no movements for the past 14 months, or 35 if you will. It would fall into the "not important" category, right? What can someone do? Stole you 10 bucks? meh...
This bank now decides to launch certain campaigns that raise the interests for storing money there (3.79%) way over what your current savings account offer (2%), so you obviously decide to switch one for the other.
What would an average user do? Simply transfer the funds and call it a day.
I understand that you look at the problem from your prisma and "sigh* it's obvious" runs through your head, but we're a minority, even half of the IT people I know would probably forget or not care enough to change the password!
Luckily banks have tones of obligations and some of these are the number of steps to log in, 2FA, biometrics, session duration and so on, because cybersec, software development and legislators assumed that people will use the same password for both their bank and their 9Gag account.
Being -usually- in the project development side, it's not that I will see any project as being in the "important" category of the people and it's not people what we're trying to safeguard in the first place but the data we are storing, just as a side-effect, one ends up protect people from doing the dumbest shit possible with journeys that involve 2FA in some way or another (not necessarily email) when necessary (and specially in Fintec or anything involving people's money or sensible data).
Lastly as I said before, if one gets a pair of credentials that still work is much easier to find other passwords using different techniques and knowledge. E.g. people usually change just 1 or 2 characters when updating the password, most people's password contain their birth year and son on and so forth. Add OSINT to the equation and you got the combo.
I agree that this is a better workflow
I realised this the first time I did this myself. So I send both the magic link and an OTP
So the user can enter the Pincode if he/she is in such a situation
OR
The link can just verify the login attempt. After the attempt has been verified then you log the user in on the device he/she initiated the login attempt. You can use sockets to make this happen
How do you go about implementing that last part? Where clicking the magic link on one device logs you in on another?
Not without some degree of back-end persistence, which I assume is the main reason it's not how what the article does. You'd need to create some sort of short-lived state in the back-end that gets cleared by opening a link in the email. The login-window could then just do polling, or use some more sophisticated method for waiting for the server to grant it access.
The only state is in the browser. On the server you just need to verify the token, which could be sent by the browser in the authorization header as a bearer token or in the body or in the url as a parameter or search term. (Sending in URL is an unforced error. It exposes the token, so dont do this in practice.) You should also sign with RSA keys vs secret, so you can verify the origin.
Regarding exposing the token. The magic url, which i hope there's a better term for, can point to a url on the server that returns html where the token and any user data are passed via session storage. It doesnt matter about the nonce. Sincei its now dead.
You say the state is in the browser, but there's not just one browser, but two, and they have no way of directly communicating. Or are you talking about the way it's described in the article?