Hacker News Reader

Comment by rpearl | Hacker News Reader

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.

View on HN

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.

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.

But you may still get notifications of requests for the link that you don't request.

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.

> Passwordless login is just password reset without a password ....

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.

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 - 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.

Reply on news.ycombinator.com