Ask HN: Security of Passwordless Login?
Hi, all. I noticed Tumblr (for me, as least) started offering passwordless login ala Medium (i.e. they'll send me a "magic link" that logs me in). I was wondering: how secure is this sort of passwordless login?
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!
27 comments
[ 1.9 ms ] story [ 75.5 ms ] threadIf those hold, then the security should be equivalent to the email account's own security.
Passwordless login is just password reset without a password, neatly removing the weak link in the chain.
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.
And without the security questions.
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'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 - auth+1234blah@cuvva.com. 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.
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'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.
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.
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.
The risk factors associated with how humans use passwords vastly outweigh the risk of data being captured in transit.
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.
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.