1. 48
  1. 15

    I must say that magic links are useful in some cases:

    I like them on websites you login on once a year, with the bonus users can’t forget a password. You won’t be able to leak sensitive passwords either, which some users like. There are way to many users using the same passwords over and over again, and the majority does not seem to be using a password manager.

    But, I do believe you should make the use of a password optional for such implementation.

    1. 9

      The other benefit (for multi-tenant environments) is that magic links automatically have the same protections that the users’ corporate IT department have decided are important for security/HR reasons. No need to make multiple orthogonal password policies or support multiple MFA flows, and offboarding is automatic.

      It’s like a poor man’s SAML. (You also have to support SAML)

      1. 5

        IMO magic links are better than passwords. Most people essentially have everything tied to their email anyway (password recovery in almost every case sends an email). It also solves the fact that most users will reuse the same passwords, or pick extremely weak passwords so they can remember them all.

        Obviously password managers fix this too, but most users will not make use of them.

        To quote the article:

        but I think it’s important to recognize how users are used to logging in across the internet

        The status quo is also that every few weeks a site has a data breach, and malignant actors gain access to several accounts because most users are “used to” reusing passwords.

        1. 3

          I like magic links, with JWTs for long (one-month) validity. Login rarely? Check your email rarely. Login regularly? Check your email rarely. And I don’t have to store passwords.

          I do not know how to deal with people who don’t get email on their phone and need to log in on their phone.

          1. 3

            Why doesn’t the magic link authorise the session that initiated the send? Store the session id, magic token and authorised status in a table…

            1. 1

              Because you already opened a new tab, you’d need to refresh the sending window or just use the window you already have. Also I wanted to minimize state where possible.

              1. 2

                IIRC, Slack uses a websocket connection to log you into the original session (even if it’s on a different device).

                1. 1

                  Which requires more JavaScript, but I can see the value in that, especially combined with the JWT approach. Should be a great way to get people logged in on mobile.

          2. 2

            Magic links are near necessary for people who use an offline password manager but like to use Slack/etc.. on their phones.

            The article calls out Slack for starting this trend, and that may be the case in some way, but Slack has the right idea of using magic links primarily for logging into their mobile app, and for desktop stuff, you still can use your password.

            1. 4

              And then there’s people like me who don’t have access to email on their phone.

              1. 2

                Slacks magic link authorises your phone even if you click it on desktop.

                1. 1

                  Indeed, then you’re back to the camp of turning passwords into QR codes and copying them to the phone that way.

            2. 10

              I wish I could up-vote this twice. Sites breaking my password manager is one of my biggest pet peeves with the modern Internet. I’ve been struggling with it for years, and it seems to be getting worse.

              Why do people build sites like this? Presumably, the programmers that build these sites use password managers too. They must know what a hassle they’re creating.

              1. 4

                Project managers: If the nerds are being paid so well they might as well be changing improving how the site works!

              2. 5

                There is a valid use for two-page logins. My bank has username on the first page and password on the second. It also displays a picture you’ve selected along with some customizable text. This makes it more difficult to phish users, since you can’t just create a copy of their homepage. I suppose you could fetch the picture and text for a given user when they try to login, but there might be a request limit… Then again it could all just be security tehater since they also require three secret questions, and require them to be changed on a regular basis.

                1. 6

                  My bank does the same thing. I think it actually hurts security. It makes users think that if they see their chosen security image, then it can’t be a phishing attempt. However, it’s pretty straightforward for a phishing site to fetch the security image (they’d just need a pool of IP addresses, which is easy enough to come by). My bank actually takes it even one step farther and asks for the username on a different domain than the password. They’re basically training users to not look at the URL and only trust the worthless security image.

                  1. 2

                    My bank recently stopped with the image thing, and now allows one step logins

                2. 4

                  The only valid use case I know of for 2 pages, one for the email address and one for the password and 2FA. If 2FA is not a requirement, but is an optional thing, then you only want to show it if they have 2FA enabled.

                  Our login is 2 pages, one for the email address, and a second for the password (and 2FA, if it’s enabled on your account).

                  But they are very straightforward, and no javascript anywhere on the auth login pages. Javascript is a security nightmare, we just avoid it, and we turn it off with HTTP headers as well.

                  1. 3

                    As a computer science teacher who also runs the general-use computer lab at our school, I wish more sites gave the option of magic links. Students are terrible about choosing reasonable passwords and storing them securely yet accessibly. Students that I work with frequently, such as those in the CS program, are used to working with their passwords regularly, but those who are only in the lab to work on assignments for other classes are constantly asking for password resets for services that aren’t usually under my direct control. Faculty and staff are often just as bad. Magic links rely on them remembering only their email account credentials.

                    1. 2

                      MacOS login screen also buries the password field to “clean up” the UI (and I’d also assume to encourage users to login via TouchID), but that cleanliness leads to (in my view) a more confusing experience.

                      I think there’s a valid reason for that: It is possible to have an account without a password. I think showing a password field which should be left blank in this case is even more confusing.

                      1. 2

                        Could always just gray it out in that case, or omit it entirely. You have to put the check for skipping past it somewhere.