4 ms·

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

by rpearl 8y ago

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.

jdashg 8y ago
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.
- truesy 8y ago
  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.
  - DDub 8y ago
    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.
    - hndamien 8y ago
      But you may still get notifications of requests for the link that you don't request.
    - pbhjpbhj 8y ago
      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.
- deleted 8y ago
  [deleted]
- jlgaddis 8y ago
  > Passwordless login is just password reset without a password .... And without the security questions.
  - blattimwind 8y ago
    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.
  - Sohcahtoa82 8y ago
    Security questions are often worthless anyways, especially if the victim is active on Facebook.
BillinghamJ 8y ago
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-association https://magic.cuvva.com/.well-known/apple-app-site-associati... and https://magic.cuvva.com/.well-known/assetlinks.json 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-companies-through-their-helpdesk-b7680ddc2d4c 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.

by rpearl 8y ago

jdashg 8y ago

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.

truesy 8y ago
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.
- DDub 8y ago
  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.
  - hndamien 8y ago
    But you may still get notifications of requests for the link that you don't request.
  - pbhjpbhj 8y ago
    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.
deleted 8y ago
[deleted]
jlgaddis 8y ago
> Passwordless login is just password reset without a password .... And without the security questions.
- blattimwind 8y ago
  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.
- Sohcahtoa82 8y ago
  Security questions are often worthless anyways, especially if the victim is active on Facebook.

BillinghamJ 8y ago

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-association https://magic.cuvva.com/.well-known/apple-app-site-associati... and https://magic.cuvva.com/.well-known/assetlinks.json 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-companies-through-their-helpdesk-b7680ddc2d4c 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.