Ask HN: Security of Passwordless Login?
27 comments
I've implemented it into a few services, but they were relatively low-risk in terms of the information retained.
In fact, for most services it is possible to use password resets for just this purpose. Sign up with your email and an incredibly strong password that you never retain, reuse or remember. Next time you need to log in, just reset your password. Same thing. By offering passwordless login from the outset, you make doing so easier.
The one pain point is the need for the user to have access to their email, which these days is pretty easy.
In fact, for most services it is possible to use password resets for just this purpose. Sign up with your email and an incredibly strong password that you never retain, reuse or remember. Next time you need to log in, just reset your password. Same thing. By offering passwordless login from the outset, you make doing so easier.
The one pain point is the need for the user to have access to their email, which these days is pretty easy.
The sender of the email needs to do dns resolution properly and securely (for instance, using DNSSEC to have origin authentication), and the domain of the email needs to have sole control of the ability to add DNS entries.
If those hold, then the security should be equivalent to the email account's own security.
If those hold, then the security should be equivalent to the email account's own security.
It only has to be as secure as password reset.
Passwordless login is just password reset without a password, neatly removing the weak link in the chain.
Passwordless login is just password reset without a password, neatly removing the weak link in the chain.
Exactly. You can have a rock-solid password login system, but pretty much everyone has a reset feature which kicks a link to the email address, and allows that user to change the password. It's no less secure than that.
It is slightly less secure than that as the password reset form has a notification mechanism built into it in that the next time you login you realise that you need to reset the password back to what you control, where the magic link does not have such a mechanism to let you know that a compromise has taken place. It is slight, and requires you to be paying attention.
I don't think it's that slight a difference - password reset is akin to a door that you have to break open. The reset is obvious, there's evidence.
A password-less login, the email can be deleted and unless there are logs of last login, and the user notes the pertinent detail, then the intrusion can be covert.
Having someone unknowingly have a key to your apartment is much more of a breech than discovering a broken lock that you know needs fixing.
A password-less login, the email can be deleted and unless there are logs of last login, and the user notes the pertinent detail, then the intrusion can be covert.
Having someone unknowingly have a key to your apartment is much more of a breech than discovering a broken lock that you know needs fixing.
But you may still get notifications of requests for the link that you don't request.
[deleted]
> Passwordless login is just password reset without a password ....
And without the security questions.
And without the security questions.
Most sites don't have those anyway.
I think the biggest security differential is the fact that a compromised password reset generally is harder to hide, because the attacker cannot replicate the original token.
I think the biggest security differential is the fact that a compromised password reset generally is harder to hide, because the attacker cannot replicate the original token.
Security questions are often worthless anyways, especially if the victim is active on Facebook.
There are a few other key things to consider.
I'd particularly suggest making use of something like PKCE (an extension of OAuth) to reduce the risk of the wrong application intercepting the token - this is important for native mobile apps.
Again for native mobile apps - prefer the use of proper Universal Links (iOS) and App Links (Android) - rather than URL schemes. The former is significantly more secure and reduces the probability of MITMing. (See https://magic.cuvva.com/.well-known/apple-app-site-associati... and https://magic.cuvva.com/.well-known/assetlinks.json as examples of how this works)
It's also rather beneficial for the "from" email to be unpredictable. For example, my company includes a nonce - [email protected]. This is to ensure resistance against this attack: https://medium.com/intigriti/how-i-hacked-hundreds-of-compan...
Obviously they must be one-time-use. Your clients should make use of a "state" parameter (along the lines of the OAuth definition) to ignore any unexpected callbacks. If you detect an attempt to use them again, you should revoke all sessions which stem from the token.
Recommend reading all the other OAuth security considerations/caveats also. I find this to be quite a useful reference of things to think about. Wouldn't necessarily recommend actually building a full OAuth server though - tends to be a recipe for making mistakes.
I'd particularly suggest making use of something like PKCE (an extension of OAuth) to reduce the risk of the wrong application intercepting the token - this is important for native mobile apps.
Again for native mobile apps - prefer the use of proper Universal Links (iOS) and App Links (Android) - rather than URL schemes. The former is significantly more secure and reduces the probability of MITMing. (See https://magic.cuvva.com/.well-known/apple-app-site-associati... and https://magic.cuvva.com/.well-known/assetlinks.json as examples of how this works)
It's also rather beneficial for the "from" email to be unpredictable. For example, my company includes a nonce - [email protected]. This is to ensure resistance against this attack: https://medium.com/intigriti/how-i-hacked-hundreds-of-compan...
Obviously they must be one-time-use. Your clients should make use of a "state" parameter (along the lines of the OAuth definition) to ignore any unexpected callbacks. If you detect an attempt to use them again, you should revoke all sessions which stem from the token.
Recommend reading all the other OAuth security considerations/caveats also. I find this to be quite a useful reference of things to think about. Wouldn't necessarily recommend actually building a full OAuth server though - tends to be a recipe for making mistakes.
Passwordless login is generally as secure as most password reset strategies. (I.e. simply email password to an email address without doing further identity checks such as checking last remembered password or asking security questions)
It doesn't really matter if an advanced technique like you described is used, or if the email account itself is compromised, the security considerations are the same.
The one advantage that password reset emails have over magic link logins is they can provide users a clue that their account has been compromised when the old password doesn't work. (Though in practice, how many users will just reset their password and move on with no further investigation?)
In additional to single-use time-limited tokens, there are two additional measures that address this type of attack:
Providing details on the previous magic link that was used (date, time, IP address and maybe user-agent details) in the email with the magic link provides the ability to detect people who have gained access by requesting a link then deleting/blocking the email so that you don't see it.
Limiting the token to being used by the same IP address that requested the token prevents people from watching for a legitimate magic-link request and then hijacking that link for their own access.
With those two measures in place, I don't think there is any security downside to switching to passwordless logins.
I would note that if you employ both password and passwordless logins, this increases your attack surface and decreases the chances that intrusion will be noticed. (I.e. if the target uses a password to login, the can request magic links and then delete them and the target may never see this activity since they don't request their own emails. Conversely, if the target uses magic-links to login, the attacker can reset the password and the user may not ever notice). As such, it may make sense to limit users to a single login method (or always display a page showing last magic-link login and last password reset when logging in)
It doesn't really matter if an advanced technique like you described is used, or if the email account itself is compromised, the security considerations are the same.
The one advantage that password reset emails have over magic link logins is they can provide users a clue that their account has been compromised when the old password doesn't work. (Though in practice, how many users will just reset their password and move on with no further investigation?)
In additional to single-use time-limited tokens, there are two additional measures that address this type of attack:
Providing details on the previous magic link that was used (date, time, IP address and maybe user-agent details) in the email with the magic link provides the ability to detect people who have gained access by requesting a link then deleting/blocking the email so that you don't see it.
Limiting the token to being used by the same IP address that requested the token prevents people from watching for a legitimate magic-link request and then hijacking that link for their own access.
With those two measures in place, I don't think there is any security downside to switching to passwordless logins.
I would note that if you employ both password and passwordless logins, this increases your attack surface and decreases the chances that intrusion will be noticed. (I.e. if the target uses a password to login, the can request magic links and then delete them and the target may never see this activity since they don't request their own emails. Conversely, if the target uses magic-links to login, the attacker can reset the password and the user may not ever notice). As such, it may make sense to limit users to a single login method (or always display a page showing last magic-link login and last password reset when logging in)
[deleted]
Don't forget that a non-trivial amount of e-mail still passes across the Internet completely unencrypted.
That's something worth quantifying. Google produces a report of the percentage of incoming and outgoing email it sees that travels over a TLS secured SMTP connection here: https://transparencyreport.google.com/safer-email/overview
It's currently about 90% for both directions. If you change the start date on the graphs, you'll see that figure was about 50% 4 years ago.
It's currently about 90% for both directions. If you change the start date on the graphs, you'll see that figure was about 50% 4 years ago.
It’s exactly as exploitable as a standard password reset flow, except that if you reset someone’s password, they’ll probably notice their current password not working anymore.
Minus the worst bug of all time - password reuse and bruteforce. Sounds like fair tradeoff.
This is quite a good point, it might even put off some “casual” attacks
Consider the weakest link in the chain.
Almost every website in the world currently allows you to reset your password via email, and there's rarely ever a way to opt out and disable that.
You can't lose something if you've never had it in the first place.
Almost every website in the world currently allows you to reset your password via email, and there's rarely ever a way to opt out and disable that.
You can't lose something if you've never had it in the first place.
It's significantly more secure and more convenient. Magic links rock. See rollcat comment +1
Magic links are susceptible to man in middle attacks if your DNS is compromised, like on public WiFi, because the reset token is in the URI itself. So you're most vulnerable when you click the link.
No, they're not, unless you also have a valid TLS certificate for the domain.
If I link you to https://foo.com/login?token=123, you need a valid TLS certificate to foo.com in order for my browser to actually send that token to it or for me to reach that page.
Even if you MITM DNS to give an ip address you control, it doesn't matter since you won't have a valid TLS certificate for foo.com, and so you gain no information.
If I link you to https://foo.com/login?token=123, you need a valid TLS certificate to foo.com in order for my browser to actually send that token to it or for me to reach that page.
Even if you MITM DNS to give an ip address you control, it doesn't matter since you won't have a valid TLS certificate for foo.com, and so you gain no information.
HTTPS usually is implied by any security-aware website and HTTPS will mitigate this attack.
Not if the service uses TLS; adversaries will only be able to see the hostname.
I've written a detailed argument for why passwordless auth (using email or some sort of reliable auth) is more secure than using passwords: https://medium.freecodecamp.org/360-million-reasons-to-destr...
The risk factors associated with how humans use passwords vastly outweigh the risk of data being captured in transit.
The risk factors associated with how humans use passwords vastly outweigh the risk of data being captured in transit.
I think it's much more secure, both for you as an individual user and for the service as a whole.
First of all, if an attacker has access to your email account, then you're doomed. The attacker can reset your password, lock you out, and acquire all privileges. Access to the email account is a fundamental assumption that every service does, and in fact that's how they let you even change your password.
For you as a user, it means not having to remember an extra password. The drawback is that email connectivity may slow down your login, and clicking the link could not work perfectly on mobile device.
For the service as a whole, it means not storing passwords, and thus not risking to leak passwords, and not being at risk of ATO due to reused and leaked credentials.
However this turns authentication from something the user knows (password) to something the user has (access to, their email account). Strictly speaking, this reduces the scope & security of 2FA solutions.
First of all, if an attacker has access to your email account, then you're doomed. The attacker can reset your password, lock you out, and acquire all privileges. Access to the email account is a fundamental assumption that every service does, and in fact that's how they let you even change your password.
For you as a user, it means not having to remember an extra password. The drawback is that email connectivity may slow down your login, and clicking the link could not work perfectly on mobile device.
For the service as a whole, it means not storing passwords, and thus not risking to leak passwords, and not being at risk of ATO due to reused and leaked credentials.
However this turns authentication from something the user knows (password) to something the user has (access to, their email account). Strictly speaking, this reduces the scope & security of 2FA solutions.
I think I've got a good understanding of how the magic links work (single-use, time-limited tokens, etc.) and that seems secure, but I'm wondering if you can rely on only the actual user receiving the email with the magic link. I hear a lot about how DNS is fundamentally insecure, and I suppose by inserting altered MX records an attacker could start receiving a domain's emails, but I'm not clear on exactly how such attacks work or how feasible they are. Also, would this be any less secure than the standard password reset function that also assumes only the actual user receives the reset email?
Can any of HN's security experts enlighten me?
Thanks!