7 ms·

If you're doing auth in 2024, please consider not supporting passwords. Most people will never use a password manager, and even if they did it's not as secure a

If you're doing auth in 2024, please consider not supporting passwords. Most people will never use a password manager, and even if they did it's not as secure as key-based approaches or OAuth2. Obviously there are exceptions

canadiantim 2y ago
That seems false. Key-based approaches I understand to be less secure than passwords, albeit of course not if someone is reusing passwords found in breaches
tommica 2y ago
> If you're doing auth in 2024, please consider not supporting passwords. And then realize that you need to support them, because they are the most universal solution there is for an average user. Email/Username + Password is the most portable way to do login as a user that we have invented.
- LoganDark 2y ago
  Email + magic link is a pattern I keep seeing that's far more secure in practice. So is email + email OTP. (I've also seen phone + phone OTP, but oh please never ask me for a phone number ever again. My phone number should always only be for making and receiving calls, not for verifying any sort of identity or personhood.) Of course, nothing beats the security and privacy of username + password + TOTP (or security key), but you can't necessarily expect normal users to know to do that (or how). Hell, I've seen at least one site that keeps the login username (what you actually use to sign into your account) separate from the public username (what everyone else sees), just to even more disconnect the login credentials from anything a potential attacker would have access to. But this is overkill for most scenarios (that particular platform does have a good reason).
  - tommica 2y ago
    I find it problematic if I do not have access to my email in the moment, or there is a glitch in the flow and I need to wait for the mail for some minutes, but that can also happen during 2FA, if email is used for that. Also, magic links need to be designed so that I can login on my PC, and click the link on my phone, and be logged in on the PC. Though I've really enjoyed using QR codes to login, that has been a really smooth modern experience.
    - simonw 2y ago
      "Also, magic links need to be designed so that I can login on my PC, and click the link on my phone, and be logged in on the PC." I feel that way too - I hate it when I'm trying to log in on desktop and the email shows up as a push notification on my phone. The problem is what happens if someone enters someone else's email address and that person unwittingly clicks on the "approve" link in the email they receive. That only has to happen once for an account to be compromised. So now you need "enter the 4 digit code we emailed you" or similar, which feels a whole lot less magical than clicking on a magic link. Presumably there are well documented patterns for addressing this now? I've not spent enough time implementing magic links to have figured that out.
      - stickfigure 2y ago
        > someone enters someone else's email address and that person unwittingly clicks on the "approve" link Eh? In a sane magic link system, clicking the magic link grants the clicker access to the account. Right then and there, in the browser that opened the link.
        philsnow 2y ago
        I would argue that a magic link system has to only allow the click-through to grant access on the machine that initiated the login flow. If I enter my email in SomeSite, they send a magic link to my email address, and then Mallory intercepts that email and gains access to my SomeSite account just by opening the link (i.e. the link acts as a bearer token), that's completely broken.
  - 9dev 2y ago
    > Email + magic link is a pattern I keep seeing that's far more secure in practice. I absolutely despise this. Every time I want to quickly log into an app and check something, just to sit in front of my synchronising mail client, wondering if the email will arrive, be caught by the spam filter, or just have random delay of a few minutes. Awful.
    - LoganDark 2y ago
      I hate it too. I always prefer TOTP. I never said this isn't shitty. Just that for normal users, it's more secure than passwords.
      - jonjojojon 2y ago
        I first saw this with Anthropic. I clear my browser pretty regularly and this flow just adds so much friction. With a password manager plus totp I never really felt burdened by logging in every time I used a service. I hope this doesn't catch on.
    - efitz 2y ago
      If the authentication session is long-lived then this is usually not too onerous; one round trip the first time you use it. It’s a nightmare if they also insist on short lived sessions.
  - godelski 2y ago
    > Of course, nothing beats the security and privacy of username + password + TOTP (or security key), but you can't necessarily expect normal users to know to do that (or how). Honestly, this just seems like a UX problem. The ways this is currently implemented are often terrible, but not always. I'll give an example: I recently did a stint at "Green company" and they gave me a yubi key. They also used Microsoft for most things. To login with Microsoft authenticator I type in my username and password, click yes on the next page, and then click yes on my phone. But to use the yubi key was needlessly frustrating. First, Microsoft doesn't let you use it as the default method (hardware key). So then you have to click "use another form of authentication", "hardware key", "next" (why? Idk), and then finally you pin and tap the key. A bunch of needless steps there and I'm not convinced this wasn't intentional. There's other services I've used working at other places where it's clean and easy: username + password, then pin+ tap key (i.e. hardware key is default!). I seriously think a lot of security issues come down to UX. There's an old joke about PGP How do you decrypt a PGP encrypted email? You reply to the sender "can't decrypt, can you send it back in clear?" It was a joke about the terrible UX. That it was so frustrating that this outcome was considered normal. But hey, we actually have that solved now. Your Gmail emails are encrypted. You have services like Whatsapp and Signal that are E2EE. What was the magic sauce? UI & UX. They are what make the tools available to the masses, otherwise it's just for the nerds.
  - philsnow 2y ago
    > nothing beats the security and privacy of username + password + TOTP (or security key) security key is at least somewhat better than TOTP because it's not (or less-)phishable
  - ttepasse 2y ago
    > Email + magic link Two scenarios I had recently, where I absolutely, utterly hated this pattern: * I did not remember the mail address for such a thing because I started (too late) to use a different mail address for every service, thanks to Apples iCloud hidden addresses. And because there was no corresponding password, there was no entry in my password manager. I since rectified that, but it’s annoying. * I tried to login on an older Windows PC - the magic mail landed on my iPhone. And because cross-system technical standards are a thing of the past the only possibility to get the magic link to the other system was to transcribe it.
  - degrees57 2y ago
    I'm not a fan of email + magic link. I know of two security gateways which "click" on the link to check to see if it ends up going to a known malicious website. So then the end user calls in a trouble ticket, because the login authorization page says their magic link is already expired (before they even got it). So for me, email + email OTP is the way to go.
- jenny91 2y ago
  Yes, made this mistake in the past. Every project has some amount of "being quirky/different" capital. If your project is not explicitly trying to innovate, or does not for some particular reason need to be very secure, then do not spend that capital on confusing users with the login flow. You'll turn a bunch of users away and cause a whole lot of support tickets, for very little benefit. Make users only think about stuff by making it unintuitive or different if it's really worth it to your product.
  - littlestymaar 2y ago
    I wish I could upvote more than once!
- miki123211 2y ago
  Email + magic link is a lot better for most use cases. It's a lot simpler to implement (just one flow instead of signin / signup / forgot), less catastrophic when your data is breached, piggybacks on the significant amount of work that already goes into securing email, gives you 90% of the benefits of 2FA / FIDO / Web Authn / whatever for free with 0 implementation cost, makes account sharing harder (good for business), and is easy to extend/replace with oAuth for specific domains.
  - Quothling 2y ago
    > Email + magic link is a lot better for most use cases. Wouldn't systems like this put a lot of trust on their users? Say you use a magic link on an compromised wifi network, like in a hotel, coffee shop, airport and so on without being on a VPN. Which some users will inevitable do. I completely agree with the "most use cases" though. As long as you can't change the associated e-mail without additional requirements.
    - vaylian 2y ago
      After you have logged in, you will get a session cookie/key that you have to send on every request. An adversary can just steal that session key from the compromised connection.
    - mwwaters 2y ago
      https end-to-end encrypts what’s in the address, except for the domain.
  - littlestymaar 2y ago
    And that's also a great way to piss the user off…
  - portaouflop 2y ago
    Is actively avoid services that only offer magic link Auth - it’s the most annoying shitty method that pushes all the work on me. No I won’t log into my email multiple times per day because you are too lazy to hash passwords. It always depends on the audience but if your users are somewhat technically literate you need passwords.
swatcoder 2y ago
Better advice is to be honest about your product/project's social scope and make appropriate choices for that scope, or else let your users make that choice for themselves. The world is not improved or made more robust if every experience online must be gated through some third-party vendor's physical widget (or non-trivial software). There are parts of our lives that benefit from the added securiry that comes alongside that brittleness and commercial dependence, and parts that don't. Let's not pretend otherwise.
godelski 2y ago
I hate this take. I understand it and I don't want OAuth2 to not exist, but it isn't a *replacement*. There are two critical things you lose with OAuth. First, it's centralization so you must trust that player and well now if that account is compromised everything down steam is (already a problem with email, who are the typical authorities). Second is privacy. You now tell those players that you use said service. Let me tell you as a user another workflow. If you use bitwarden you can link Firefox relay, to auto generate relay email addresses. Now each website has not only a unique password, but a unique email. This does wonders for spam and determining who sells your data, AND makes email filters much more useful for organization. The problem? Terrible UX. Gotta click a lot of buttons and you destroy your generated password history along the way (if you care). No way could I get my parents to do this, let alone my grandma (the gold standard of "is it intuitive?" E.g Whatsapp: yes; Signal: only if someone else does the onboarding). There's downsides of course. A master password, but you do control. At least the password manager passes the "parent test" and "girlfriend test", and they even like it! It's much easier to get them (especially parents) to that one complicated master passphrase that the can write down and put in a safe. A lot of security (and privacy) problems are actually UI/UX problems. (See PGP) OAuth recognized this, but it makes a trade with privacy. I think this can be solved in a better way. But at minimum, don't take away password as an option.
- jpc0 2y ago
  You are assuming a lot about who your oAuth provider is... Sure many places only implement Google/Meta/Githun/Discord etc but that's not a requirement, specially for your own app. You can implement and run your own oAuth server if you so wished, much good it would be. But regardless, that's why FIDO2 and webAuthN was developed, but even that has it's issues.
  - godelski 2y ago
    > You are assuming a lot about who your oAuth provider is > Sure many places only implement This doesn't change my concern, but yes, it deepens it. Sure, I known there can be an arbitrary authority, but does it matter when 90% don't allow another authority? I can't think of more than once I have seen another authority listen.
efitz 2y ago
> Most people will never use a password manager Prediction: in 10 years nearly everyone will be using a password manager; it will come with their OS (Android or iOS) with browser plugins for other OS’s, and the integration with mobile apps and mobile web will be so tight that people will not even realize they are using passwords, most of the time. Apple just massively revamped their own manager in the latest iOS release. They already have pretty good integration with mobile web and with App Store apps. In the next couple of years I expect to see pw manager integration made a firm requirement for App Store apps, and I expect to see web standards for account signup and login that make pw managers reliable. I suspect Google will follow suit although I am not familiar with Android’s capabilities in that area. So in a few years you will not type an email address and password to sign up for things; the OS will prompt you: “foo.com is asking you to sign up, would you like to do this automatically?” and if you respond in the affirmative you’ll get a site-specific email address and password automatically created and stored for you, and that will be used whenever you want to log in. Recovery will shift to a mobile account centric workflow (Apple ID or Google account) rather than email based password reset links. If a data breach is reported the pw manager app can notify you and give you a one-button-click experience to reset your password. The downside is that if you get canceled by Apple or Google it will be a special kind of hell to recover.
- dahousecat 2y ago
  In 10 years time everyone will be using passkeys, not passwords.
  - gomox 2y ago
    Please, for the love of god, no.
  - efitz 2y ago
    Hahahaha good one. I love the idea of passkeys; I hate the experience of passkeys, especially when it comes to having to reach for my phone to log into a desktop web site.
  - homebrewer 2y ago
wg0 2y ago
And I can't get my head around passkeys yet. Haven't switched to them. Haven't developed a clear model of where's my private key exactly how many of them and how to get to them if my camera or fingerprint sensor isn't working etc.
- lovethevoid 2y ago
  Your keys are in your password manager of choice, you can create one per service+manager (eg. your google account can have one passkey using iCloud Keychain, and another one using bitwarden). If you lose access to your PM, the other recovery processes would take place. It might help your mental model to think about them as identical to hardware security keys. Except now you don't need to buy a specific hardware key, your password manager is it. You can also just use your hardware key as your passkey, same thing (as long as the key supports FIDO2). Specifically for your question on what happens if you lose face/fingerprint sensor. So this would be assuming you use Android/iOS's password managers, in that case even with biometrics failing you can just use the code you set on your device as both have fallbacks.
  - jms703 2y ago
    Good explanation, IMO.
  - miki123211 2y ago
    Why did we need a new standard for this, exactly? Couldn't we just make password managers pretend that they're a Jubikey or similar? Is it that Jubikeys don't offer any extra (master password / biometric) authn, and hence are only suitable as a second factor, where password managers can be used as both?
dahousecat 2y ago
You need the password for the lost passkey flow. Well, you don't need it, but it's an extra layer.

canadiantim 2y ago

That seems false. Key-based approaches I understand to be less secure than passwords, albeit of course not if someone is reusing passwords found in breaches

tommica 2y ago

> If you're doing auth in 2024, please consider not supporting passwords. And then realize that you need to support them, because they are the most universal solution there is for an average user. Email/Username + Password is the most portable way to do login as a user that we have invented.

LoganDark 2y ago
Email + magic link is a pattern I keep seeing that's far more secure in practice. So is email + email OTP. (I've also seen phone + phone OTP, but oh please never ask me for a phone number ever again. My phone number should always only be for making and receiving calls, not for verifying any sort of identity or personhood.) Of course, nothing beats the security and privacy of username + password + TOTP (or security key), but you can't necessarily expect normal users to know to do that (or how). Hell, I've seen at least one site that keeps the login username (what you actually use to sign into your account) separate from the public username (what everyone else sees), just to even more disconnect the login credentials from anything a potential attacker would have access to. But this is overkill for most scenarios (that particular platform does have a good reason).
- tommica 2y ago
  I find it problematic if I do not have access to my email in the moment, or there is a glitch in the flow and I need to wait for the mail for some minutes, but that can also happen during 2FA, if email is used for that. Also, magic links need to be designed so that I can login on my PC, and click the link on my phone, and be logged in on the PC. Though I've really enjoyed using QR codes to login, that has been a really smooth modern experience.
  - simonw 2y ago
    "Also, magic links need to be designed so that I can login on my PC, and click the link on my phone, and be logged in on the PC." I feel that way too - I hate it when I'm trying to log in on desktop and the email shows up as a push notification on my phone. The problem is what happens if someone enters someone else's email address and that person unwittingly clicks on the "approve" link in the email they receive. That only has to happen once for an account to be compromised. So now you need "enter the 4 digit code we emailed you" or similar, which feels a whole lot less magical than clicking on a magic link. Presumably there are well documented patterns for addressing this now? I've not spent enough time implementing magic links to have figured that out.
    - stickfigure 2y ago
      > someone enters someone else's email address and that person unwittingly clicks on the "approve" link Eh? In a sane magic link system, clicking the magic link grants the clicker access to the account. Right then and there, in the browser that opened the link.
      - philsnow 2y ago
        I would argue that a magic link system has to only allow the click-through to grant access on the machine that initiated the login flow. If I enter my email in SomeSite, they send a magic link to my email address, and then Mallory intercepts that email and gains access to my SomeSite account just by opening the link (i.e. the link acts as a bearer token), that's completely broken.
- 9dev 2y ago
  > Email + magic link is a pattern I keep seeing that's far more secure in practice. I absolutely despise this. Every time I want to quickly log into an app and check something, just to sit in front of my synchronising mail client, wondering if the email will arrive, be caught by the spam filter, or just have random delay of a few minutes. Awful.
  - LoganDark 2y ago
    I hate it too. I always prefer TOTP. I never said this isn't shitty. Just that for normal users, it's more secure than passwords.
    - jonjojojon 2y ago
      I first saw this with Anthropic. I clear my browser pretty regularly and this flow just adds so much friction. With a password manager plus totp I never really felt burdened by logging in every time I used a service. I hope this doesn't catch on.
  - efitz 2y ago
    If the authentication session is long-lived then this is usually not too onerous; one round trip the first time you use it. It’s a nightmare if they also insist on short lived sessions.
- godelski 2y ago
  > Of course, nothing beats the security and privacy of username + password + TOTP (or security key), but you can't necessarily expect normal users to know to do that (or how). Honestly, this just seems like a UX problem. The ways this is currently implemented are often terrible, but not always. I'll give an example: I recently did a stint at "Green company" and they gave me a yubi key. They also used Microsoft for most things. To login with Microsoft authenticator I type in my username and password, click yes on the next page, and then click yes on my phone. But to use the yubi key was needlessly frustrating. First, Microsoft doesn't let you use it as the default method (hardware key). So then you have to click "use another form of authentication", "hardware key", "next" (why? Idk), and then finally you pin and tap the key. A bunch of needless steps there and I'm not convinced this wasn't intentional. There's other services I've used working at other places where it's clean and easy: username + password, then pin+ tap key (i.e. hardware key is default!). I seriously think a lot of security issues come down to UX. There's an old joke about PGP How do you decrypt a PGP encrypted email? You reply to the sender "can't decrypt, can you send it back in clear?" It was a joke about the terrible UX. That it was so frustrating that this outcome was considered normal. But hey, we actually have that solved now. Your Gmail emails are encrypted. You have services like Whatsapp and Signal that are E2EE. What was the magic sauce? UI & UX. They are what make the tools available to the masses, otherwise it's just for the nerds.
- philsnow 2y ago
  > nothing beats the security and privacy of username + password + TOTP (or security key) security key is at least somewhat better than TOTP because it's not (or less-)phishable
- ttepasse 2y ago
  > Email + magic link Two scenarios I had recently, where I absolutely, utterly hated this pattern: * I did not remember the mail address for such a thing because I started (too late) to use a different mail address for every service, thanks to Apples iCloud hidden addresses. And because there was no corresponding password, there was no entry in my password manager. I since rectified that, but it’s annoying. * I tried to login on an older Windows PC - the magic mail landed on my iPhone. And because cross-system technical standards are a thing of the past the only possibility to get the magic link to the other system was to transcribe it.
- degrees57 2y ago
  I'm not a fan of email + magic link. I know of two security gateways which "click" on the link to check to see if it ends up going to a known malicious website. So then the end user calls in a trouble ticket, because the login authorization page says their magic link is already expired (before they even got it). So for me, email + email OTP is the way to go.
jenny91 2y ago
Yes, made this mistake in the past. Every project has some amount of "being quirky/different" capital. If your project is not explicitly trying to innovate, or does not for some particular reason need to be very secure, then do not spend that capital on confusing users with the login flow. You'll turn a bunch of users away and cause a whole lot of support tickets, for very little benefit. Make users only think about stuff by making it unintuitive or different if it's really worth it to your product.
- littlestymaar 2y ago
  I wish I could upvote more than once!
miki123211 2y ago
Email + magic link is a lot better for most use cases. It's a lot simpler to implement (just one flow instead of signin / signup / forgot), less catastrophic when your data is breached, piggybacks on the significant amount of work that already goes into securing email, gives you 90% of the benefits of 2FA / FIDO / Web Authn / whatever for free with 0 implementation cost, makes account sharing harder (good for business), and is easy to extend/replace with oAuth for specific domains.
- Quothling 2y ago
  > Email + magic link is a lot better for most use cases. Wouldn't systems like this put a lot of trust on their users? Say you use a magic link on an compromised wifi network, like in a hotel, coffee shop, airport and so on without being on a VPN. Which some users will inevitable do. I completely agree with the "most use cases" though. As long as you can't change the associated e-mail without additional requirements.
  - vaylian 2y ago
    After you have logged in, you will get a session cookie/key that you have to send on every request. An adversary can just steal that session key from the compromised connection.
  - mwwaters 2y ago
    https end-to-end encrypts what’s in the address, except for the domain.
- littlestymaar 2y ago
  And that's also a great way to piss the user off…
- portaouflop 2y ago
  Is actively avoid services that only offer magic link Auth - it’s the most annoying shitty method that pushes all the work on me. No I won’t log into my email multiple times per day because you are too lazy to hash passwords. It always depends on the audience but if your users are somewhat technically literate you need passwords.

swatcoder 2y ago

Better advice is to be honest about your product/project's social scope and make appropriate choices for that scope, or else let your users make that choice for themselves. The world is not improved or made more robust if every experience online must be gated through some third-party vendor's physical widget (or non-trivial software). There are parts of our lives that benefit from the added securiry that comes alongside that brittleness and commercial dependence, and parts that don't. Let's not pretend otherwise.

godelski 2y ago

I hate this take. I understand it and I don't want OAuth2 to not exist, but it isn't a *replacement*. There are two critical things you lose with OAuth. First, it's centralization so you must trust that player and well now if that account is compromised everything down steam is (already a problem with email, who are the typical authorities). Second is privacy. You now tell those players that you use said service. Let me tell you as a user another workflow. If you use bitwarden you can link Firefox relay, to auto generate relay email addresses. Now each website has not only a unique password, but a unique email. This does wonders for spam and determining who sells your data, AND makes email filters much more useful for organization. The problem? Terrible UX. Gotta click a lot of buttons and you destroy your generated password history along the way (if you care). No way could I get my parents to do this, let alone my grandma (the gold standard of "is it intuitive?" E.g Whatsapp: yes; Signal: only if someone else does the onboarding). There's downsides of course. A master password, but you do control. At least the password manager passes the "parent test" and "girlfriend test", and they even like it! It's much easier to get them (especially parents) to that one complicated master passphrase that the can write down and put in a safe. A lot of security (and privacy) problems are actually UI/UX problems. (See PGP) OAuth recognized this, but it makes a trade with privacy. I think this can be solved in a better way. But at minimum, don't take away password as an option.

jpc0 2y ago
You are assuming a lot about who your oAuth provider is... Sure many places only implement Google/Meta/Githun/Discord etc but that's not a requirement, specially for your own app. You can implement and run your own oAuth server if you so wished, much good it would be. But regardless, that's why FIDO2 and webAuthN was developed, but even that has it's issues.
- godelski 2y ago
  > You are assuming a lot about who your oAuth provider is > Sure many places only implement This doesn't change my concern, but yes, it deepens it. Sure, I known there can be an arbitrary authority, but does it matter when 90% don't allow another authority? I can't think of more than once I have seen another authority listen.

efitz 2y ago

> Most people will never use a password manager Prediction: in 10 years nearly everyone will be using a password manager; it will come with their OS (Android or iOS) with browser plugins for other OS’s, and the integration with mobile apps and mobile web will be so tight that people will not even realize they are using passwords, most of the time. Apple just massively revamped their own manager in the latest iOS release. They already have pretty good integration with mobile web and with App Store apps. In the next couple of years I expect to see pw manager integration made a firm requirement for App Store apps, and I expect to see web standards for account signup and login that make pw managers reliable. I suspect Google will follow suit although I am not familiar with Android’s capabilities in that area. So in a few years you will not type an email address and password to sign up for things; the OS will prompt you: “foo.com is asking you to sign up, would you like to do this automatically?” and if you respond in the affirmative you’ll get a site-specific email address and password automatically created and stored for you, and that will be used whenever you want to log in. Recovery will shift to a mobile account centric workflow (Apple ID or Google account) rather than email based password reset links. If a data breach is reported the pw manager app can notify you and give you a one-button-click experience to reset your password. The downside is that if you get canceled by Apple or Google it will be a special kind of hell to recover.

dahousecat 2y ago
In 10 years time everyone will be using passkeys, not passwords.
- gomox 2y ago
  Please, for the love of god, no.
- efitz 2y ago
  Hahahaha good one. I love the idea of passkeys; I hate the experience of passkeys, especially when it comes to having to reach for my phone to log into a desktop web site.
- homebrewer 2y ago

wg0 2y ago

And I can't get my head around passkeys yet. Haven't switched to them. Haven't developed a clear model of where's my private key exactly how many of them and how to get to them if my camera or fingerprint sensor isn't working etc.

lovethevoid 2y ago
Your keys are in your password manager of choice, you can create one per service+manager (eg. your google account can have one passkey using iCloud Keychain, and another one using bitwarden). If you lose access to your PM, the other recovery processes would take place. It might help your mental model to think about them as identical to hardware security keys. Except now you don't need to buy a specific hardware key, your password manager is it. You can also just use your hardware key as your passkey, same thing (as long as the key supports FIDO2). Specifically for your question on what happens if you lose face/fingerprint sensor. So this would be assuming you use Android/iOS's password managers, in that case even with biometrics failing you can just use the code you set on your device as both have fallbacks.
- jms703 2y ago
  Good explanation, IMO.
- miki123211 2y ago
  Why did we need a new standard for this, exactly? Couldn't we just make password managers pretend that they're a Jubikey or similar? Is it that Jubikeys don't offer any extra (master password / biometric) authn, and hence are only suitable as a second factor, where password managers can be used as both?

dahousecat 2y ago

You need the password for the lost passkey flow. Well, you don't need it, but it's an extra layer.