Hacker News Reader

Comment by simonw | Hacker News Reader

A general rule of thumb I've built up over the years: resist the temptation to innovate around login!

Look at the most commonly used flows that are not obviously terrible and try to implement as close a match to them as possible.

When I've tried to innovate around login in the past I've found that any clever ideas I come up with inevitably run into road blocks pretty quickly.

Here's one example: why have a separate login form from a signup form? They both involve asking the user for an email and password, why not have one form that can do either depending on if the user's account already exists?

I quickly learned why: if you don't understand the user's intent when they submitted that form, you can't show them error messages that match their mental model as to what is going on. This makes for an incredibly confusing experience the moment you step off the happy path.

----

That's not to say it's not interesting and valuable to think through new login mechanisms. They're very interesting design challenges! But its good to be prepared to find out that vanishingly few innovative ideas will work out as genuine improvements.

View on HN

That’s what I used to believe. Circa 2000 the advice was ‘do what Yahoo! does’ and that was good, but when I revisited that in 2006 I found that Yahoo’s signup and login process was deformed by the need to discourage users from responding to phishing attempts —- a bank needs to be concerned about this but it will hurt the login for other sites that have higher iq users and aren’t big enough that spamming everybody is a good tactic.

I worked on one site (a chat service for Brazil) that had a 20% success rate for the login flow at first that we got up to the high 80s by tweaking this and that. Later I worked on one aimed at scientists that was in the low 80s before optimization.

Some tweaks from a long time ago are:

1. Put something like ‘we sent a message to <b>your.email@somewhere.net</b>‘ on the post-registration form where they are likely to see it if they make a mistake. Today forms are likely to ask for your email twice to catch this, annoying as it is.

2. Put a form field for the registration code on that form, we found that oriented people towards looking for a registration code. We still sent a link to click on but we found that users preferred to type the code into the form which was fine with us because they succeeeded.

3. Always store the current URL that the person clicked ‘register’ on and store it in the database so they end up where they started after the process is complete.

When I started on my first project as a junior engineer I thought I was being clever to build an app without any passwords: every time you wanted to login you received a new email with a link to log you in. Technically, this worked great but after a while I received many complaints from frustrated users who kept looking for the “signup form”…

You can solve this problem without a signup form.

Just give the user two links: sign up and log in. Both ask for email address first. The next screen tells them to check their email.

You can use unusual flows without confusing users as long as you give them cues about how to do what they're trying to do.

That doesn’t solve the issue of passwordless login, though, which is the fact not everyone has access to their email on every device at all times.

Need to check something attached to a work email (hello Slack) but purposefully not got work email set up on your personal device? Good luck

It's not only having "access to your emails", sometimes these services will send links that are supposed to open in an app and do something there.

... and it just doesn't work.

Want to log in on your TV?

Ha. Good luck with that. Your email provider probably only supports Chrome.

> Need to check something attached to a work email (hello Slack) but purposefully not got work email set up on your personal device?

This isn't worse or different than SSO, which your work should be enforcing anyway.

ImprovMX does this just fine

ImprovMX was extremely confusing to me at first.

Checking your email for the login link was confusing?

I hate the email login link stuff, and any site that has it as the only option, I move on unless absolutely forced to use it.

Especially a pain if I'm trying to login on a device without my email.

You don't need to have email on the device you are logging in from

Can take out phone and click link

> Can take out phone and click link

That assumes you have that email account on your phone. Also that you have your phone with you, that your phone has signal / wifi, there's no delays, no greylisting, no spam filtering that might catch the email, ...

There's just too many simple ways it can break down for it to be a good system.

Okay, but what if you don't know your password and your password manager is offline or you don't have access to it on your phone or the phone ran out of battery or... I assure you we can find a similar amount of cases where passwords would fail. It's mostly novelty phobia.

We're used to one way of working and have our setups for that. We don't want something different but not because it's worse. It's just different.

And even more, when you have a problem with your password, what do you have to do, yes, email for the most part.

Some of the ones that doesn’t work - it logs you in on your phone but not the computer you were trying to login on

On at least half of those services, that ends up with me being logged in on my phone which is decidedly not what I want.

Plus I don't know who's using that to help adtech build their cross device mappings

Email I wanted to use as a login is a totally be a different email than what I wanted to forward to.

Obviously a webmaster knows how a sign up form works.

I didn't know the word webmaster still existed

That's crazy! I was reading the article and kept in mind what we did in ImprovMX and was surprised to see we were mentioned in the comment :D

We did, tried something "original" in the login part, by offering a "one time login link" to our users instead of the standard flow. To be honest, we believe this was a bad idea.

The flow in itself is good and works fine (supposing email delivery works), but as @simonw perfectly said it, "resist the temptation to innovate around login!".

Offering that original "one time login link" is a frequent cause of support request because some users doesn't receive it, doesn't know what to do or how. They are not used to a change on login and this causes more troubles down the road than a standard flow.

That's why we later on decided to add the standard "password" login and tried to reverse that original flow. We still have users that have accounts with no password set though (still connecting via the original "one time login link").

Oh the few websites that do this drive me absolutely crazy. It makes me immediately look for alternatives, it's unbearable

Revolut does this for app logins and it's infuriating when your (new) phone doesn't have the email account used synchronized.

This so much. If some Revoluter reads HN comments, please raise the concern, this is such a PITA.

It assumes that we all have access to our email all of the time. Which is a fair assumption for 99.99% of the population.

But I deliberately keep email off my phone, so I don't look at email on my phone.

So yes, I hate 'passwordless login'. I have a password manager, I can do it myself thanks very much.

You could consider setting up a separate email account just for the verification messages and have that on your phone.

Why should I have to go through all that faff when I have a perfectly good password manager?

> Why should I have to go through all that faff when I have a perfectly good password manager?

If you are not using dedicated special-purpose email addresses with specific services, you're already grossly mismanaging your online safety.

Think about it for a second: how does your password manager help you if your email password gets leaked?

Thats a crazy level of risk assessment for an average user.

> how does your password manager help you if your email password gets leaked?

You still need my TOTP codes in my case at least, which conveniently are stored in my password manager. Is it perfectly secure? No, of course it's not, but frankly my risk profile isn't worrying about a targeted attack on me and my password manager, it's worrying about leaked shared credentials.

Side note, I also get a push notification on my phone whenever a new device logs on, so unless the attack is _extremely_ targeted, well timed and they know what they want, Its not a risk for me.

> Thats a crazy level of risk assessment for an average user.

It really isn't. Think about it for a second: how hard is it to spot phishing attempts when they are sent to an email address you know for a fact you're not using with a service?

And how vulnerable are you to phishing if your special-purpose email address that you only use for one specific purpose receives zero spam?

To claim that the most basic and easy internet security precautions are at a "crazy level", first you need to somehow believe that no one is targeted by these schemes. But somehow there's a whole international industry that thrives on stuff like Western Union transfers. Why is that?

Do you think youre going to get scammed and send a fraudulent Western Union transfer? What do you think the venn diagram overlap between "uses a specific email for each service" and "gets phished" is? The people that even have the capacity to do the first aren't going to fall into the second. If someone is sending fraudelent transfers to scammers, they're not going to be smart enough to create multiple emails.

> Do you think youre going to get scammed and send a fraudulent Western Union transfer?

I know for a fact that there are targeted phishing campaigns aimed at users of specific services such as LinkedIn and GitHub and Twitter and etc, primarily because I've been targeted by them.

> What do you think the venn diagram overlap between "uses a specific email for each service" and "gets phished" is?

I know for a fact that the Venn diagram of phishing attempts sent to email accounts that are not used by those services is practically zero.

Do you understand how trivial it is to identify and filter out these attacks when they are sent to addresses that are already known beforehand that are not used for that purpose?

In 2022 nobody actually clicks links in emails, right?

You are right of course in one sense, but look at the comments here! If the HN crowd is still sending verification links rather than codes to be copy and pasted, that implies regular folks are still clicking the links..

> To claim that the most basic and easy internet security precautions are at a "crazy level",

Basic and easy internet precautions are not "register and run a domain and host your mail yourself". Basic and easy precautions are don't reuse passwords/use a password manager, use a reputable email provider, enable 2fa with totp, and dont click links from your emails

> first you need to somehow believe that no one is targeted by these schemes.

I don't see how you come to that conclusion at all. The assumption is that _everyone_ is targeted by those schemes.

> But somehow there's a whole international industry that thrives on stuff like Western Union transfers. Why is that?

Because they're low risk high reward, easy to set up, and you only need to make one mistake.

>>Think about it for a second

Perhaps instead of telling everyone to think on things for a second, you should think on things for longer than a second?

>And how vulnerable are you to phishing if your special-purpose email address that you only use for one specific purpose receives zero spam?

This would depend on how you setup the email address, if it truly a separate email address i.e a separate account not just an alias then phishing is not the concern but management of the accounts becomes a huge problem

I use separate alias's for every service against my own custom domain that has a single email account. This is not to prevent phishing but to detect when a breach occurred or when my info is sold, you assume that when you sign up for a service only that service will ever have access to your info, many many many companies and service sell your email address to marketers.

Wasn’t suggesting that anyone should - just wanted to suggest a solution to the problem they described.

But they don't have a problem - they just don't use the passwordless sites. If anybody, it's the sites having the problem of missing users.

> But they don't have a problem - they just don't use the passwordless sites.

If nothing else, the idea of having a separate e-mail account/inbox per use case is an interesting one!

Much like those people that use aliases or something of the sort to be able to tell where who sent then a particular email, like if suddenly some shop+my.account@gmail.com started getting random marketing mails.

> If anybody, it's the sites having the problem of missing users.

I mean, isn't that just the consequence of websites optimizing for whatever seems to work for them and forgetting about the minority of users? It might be missed profit, sure, but that depends on just what portion of the users view this as a dealbreaker.

Maybe there could be an app like Google Authenticator that would offer login to multiple websites through one's phone? We already have that in Latvia somewhat, for banking - you enter your user details in the web form and get a prompt on your phone for your PIN to log in with in the web app: https://www.smart-id.com/

What a pain. Nope.

The site would have to have a hell of a value proposition for that to be worth the effort.

"No way! Why should I change? He's the one who sucks."

can you name even one service that uses login links and allows you to configure an address that is exclusively used for login links and not any other communication?

i'm not talking about unselecting all other types of communication, but rather having the service store 2 different emails for you. one for logging in and one for communication.

That is a fair point, indeed this would probably make the configuration page extremely complex. I guess my suggestion would only work for cases where you don’t really care much about other kinds of notifications.

This is ostensibly what WebAuthn will do. It needs to happen, but retraining users is going to be the difficult bit.

I love having my access denied while the email systems delay the email arriving in to my inbox

It's a decent idea! Slack does this, as does a few other services.

Email is not a secure method of communication.

And yet it's surprising how many sites allow you to reset a password using nothing but an email link (single factor authentication - and there are already known cases of emails being silently redirected).

Email os how all password recovery flows work. So your accounts are generally as secure as your Email.

Nor is SMS. Nor a phone call (even a presumed "landline" can be voip, and that can be hacked too).

Here's the truth ; nothing is "secure".

Now... is email more secure than SMS, or less? What about other 2-factor auth things? Is email secure with 2-factor auth?

Amazon does this! Morons will ask you to "click the link in the sms" to "authorise access". I can understand doing this randomly once or twice, for security. But every single time!? Figured they were doing it for two reasons - data-mining (to figure out what mobile phone and mobile browser yo have, and to leave an Amazon cookie on your mobile browser), and to harass you into installing and using the Amazon app instead of the website. Had to call customer support multiple times before this stopped (who kept urging me to install the Amazon app).

Super typical developer thinking :) two pieces of code look the same but are not doing the same things.

I usually see it when people implement add/edit for some entity, that should be separate forms but are crammed into one to be "DRY".

PUT versus POST

This is why views are so nice. You can reuse the view and controller logic and only write a new data model that updates instead of creates (tbh though those can just be two functions on some data model.)

On the contrary, CRUD forms are an ideal candidate for being schema-driven.

The standard login/sign up form is broken, though. People will just use the same password across websites or write it down. You can't win

Use a password manager. Problem solved.

I do and tell people to do the same. Unfortunately we can't force people to actually do it.

Unpopular take: users should be free to use bad and insecure passwords for services they don't care about.

Unfortunately even privileged users (that have authority to change the permissions or possibly passwords of other users) can still use weak passwords. A better solution would be to have your browser prevent you from reusing passwords (it only needs to keep hashes).

If the web browser is governing the passwords you can and can't have, and forcing you to have unmemorisable passwords, you're better off rethinking the whole thing. For instance, it probably makes more sense to ask the web browser to generate keypairs rather than passwords if we know the passwords cannot possibly be memorised.

I don't reuse passwords, or use a password manager. I just have a system for remembering which password to use for each website, and maintain a list of hints. And I have a pretty terrible memory. But having had the password I used to re-use across a few (non- critical) sites show up on haveibeenpwned it's what works best for me.

That turns all users into a greater threat in the case of any bugs in the server. Makes it easier for the service to get DOS'd by authenticated users, and so on. Allowing on user to be more insecure, makes all users more insecure.

\popular take: they shouldn't use services that they don't care about

Password managers are a single point of huge vulnerability.

Unless password managers have a bug bounty of 3m$, then it’s less than the assets I’m protecting with it.

Also, Chrome itself is a password manager.

It’s still better than using the same few passwords everywhere or having a system with the site name. Because you need only on website vulnerability, which is quite common, to compromise your passwords. It’s better to have a single unlikely point of failure than many guaranteed points of failure in my opinion.

Chrome has a password manager but the key is stored for you, which is less secure because it’s not using a HSM (hardware security module) as far as I know.

Your single point will be compromised. Someone gets access to your system they now have access to all of your passwords. Your password manager is hacked. Your device dies. Putting your eggs in one basket feels like a smart thing until you lose that basket.

I agree it’s not perfect but what is your better solution? My email and some passwords have been collected at least 8 times according to https://haveibeenpwned.com/

A password manager with multiple factor authentication sounds better to me.

The different email address per service approach fixes that issue and provides additional privacy when your data is sold to bulk data resellers.

My password manager can only decrypt my passwords via my yubikey. What now?

> Also, Chrome itself is a password manager.

Until the day Google locks your Google Account.

This would only break sync and not access to existing passwords at least, unlike most Google services where you'd be totally SOL

Firefox is great in that regard: when you fill in a signup form it will automatically suggest you a long, generated password, and will then store it for you.

That is not really unique to Firefox, right? Safari does it as well and I am pretty sure Chrome does it too (I am not a Chrome user, so I can't check).

This is news for me. I've been using a local password manager for ages and disabled any browser form support since maybe the last century so I missed all those new functionalities. I'll keep using my password manager anyway, it's not only for the browser and not only for one device. I sync the db across devices with Syncthing, I don't login into any browser cloud sync.

Hopefully this should change over the next few years with both iOS and Android adding support for FIDO Passkeys.

It's not new tech, but now that two huge players have put it in the hands of millions of users, it should pick up speed.

I once built exactly what the author proposed and it worked but confused users a lot because they’d have never experienced it before.

There was a lot more leak in the signup funnel as people would just leave once asked to do something besides giving their (usually auto filled) info.

So I tend to believe trying to generally match the flow they are accustomed to is the best way, even if you think it’s not the best way.

> When I've tried to innovate around login in the past I've found that any clever ideas I come up with inevitably run into road blocks pretty quickly.

Either that or you are throwing roadblocks in your user's way. Even if there is no reason for the most common UX to be the way they are, it is what users are used to, and know how to deal with.

Sounds like a lot of people would accidentally create new accounts.

People do go back to the signup page a lot. Redirecting them when detecting an existing account from the email is enough in the most common cases.

Users doing "clever" stuff like a random email each time, will also probably understand the situation when they go write down which email for which domain they used and see another entry next to it.

There will be some numbers of users that can't be caught and will create many new accounts, but if thwy use your seevice that much, it will probably stop at one point.

Nothing is foolproof, but there can be many ways to mitigate the issue.

There is a site I use that does this. I try and use $sitename@domain.tld as the email for most things I sign up to. Occasionally this gets wonky like the site in question because it was originally a Patreon sub for access so the email for the site was patreon@domain.tld then they switched to their own payment system but my email for them is now locked to patreon@domain.tld.

So when I log in with sitename@domain.tld it thinks it's new account and just signs you up as a new user rather than saying you don't have an account.

Now imagine having a bad day and you try and sign in with 5 different emails because you forgot wha one it was and snow you have 5 different "new account" flows with all the bullshit +12+24+48 hour onboarding/retention/marketing emails for all 5 email addresses.

My fault entirely obviously but it is a little mad.

For your example, this seems bizarre. Every "sign up" process I can think of ends with you being signed into to your new account. Every "log in" process includes a button or link that says "are you a new user, sign up here". You chose a very streamlined thing to worry about.

I'm not sure. A lot end up sending an email that you need to click on to verify.

That's a step of the signup process. AS this article points out, that link ends up with you back in your browser and logged in. In fact, that's probably the most important reason to bring you back to the browser - so you end in the logged in state and can memorize the password in your browser.

100% agree with you. I've gone through the entire journey of experimenting + building my own authentication to using a reliable open source solution.

Been using this passwordless login recipe by supertokens for my recent projects: https://supertokens.com/docs/passwordless/introduction

Re-inventing the wheel calls for a lot more than usually anticipated. Best to keep it simple - and if you do end up innovating might as well open source it or contribute to an already popular OS solution.

At the same time, the whole idea of a shared secret instead of asymmetric crypto is source to so many leaks that I wish we would pressure services to not use password-based authentication as their default.

Haha, the mistake I've helped implement thrice. Two forms, always.

Indeed; as soon as the article stated that SPF and DMARC are required, it stopped sounding like a good idea.

Reply on news.ycombinator.com