The difficulty of switching authentication providers | Hacker News Reader

The difficulty of switching authentication providers

ezid.io

26 pointsdhruv_tek31 comments

Good diagrams, as is needed in any authentication flows where the devil always end up lurking in the details! But I have a general concern on passwordless. We recently tried switching a SaaS app to Firebase passwordless but it has been a support nightmare. Typical error cases:

a) User has to wait many minutes for email

b) User never finds the email

c) User clicks to get another email, invalidating the first, then clicking the first

d) User tries to re-use old sign-in emails to get in again many days later

e) User gets confused as to whether they are supposed to have a password or not, or other forms of sign-in vs passwordless

At best, these problems amount to some support work and user friction. But in the worse case, for the not so tech-savvy users, they become a complete blocker to using the product.

Of course, we cannot track deliverability when the emails are sent by Firebase so we can't really see how often there are problems. Are we just unlucky, missing something obvious or is passwordless a poor bandaid on the auth problem (hey, webauthn?)

Another good reason to avoid "passwordless" and magic links in email from https://news.ycombinator.com/item?id=31892299 is that some email clients or server stacks "click" on links, and perhaps even use their search crawlers to index sites they visit from the links.

That could result in private user content being indexed by the crawler if it's not configured correctly, or if it didn't realise this.

This also introduces another complication on figuring out whether the user clicked it twice, or whether one click was actually the email server provider doing some "scanning" by clicking all the private links in the email...

HTTP GET is idempotent by the spec. If you login by visiting URL it is not according to the HTTP spec. You should any case have a button that says Login and does HTTP POST.

With some mail providers using grey listing heavily, I don't even know why passwordless via email link click is a thing. I hate it with a passion.

Can you ever build enterprise SaaS with email link based logins? Any examples of enterprise SaaS with email link login? Or is it just for consumer?

Email-based logins are not great from a security standpoint, to put it mildly.

They are generally secure. Password reset typically uses email as the sole factor. So it's no less secure than that, which is generally considered necessary and secure.

In an enterprise setting, access to email can be made to require MFA. The email loop itself, to major providers, is generally secure.

Yes exactly. If the email itself doesn't require MFA, you can always add MFA on top of email magic links.

You mean the SaaS can add their own MFA? No, they can't. If you do that, you have no reasonable way to recover accounts. You get down the rabbit hole of extremely difficult UX, vs easily bypassed MFA. Once you add MFA, you cannot allow account recovery without it. This is the still-hard part of MFA.

By the time you go through all the rigamarole, you're just better off forcing your customer to manage their own MFA.

Hmm, it "feels" insecure to me, but thinking on it, I'm not sure why, especially since most email is web-based these days, and pretty much all the rest goes over encrypted IMAP/POP/Exchange.

What concerns do you have?

For one, if an attacker has access to your email, they also can log in to all your accounts where you used e-mail based login.

That is also true for every password-based account without 2FA by means of password reset.

Plus, having someone access your email account means you're pwned anyway - they can see your sensitive documents that were received / sent as attachments, they can read recent conversations and phish information, maybe even ask for a downpayment, etc.

So the basic rule should be: don't lose access to your email.

That doesn't mean that email-based login is good, just that IMO this point is kind of moot.

Also, do email-based login flows allow 2FA?

Yes, you're very pwned if somebody has access to your email account. But less pwned than if they can also access all your other accounts directly at the same time =)

Of course, combining email-based login with another factor makes it more secure again, I was just talking about one factor.

Agree with this. I don't see why you cannot add 2FA to email based login flows.

This is true of any non-physical authentication factor, so is your view that a second factor should always be "something you have"?

As, what about web-based email systems that enforce 2FA? Isn't that a good mitigation?

Any other issues you see? (genuinely just curious, I don't mean to needle you :)

There is none. I implemented passwordless on an app a few months back and a few weeks ago it passed a CHECK pentest with no flaws detected or expected in auth. It’s basically asking the user to reset their password every time, which is much safer than having them using “123456” as their password.

I use Sendgrid to send the email and have had no issues with the service so far.

Not true! We have written this piece that talks about the security of magic links and how they can be used: https://www.ezid.io/resource/are-magic-links-secure

It doesn't really matter if they're secure or not (but they're not).

They're also infuriating, massively increase friction (especially for users of a web-based email system that they may not keep open) by forcing a user out of their workflow, as well as infantilizing users by deciding that for them that they just don't know any better and can't be trusted to use a secure password/turn on 2FA.

If security were actually the concern, push users to turn on 2FA with a non-removable banner until they do it, and on that page prominently educate them on the best ways to smooth THAT out via the many 2FA tools that help manage logins, until we have a good 2FA standard or good, wide implementation of webauthn or similar.

Perhaps we tolerate emailed password reset links currently until there is a better method. There's an additional advantage to them in that "if they work, you know they haven't been lifted/used, and your password still works/has been set". On the other hand, given that anyone can go ask for a login link to be sent as many times as they want, if you come home to a mailbox full of login link requests you haven't requested and which have already expired you really have no hope of knowing whether or not your account has been compromised/used for some nefarious purpose already. Even having immutable-to-the-end-user session info saved and displayed probably isn't enough to remedy this.

"you really have no hope of knowing whether or not your account has been compromised/used for some nefarious purpose already" this is an interesting point.

Although the same would be true if your password to site in question itself got compromised, which is probably more likely. You wouldn't have any way of knowing if your account has been used for some nefarious purpose already too.

After reading that, nobody should be taking security advice from you and I would avoid using your product. Most of the piece is spent talking about UX (which is almost always in conflict with security), and ignored the extremely large problem that email is sent over the Internet without encryption, and then sits on some cloud server somewhere without encryption. Maybe that’s fine for managing a newsletter subscription, but it’s complicated inappropriate for anyone wanting real security.

Perhaps a better title would be "trade-offs between security and UX for Magic Links"? Actually agree with most of what you said (bar the first sentence ;))

2 key things highlighted in the post though:

1. The trade-offs you take are entirely dependent on the type of web app you have and there isn't really a one size fits all solution (nor should there be). If you are having a banking app vs a newsletter subscription, of course the solution would (and should) be different. You can always supplement the email magic links with 2FA based on "something you have" like SMS, TOTP authenticators or WebAuthn. Just like you can supplement traditional un/pw auth with extra factors...

2. The encryption argument is factual but completely irrelevant if the comparison is really between a magic link flow and a password reset flow, which pretty much every site has to deal with. Magic link flow would give 'at least' that amount of security without the problems of passwords being phished or brute forced. This is true whether are not the email is e2e encrypted or not. Recovery mechanisms for some reason tends to get overlooked... and email is by far the most common recovery mechanism present in the internet today.

> UX (which is almost always in conflict with security)

UX is arguably a security concern. Poor UX impacts availability of the service, and availability is definitely a security concern. It can also tempt users to bypass security mechanisms if they have poor UX, often leading to worse security than before the mechanism was added!

I had to double take here because that just isn't true. I can't even remember when the last time was that I sent an email over the wire without encryption and if you're using one of the big free providers (most are) you can be absolutely certain those emails are encrypted at rest.

SMTP connections tend to be opportunistically encrypted, but intercepting the connection via MITM is much easier than for e.g. a HTTPS connection.

So while it's true that most SMTP connections are encrypted, that doesn't mean anything unless the endpoints are enforcing trust on each other which mostly they're not.

The more we assume that everyone is using the big email providers, the more it becomes a reality. And everyone agrees that a centralized Internet controlled by only a few companies is one of the worst case scenarios.

I have no certainty at all that any of those free providers use encryption at rest. How would they mine the messages for data to sell? And, cloud compute is expensive, and disk encryption takes more CPU cycles. Why would they spend that money? SMTP connections are more visible so it makes sense to use that from a marketing standpoint.

Yeah the big providers will not be encrypting at rest for sure. Even if so, the encryption keys would lie with the provider and not the end user, which kind of defeats the purpose.

Most email these days is sent over encrypted connections and encrypted at rest.

Password reuse is bad because it allows compromising one site if another one is compromised. By sending someone a URL to login via email, now you've effectively forced password reuse of their email password as the site password (because obviously, if someone gets access to email they also get access to the emailed links).

I believe we have to view from the context of how most sites do auth, which is email + password with an 'email recovery' for the password. This is effectively the same thing with worse UX and an added attack vector of the password for the site being compromised.

The point on password reuse I agree with, but flakiness here is that there do unfortunately exist dodgy sites without TSL and without password hashing and salting in place. This overall increases the probability of a breach and since re-use is common the supposedly secure sites become vulnerable too. At least with email, most major email providers have some level of securing the email (example 2FA involved when attempting to login from a different device).

If the comparison is between email magic links and a site that offers email / password with no recovery at all or "secret questions" as the means of password recovery, which I haven't seen in years, that's a whole other debate all together.

Slack supports it, though I suspect most enterprises (on Slack and elsewhere) use SSO instead, if they’re actually paying for the enterprise tier.

Yup, you actually can do it. I've seen a few enterprise level companies do it without SSO, especially for their invite user feature. Much easier to have he invite a new user to be done passwordless than the usual onboarding flow

Reply on news.ycombinator.com