Ask HN: Tell me why this auth system is a bad idea
I’m no security expert, and it’s probably about to show.
I’ve had an idea for a simple passwordless auth system bouncing around in my head. I’ve seen similar ideas floated once or twice before but don’t see it used anywhere, so I’m assuming it’s not as good of an idea as I think it is. The idea is essentially to use a password reset flow for all logins, not just when you need to reset your password. So it goes something like this:
User prompted for and inputs email address Server sends them an email with a randomly generated key. The key expires in a short period (5-10 minutes) or after first use, whichever is sooner. User inputs key (possibly automatically by clicking a link in the email). Server verifies the key, generates a random token, and sets it in a cookie/local storage which is valid for a reasonable session period (a day or two, maybe a week).
Advantages:
* Very simple to implement. Few moving pieces.
* Authorization can be handled by associating resources with lists of authorized email addresses, so technically users don't need an "account" in order to "login" and access the resources.
* User doesn’t have to remember a password. If you can prove you control the email address, you’re authenticated.
* No passwords to hack/phish from the database.
Disadvantages:
* If someone gets control of your email address, they have complete control over any service relying on this system. However, I don’t see this as different from password reset flows which rely on email (ie Slack’s magic links).
* User has to open their email every time they login.
* You tell me.
44 comments
[ 3.3 ms ] story [ 105 ms ] threadThe fact that a person will need to keep opening their email is really a deal breaker. Usage will drop off pretty quickly.
I hate it, however. Quoting from another HN comment of mine:
It's _not_ convenient in many cases, such as if you're using an incognito/private window, or on a friend's computer, school PCs, don't have access to email, etc.
I much prefer the traditional username+password system. You shouldn't be memorising passwords anyway, use a password manager.
Your system doesn't allow password managers to work. Password managers are quicker than clicking on links in emails, and if you're on a stranger's PC that doesn't have the browser extension, you can just look the password up in the phone app and type it in.
I feel like you're making two somewhat contradictory arguments. The first is that this is inconvenient in several specific situations. The second is that passwords aren't a problem because people should use password managers. But the specific situations you mention are exactly the situations I've encountered in the past where my password manager isn't available either (which you acknowledge).
I do agree though that these are real problems. One advantage of using short-lived random keys for the emails is they could be short enough to manually enter (shorter than a secure password). Obviously you'd need to implement rate-limiting on the login page to prevent people from brute-forcing outstanding logins.
I assume by "specific situation" you mean, "when I'm on someone else's computer."
Does your password manager not offer a web vault? That's what I use when I'm on someone else's computer and don't have my phone with me.
But then don't you have to login to your web vault? Why not just login to your email? Unless a web vault is something specific I'm not familiar with that makes it simpler.
EDIT: Didn't realize parent was not same person as great-grandparent.
However, my email password is stored in my password manager. I can't login to gmail unless I login to my web vault first.
If a third service requires me to click a link in my email, this becomes a semi-rediculous three steps: web vault → email → other service.
Sometimes the link opens the web app.... so now I've got the channel in a web app that I don't want and not in the dang program... now what?
I'm authorized, but not where I want it and I can't just tell the non web app to do what I want.
Second, why use email? It's not secure. Depending on your threat model, it might not be a good idea.
What about a (phone) app associated to your email address that generates a short passphrase (think magic-wormhole style) every few minutes which will allow you to login to any associated service? (Caveat: one login per passphrase). Of course, now you need to make that app secure and compatible with login services..
The phone app would be more secure, but that's much higher onboarding friction than an email address, which everyone already has.
Normal situation:
1) Email address not accessible (big problem)
2) Not much ...
Proposed situation:
1) Email address not accessible (big problem)
2) Literally all other services also not accessible
But for stolen email credentials, one of the first things an attacker is going to do is start going through your email archives to see what services you use, resetting all your passwords to important services.
I agree. You are saving them the effort of taking this step.
Isn't this basically already true for all of the services that require two-step authentication?
I'm not saying this is a good state of things, per se, but at this point I've basically accepted that I can never change my email or phone number.
The proposed login mechanism has no backup. Email address hacked, expired (new job, graduated from uni) or forgot password? You're out of luck.
I like your proposal to remove passwords and prevent phising in general and I'm trying to give some honest feedback on what I think is wrong with this auth system.
The title of this post is "Tell me why this auth system is a bad idea", after all, not "Tell me the good parts of this auth system" ;)
I guess a question I would have for you is: name a few companies to which you would like to pitch this auth system. (e.g. your first few customers if you turned this into a startup or something)
But, OP should add an option for users to add a password to their accounts, which could be used instead. It need not be a part of the standard user registration flow, just an option available in settings.
Worked really well, I would do it again if the terms allow it. But I think as everything this is a case by case decision.
I personally believe they're taking more the "business" point of view, where users may have a business email which may not be very secure or always under their control.
For consumers I think it's ok, especially considering most of them use gmail. However this slows down login compared to other approaches like OAuth, so I'm not sure how applicable this may be at scale.
To be honest I didn't/don't like it because it's an extra step and I use a password manager anyway that makes it easy to fill in my passwords.
As I'm reflecting on it though, it's not that big of deal as I use the mobile and desktop apps which I'm signed into all the time. I would imagine if it were an app I had to log into again all the time or frequently I would be pretty annoyed with it.
My email is a mess for I should switch between several work/home mailboxes — and from time to time I just have to wait for an email too.
This is one of the reasons I avoid launching Notion.so.
1. bad UX, extra email step. Every. Single. Time.
1.1 Sometimes email servers take a while to send/receive emails.
1.2. Constant flood of emails. Swipe to delete might be OK a few times, but at the end it is a user overload.
2. No 2FA as with the process here, if added the process will get real very soon.
3. you still need tokens for the session and prevent someone else steals the key and makes a double login (e.g. looking at someone screen)
4. User might want to change email, so you auth system will need to implement real world UX sooner or later.
5. Think like a business. When problems arise you might want to assist the customer in a personal way. What will happen when their email got compromised? 2FAA to the rescue?
Your login link now passes through one or more third parties (SMTP servers) which may or may not use TLS, and which may or may not have their certificates validated by each other. So technically a targeted MITM would be possible that would not have been possible with a normal HTTPS password authentication.
Also from a privacy standpoint, your email host and any relays involved now have a detailed record of every time you logged in.
[0] https://xkcd.com/1279/
I have personally logged into people's accounts simply by opening links sent in an email. It is routine to inspect URLs and attachments in emails, email is not confidential. Period.
You mentioned slack does this? Alright then, search for similar URLs in virustotal or any other public malware or spam URL repository and tell me how many slack accounts you can login to (assuming someone started the login and did not finish).
It's not just man in the middle attackers but many othet han and automated processes inspect email at most larger organizations.
I remember someone claiming an email security appliance vendor was "brute forcing" them,turns out they mass-emailed something with their URL in it and the appliances at different companies were detonating the URLs in different virtual environments to see if they cause anomalous behavior.
You can substitute 2FA with signal,telegram,matrix,push notification and I personally would have no problem with it.
But I think a lot of the risks you're talking about are mitigated by having the initial link/code expire in 5 minutes. Not completely removed, but mitigated. The risk profile isn't great but it's not any worse than an email-based password recovery flow.
> I remember someone claiming an email security appliance vendor was "brute forcing" them,turns out they mass-emailed something with their URL in it and the appliances at different companies were detonating the URLs in different virtual environments to see if they cause anomalous behavior.
This is interesting. That might make prevent me from being able to make the codes single-use, which greatly increases the risk.
But... ignoring the potential security issue of trusting your email, which (like your post points out) most forgot-password routes do anyway, you then get onto usability.
Turns out some of our users really hated it, and couldn't get their heads around it. Including some key members of our snr. management team. Slack IIRC was originally magic-link only, but then reversed course later, and tbh -- even I find it frustrating when using it with my banking app. It's way slower than just having 1Password fill in the user/pwd details for me – as has been pointed out, it adds a cumbersome second step.
That said, I think it still has a place for places where the user won't necessarily need/want to create a "full account" but you can use it to at least do some email validation. Then if they want an account later, you can simply turn this "shadow" account into a full one by letting the user set a password, as that's really the only difference.