3 ms·

Using email magic links as authentication mechanism is not a great choice in my opinion as email is not a very secure protocol if you think about the default sm

by jupp0r 3y ago

Using email magic links as authentication mechanism is not a great choice in my opinion as email is not a very secure protocol if you think about the default smtp security guarantees and man-in-the-middle interception, either on the smtp or on the network level if servers communicate unencrypted.

KRAKRISMOTT 3y ago
If you believe email to be the weakest link in the chain, then you have to get rid of email password resets too and use reset codes instead. Lose your codes, lose your account.
- apitman 3y ago
  This. As sad as it is, email is the defacto identity on the internet. Every system I'm aware of falls back on email and/or phone numbers for recovery.
  - v2223943777435 3y ago
    just because email is often the defacto identity on the internet doesn't make it a good idea (bandwagon fallacy). i don't consider email tokens to be a serious form of authentication. unless you send the user their authentication secret with data encrypted by the user's public key, i strongly recommend against any use of email-based authentication. * there are a huge number of middlemen in emailing that you have to trust. the sending email provider, the receiving email provider, ISP, email client, the device the client resides on. and everyone else in between. * unless you're just hosting an email server on your local network, starting up an email server that can successfully get its messages across the internet to your intended recipient is an extremely high barrier. email is an extremely error-prone protocol. there's lots of reasons that government/health organizations don't send you personal private information by email and instead send you an email that says to come log into their secure platform to view the private information.
    - apitman 3y ago
      There are mitigations for these security issues. The most important is that you only email the user a random code which is bound to the browser login attempt session. The user is required to enter the code they received in that session. This removes the need to trust any of the parties you listed.
      - v2223943777435 3y ago
        you still have to trust the client device. but i guess if someone else is there you're screwed anyway. also, email has a potential for a big delay. a lot of times people need to log in quickly. email doesn't always reach the destination in a timely manner.
        apitman 3y ago
        The UX challenges are real, no doubt about that. That's actually one of the main reasons I started down the OIDC rabbit hole. I was using only passwordless email logins on my services, and wanted to provide my users with the UX of social login without forcing them to give up their privacy to ad companies.
  - xg15 3y ago
    On the surface yes. In practice, it's more like email + whatever kind of security system your email provider has set up to verify its really you. I.e. try to log into a gmail account from a new machine in an unfamiliar location, even if you know the password and can receive SMS codes. So right now, I'm more worried about getting locked out of a mail account than that someone else could take it over. As for unencrypted SMPT, there is SMTPS [1]. I'm not sure if this seever supports it, but I'd assume it would be a basic requirement if you want to communicate with real-world mailboxes and not instantly flagged as spam. [1] https://de.m.wikipedia.org/wiki/SMTPS https://de.m.wikipedia.org/wiki/SMTPS
- Phrodo_00 3y ago
  You could let users use end to end encrypted protocols for it (like signal, telegram or supposedly whatsapp)
  - apitman 3y ago
    Yes, and I hope we get there someday, but currently that's a tiny fraction of users.
    - Phrodo_00 3y ago
      Whatsapp has like 3 billions users. Not exactly tiny.
      - apitman 3y ago
        Huh, I honestly didn't know it was that big. Forgive my ignorance, I've never really used Whatsapp. Can you send a message to someone that hasn't added you as a contact? If so I would seriously consider implementing this as an alternative to email. The main problem is that it's not federated and completely under Facebook's control. Also, identity based on WhatsApp is still vulnerable to simjacking, correct?
        Phrodo_00 3y ago
        > The main problem is that it's not federated and completely under Facebook's control. Also, identity based on WhatsApp is still vulnerable to simjacking, correct? Yes to both
  - jupp0r 3y ago
    Even SMS would be vastly more secure, as sim swap or SS7 attacks are costly.
- brazzledazzle 3y ago
  With these servers/services you can usually chain to another identity source (e.g. ldap directory+kerberos) so that would fall to the origin identity service. But even if you don't chain it the owner of OIDC provider will usually provide an administrator role and integration system accounts that can be used as an out of band sort of user account recovery mechanism.
- JambalayaJim 3y ago
  There is one difference here - email reset would lock the legitimate user out of the account, whereas email magic links would not. I think that's an advantage for the former.

by jupp0r 3y ago

KRAKRISMOTT 3y ago

If you believe email to be the weakest link in the chain, then you have to get rid of email password resets too and use reset codes instead. Lose your codes, lose your account.

apitman 3y ago
This. As sad as it is, email is the defacto identity on the internet. Every system I'm aware of falls back on email and/or phone numbers for recovery.
- v2223943777435 3y ago
  just because email is often the defacto identity on the internet doesn't make it a good idea (bandwagon fallacy). i don't consider email tokens to be a serious form of authentication. unless you send the user their authentication secret with data encrypted by the user's public key, i strongly recommend against any use of email-based authentication. * there are a huge number of middlemen in emailing that you have to trust. the sending email provider, the receiving email provider, ISP, email client, the device the client resides on. and everyone else in between. * unless you're just hosting an email server on your local network, starting up an email server that can successfully get its messages across the internet to your intended recipient is an extremely high barrier. email is an extremely error-prone protocol. there's lots of reasons that government/health organizations don't send you personal private information by email and instead send you an email that says to come log into their secure platform to view the private information.
  - apitman 3y ago
    There are mitigations for these security issues. The most important is that you only email the user a random code which is bound to the browser login attempt session. The user is required to enter the code they received in that session. This removes the need to trust any of the parties you listed.
    - v2223943777435 3y ago
      you still have to trust the client device. but i guess if someone else is there you're screwed anyway. also, email has a potential for a big delay. a lot of times people need to log in quickly. email doesn't always reach the destination in a timely manner.
      - apitman 3y ago
        The UX challenges are real, no doubt about that. That's actually one of the main reasons I started down the OIDC rabbit hole. I was using only passwordless email logins on my services, and wanted to provide my users with the UX of social login without forcing them to give up their privacy to ad companies.
- xg15 3y ago
  On the surface yes. In practice, it's more like email + whatever kind of security system your email provider has set up to verify its really you. I.e. try to log into a gmail account from a new machine in an unfamiliar location, even if you know the password and can receive SMS codes. So right now, I'm more worried about getting locked out of a mail account than that someone else could take it over. As for unencrypted SMPT, there is SMTPS [1]. I'm not sure if this seever supports it, but I'd assume it would be a basic requirement if you want to communicate with real-world mailboxes and not instantly flagged as spam. [1] https://de.m.wikipedia.org/wiki/SMTPS https://de.m.wikipedia.org/wiki/SMTPS
Phrodo_00 3y ago
You could let users use end to end encrypted protocols for it (like signal, telegram or supposedly whatsapp)
- apitman 3y ago
  Yes, and I hope we get there someday, but currently that's a tiny fraction of users.
  - Phrodo_00 3y ago
    Whatsapp has like 3 billions users. Not exactly tiny.
    - apitman 3y ago
      Huh, I honestly didn't know it was that big. Forgive my ignorance, I've never really used Whatsapp. Can you send a message to someone that hasn't added you as a contact? If so I would seriously consider implementing this as an alternative to email. The main problem is that it's not federated and completely under Facebook's control. Also, identity based on WhatsApp is still vulnerable to simjacking, correct?
      - Phrodo_00 3y ago
        > The main problem is that it's not federated and completely under Facebook's control. Also, identity based on WhatsApp is still vulnerable to simjacking, correct? Yes to both
- jupp0r 3y ago
  Even SMS would be vastly more secure, as sim swap or SS7 attacks are costly.
brazzledazzle 3y ago
With these servers/services you can usually chain to another identity source (e.g. ldap directory+kerberos) so that would fall to the origin identity service. But even if you don't chain it the owner of OIDC provider will usually provide an administrator role and integration system accounts that can be used as an out of band sort of user account recovery mechanism.
JambalayaJim 3y ago
There is one difference here - email reset would lock the legitimate user out of the account, whereas email magic links would not. I think that's an advantage for the former.