Hacker News Reader

Comment by sebastiennight | Hacker News Reader

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.

View on HN

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).

The number of support requests I got last year because of [hotmail|gmail|msn|yahoo].con > 30

I just auto switch any incoming .con to .com on the back end. 100% of the time it is a user typo

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.

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.

Nice trick! I check on the frontend for all gmal, gmial, etc variations :)

> I check on the frontend

This is the way. The user can benefit from feedback that they got something wrong, in addition to a helping hand.

A couple of years ago I think I saw a frontend library that warned the user / auto-fixed those typos, but I can't remember its name, and all I can find now are SaaS offers for that kind of service.

Which I'm not entirely enthusiastic about as it leaks all user emails to some random service.

Wouldn't privacy aware users prefer passkeys or passwords, instead of any kind of SSO?

In general, I do understand that use of SSO is due to convenience. Especially since in many cases websites provide less friction when signing up via SSO instead of using username+password.

Believe it or not, most users are not that privacy cautious

That would be my guess too. I think convenience always win.

> 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

I do it for services I don't care about. In my mind it is more privacy for me. Keeps you out of my real inbox and my password out of your system and I believe that I can - to some extend - remove myself without having to go through whatever crap account deletion process that services has tried to cobble together.

Worst offenders let me login with google and then immediately asks for name and phone number or email and asks me to verify it.

> my password out of your system

This shouldn't be a factor because your password should be a random series of characters that are unique to that site.

> I believe that I can - to some extend - remove myself without having to go through whatever crap account deletion process that services has tried to cobble together.

To an absolute minimal extent: you can make it so Google won't tell them whatever it was they already told them again. But you can't make them delete the data that they already lifted from your Google account.

For keeping surfaces out of your inbox, that's what email aliases are really good for. Register with an alias and then block that alias if they abuse it.

I have my HN username at a venerable webmail service. I check it about once a year, tops. My name isn't unimaginably rare, but neither is it "Smith".

I am shocked, shocked, by the number of different K. Strauser people who have typed that email address into some random website or another. I've gotten bank notifications, loan documents, Facebook signup info, meeting minutes from some random volunteer work, and all kinds of other things. When I can figure out from context who the intended recipient is, I try to let them know so they can fix it. On one occasion, the person sent me back a swear-laden diatribe for "hacking their email". Sigh.

I think this has made me a better engineer, though. When someone says something in a meeting like "...as long as they type their email correctly", I can jump in and address that myth head-on. No, people will not type it correctly. If it's a minor pain in the neck for me, with an uncommon name, I can only imagine the traffic that the world's John Smith's get.

Same issue. I've had university professors put my email address in their sylabus instead of ____.edu, and been carpet bombed by assignments, excuses, and pleading diatribes.

I'm listed as the email address for _many_ utility bills, doctors offices, and more political campaigns than I can count.

Comical how many people mess up their own email address.

I just don't get it. A legitimate typo I can see, sure, but so many of the things I get looks like someone said "email address? I guess I can just pick one!"

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

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

... but the usability is a nightmare.

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

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.

With password reset, you are also trusting email.

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...)

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.

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.

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.

In my country even the social security number of people is public information.

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.

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!

Reply on news.ycombinator.com