5 ms·
The difficulty of switching authentication providers
- notlukesky 4y agoCan 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?
- btmcnellis 4y agoSlack supports it, though I suspect most enterprises (on Slack and elsewhere) use SSO instead, if they’re actually paying for the enterprise tier.
- dhruv_tek 4y agoYup, 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
- shafyy 4y agoEmail-based logins are not great from a security standpoint, to put it mildly.
- dhruv_tek 4y agoNot 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 https://www.ezid.io/resource/are-magic-links-secure
- nullfield 4y agoIt 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.
- prash_murali21 4y ago"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.
- orev 4y agoAfter 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.
- jaywalk 4y agoMost email these days is sent over encrypted connections and encrypted at rest.
- emptysongglass 4y agoI 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.
- jjav 4y agoSMTP 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.
- orev 4y agoThe 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.
- jjav 4y agoLogin via URL ("magic link") is about as insecure as it gets. You can do worse, but have to try. 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).
- prash_murali21 4y agoI 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.
- GordonS 4y agoHmm, 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?
- shafyy 4y agoFor 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.
- arubania2 4y agoThat 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?
- prash_murali21 4y agoAgree with this. I don't see why you cannot add 2FA to email based login flows.
- shafyy 4y agoYes, 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.
- GordonS 4y agoThis 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 :)
- jiveturkey 4y agoThey 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.
- prash_murali21 4y agoYes exactly. If the email itself doesn't require MFA, you can always add MFA on top of email magic links.
- jiveturkey 4y agoYou 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.
- ripperdoc 4y agoGood 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?)
- g_p 4y agoAnother good reason to avoid "passwordless" and magic links in email from https://news.ycombinator.com/item?id=31892299 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...
- miohtama 4y agoHTTP 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.
- chinathrow 4y agoWith 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.