5 ms·

We've been using Magic Links for a few years (and yes, one reason was to avoid the security issue of storing user passwords when we were just at MVP stage) and

We've been using Magic Links for a few years (and yes, one reason was to avoid the security issue of storing user passwords when we were just at MVP stage) and found the top problems with it are: 1. Some users (0.1%) just don't ever get the email. We tried sending from our IP, sending from MailGun, sending from PostMark, having a multi-tier retry from different transactional tools. Still, some people just will not ever be able to log in. 2. People click old Magic Links and get frustrated when a 6-month old link "doesn't work". We've decided to remedy that by showing them a page that re-sends the link and explains the situation (like Docusign does) instead of an error message. 3. People will routinely mis-spell their email and then blame the system when they don't get the code. All of this still results, I feel, in way fewer support tickets than the email+password paradigm, so I'm still in favor of Magic links.

cchance 2y ago
Funny part is most of those apply to passwords too, using an old password and complaining its not working, mistyping shit and complaining that its the system, and requesting a password reset and not getting the mail LOL so i only see upsides
tjoff 2y ago
... but the usability is a nightmare.
- graemep 2y ago
  Absolutely. Users have to wait for the email before signing in, it does not work on devices without email without copying the link, etc.
255kb 2y ago
It's indeed interesting the number of people misspelling their email address, or having an inbox so full that it cannot receive emails anymore. I never tried to add magix links, but I added Google Sign in to my SaaS several month ago, and since then, it accounts for more than 90% of new sign-ups (users are devs, so rather tech savvy and privacy aware). I'm now convinced that no other method is a priority (I still have email/password of course).
- yvoschaap 2y ago
  The number of support requests I got last year because of [hotmail|gmail|msn|yahoo].con > 30
  - revicon 2y ago
    I just auto switch any incoming .con to .com on the back end. 100% of the time it is a user typo
    - andy800 2y ago
      Just a very small detail, but want to point out the distinction between these two comments. "Revicon" is demonstrating 10x thinking, it's not about being better at rewriting a linked list algorithm or some leetcode challenge. Player 1 gets the same support request over and over, does nothing about it, ("hey, that's what the user entered, they should be more careful!"), complains about it online, and who knows how many hours are wasted in the back and forth with the customers. Player 2 simply makes the necessary change on the backend, the users don't even realize they made a typo, totally seamless flow. Hat tip to you. Hope you screenshot these two comments and bring this up in every interview to exemplify the contrast between "technically correct" and high-efficiency problem solving.
      - pixelsort 2y ago
        A tasteful post and distinction well highlighted. Humorously, Yvo Schaap is no stranger to 10x thinking. For one thing, Yvo publishes diagrams on SaaS/dev topics that always seem consistently way ahead of their time in terms of their organization and completeness.
    - 255kb 2y ago
      Nice trick! I check on the frontend for all gmal, gmial, etc variations :)
      - bshacklett 2y ago
watermelon0 2y ago
Email should not be considered a secure channel. Username+password (or passkeys) with a password manager (which ensures that credentials are used on the correct domain) via HTTPS is probably the only end-to-end encrypted way of exchanging credentials with good UX for general public.
- danenania 2y ago
  With password reset, you are also trusting email.
  - gepeto42 2y ago
    Even with passkeys or TOTP 2FA, we've decided email is the root, for better or for worse (for people with gmail, it's likely better than SMS would be on a crappy carrier, but it depends on so many factors, including how many hundred apps have Gmail read access via OAuth...)
- Jolter 2y ago
  If you are storing sensitive information in the system, by all means, you should act accordingly and require higher-security login than magic links. But if you do, you really should not be accepting username+password either. You need to at least put some 2FA on there to step up one level of security. And not SMS- or email-based 2FA either. 90% of web apps don't handle that kind of information, and for them a magic link is at least as good as passwords (as this article explains). Those that do handle things like personally identifiable information (beyond an email address) really should be enforcing 2FA or proper electronic IDs. There is a whole profession writing recommendations about information security, and every web developer needs to be able to do this kind of analysis at a rudimentary level. We don't need to wing it, we can analyze security requirements in a systematic way.
flessner 2y ago
Also what's the reasoning behind not wanting to store passwords? It's not like the rest of the customer's data is not valuable? If you don't feel comfortable storing passwords, the amount of data I'd trust you with is strictly zero.
- danenania 2y ago
  The UX debate is valid, but magic links (and emailed one-time codes) are clearly more secure than password + password reset. Control of the email account gets you in either way. Passwords are an additional attack vector.
- Kiro 2y ago
  In my country even the social security number of people is public information.
- gepeto42 2y ago
  To be fair to 404, they're trying to limit the amount of data they hold which IS good, but in the end they need to have the email address of subscribers.
- lolinder 2y ago
  No, kudos to them for looking at a piece of data and asking themselves if it's worth storing—more companies should do that with more data. It's not that the rest of the data isn't valuable to some extent, it's that every piece you have makes the blast radius of a leak that much bigger, so why hold stuff you don't need? Planning for a breach doesn't make you more likely to have one—if anything it makes you less likely!
skerit 2y ago
Magic links can be very useful, but for some users the issue is in only supporting magic links.

cchance 2y ago

Funny part is most of those apply to passwords too, using an old password and complaining its not working, mistyping shit and complaining that its the system, and requesting a password reset and not getting the mail LOL so i only see upsides

tjoff 2y ago

... but the usability is a nightmare.

graemep 2y ago
Absolutely. Users have to wait for the email before signing in, it does not work on devices without email without copying the link, etc.

255kb 2y ago

It's indeed interesting the number of people misspelling their email address, or having an inbox so full that it cannot receive emails anymore. I never tried to add magix links, but I added Google Sign in to my SaaS several month ago, and since then, it accounts for more than 90% of new sign-ups (users are devs, so rather tech savvy and privacy aware). I'm now convinced that no other method is a priority (I still have email/password of course).

yvoschaap 2y ago
The number of support requests I got last year because of [hotmail|gmail|msn|yahoo].con > 30
- revicon 2y ago
  I just auto switch any incoming .con to .com on the back end. 100% of the time it is a user typo
  - andy800 2y ago
    Just a very small detail, but want to point out the distinction between these two comments. "Revicon" is demonstrating 10x thinking, it's not about being better at rewriting a linked list algorithm or some leetcode challenge. Player 1 gets the same support request over and over, does nothing about it, ("hey, that's what the user entered, they should be more careful!"), complains about it online, and who knows how many hours are wasted in the back and forth with the customers. Player 2 simply makes the necessary change on the backend, the users don't even realize they made a typo, totally seamless flow. Hat tip to you. Hope you screenshot these two comments and bring this up in every interview to exemplify the contrast between "technically correct" and high-efficiency problem solving.
    - pixelsort 2y ago
      A tasteful post and distinction well highlighted. Humorously, Yvo Schaap is no stranger to 10x thinking. For one thing, Yvo publishes diagrams on SaaS/dev topics that always seem consistently way ahead of their time in terms of their organization and completeness.
  - 255kb 2y ago
    Nice trick! I check on the frontend for all gmal, gmial, etc variations :)
    - bshacklett 2y ago

watermelon0 2y ago

Email should not be considered a secure channel. Username+password (or passkeys) with a password manager (which ensures that credentials are used on the correct domain) via HTTPS is probably the only end-to-end encrypted way of exchanging credentials with good UX for general public.

danenania 2y ago
With password reset, you are also trusting email.
- gepeto42 2y ago
  Even with passkeys or TOTP 2FA, we've decided email is the root, for better or for worse (for people with gmail, it's likely better than SMS would be on a crappy carrier, but it depends on so many factors, including how many hundred apps have Gmail read access via OAuth...)
Jolter 2y ago
If you are storing sensitive information in the system, by all means, you should act accordingly and require higher-security login than magic links. But if you do, you really should not be accepting username+password either. You need to at least put some 2FA on there to step up one level of security. And not SMS- or email-based 2FA either. 90% of web apps don't handle that kind of information, and for them a magic link is at least as good as passwords (as this article explains). Those that do handle things like personally identifiable information (beyond an email address) really should be enforcing 2FA or proper electronic IDs. There is a whole profession writing recommendations about information security, and every web developer needs to be able to do this kind of analysis at a rudimentary level. We don't need to wing it, we can analyze security requirements in a systematic way.

flessner 2y ago

Also what's the reasoning behind not wanting to store passwords? It's not like the rest of the customer's data is not valuable? If you don't feel comfortable storing passwords, the amount of data I'd trust you with is strictly zero.

danenania 2y ago
The UX debate is valid, but magic links (and emailed one-time codes) are clearly more secure than password + password reset. Control of the email account gets you in either way. Passwords are an additional attack vector.
Kiro 2y ago
In my country even the social security number of people is public information.
gepeto42 2y ago
To be fair to 404, they're trying to limit the amount of data they hold which IS good, but in the end they need to have the email address of subscribers.
lolinder 2y ago
No, kudos to them for looking at a piece of data and asking themselves if it's worth storing—more companies should do that with more data. It's not that the rest of the data isn't valuable to some extent, it's that every piece you have makes the blast radius of a leak that much bigger, so why hold stuff you don't need? Planning for a breach doesn't make you more likely to have one—if anything it makes you less likely!

skerit 2y ago

Magic links can be very useful, but for some users the issue is in only supporting magic links.