Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Tell me why this auth system is a bad idea
19 points by apitman on July 16, 2019 | hide | past | favorite | 43 comments
EDIT: It has been pointed out that slack already does essentially this, which gives me hope.

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.




Something very similar is used by Slack, Medium (also Discord and Quora, iirc), wherein they just send you an email with a link. You click on it, are logged in, cookies set and all that jazz.

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.


Would you mind linking to where you originally made that comment? Sounds like it might be a relevant conversation I should read.

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.


The original comment was made here (but no other comments are in the thread): https://news.ycombinator.com/item?id=20418196


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


Yeah basically I was referring to the situations mentioned above. Someone else's computer, private browser, etc.

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.


Well, yes, at some point I have to login to something.

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.


Ah yes that makes sense. I wasn't considering that because my email password is one of the few I have memorized.


You would enter your master password on a device that you don't control? Are there any limits to this which would cause you to think twice?


No, I'd burn a one-time use password that I've set up for such purposes.


I hate that too.

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.


As others have mentioned there are apps in the wild that do this. I use a notes app Notion.so which does auth like this.

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.


Came to mention Notion.so too.

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.


FWIW My bank here in the UK does this (Monzo) and I worked at a startup where we also implemented "magic link" to log in. It also seemed to fit nicely with a pre-account workflow idea that I'd had for one of my projects.

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.


I came to this post late but this is a terrible idea simply because of email. Now if you said push notifications to an app, Duo does this already and it's great.

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.


I agree I'd 100% prefer something like Duo if people were already acclimated, but I think we're 5-10 years away from that reality, if we ever get there.

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.


SMS is more secure than email. I challenge anyone to prove me wrong.


It is just unreliable to depend on an external system and external UX to delegate the authentication on its whole. It is the cheapest way of delegate auth I think and has notable flaws. It can work.

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?


To add a couple other thoughts off the top of my head:

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.


Used this in the past to allow Kickstarter backers to access their pledges (set shipping address etc.). We only had emails which meant that ownership of the email identified them already as the sole owner of the pledge. There would have been no benefit to ask them to create an additional account. It actually had the benefit that we could control transfer of ownership because people couldn't simply give up their email to others to sell their pledge. They had to get in contact with our support to change the email.

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.


First of all, what if you lose access to your email address? Now you can't access your service anymore?

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


> First of all, what if you lose access to your email address? Now you can't access your service anymore?

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.


2FA could be via email, but is often with SMS / app on phone. There is a backup mechanism here with printed one-time-use numbers. This is not friction-less nor optimal in my view, but there is some backup.

The proposed login mechanism has no backup. Email address hacked, expired (new job, graduated from uni) or forgot password? You're out of luck.


No explicit backup, but I think you're also assuming Google-level lack of customer service. If someone contacted me telling me they lost control of their email, there's a lot of steps I could take to help them out short of telling them tough luck and them never being able to access their account again.


True. And I don't want to be overly pedantic with the implementation details.

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)


This actually strikes me as a quite dangerous mindset! A lot of "hacked" accounts happen when someone tricks customer support. How, exactly, would you verify the customer's legitimacy?


By asking them their mother’s maiden name, of course!


You should definitely be using 2 different forms of 2FA with important services like your email address, and one of them should not be SMS. Personally I use a phone app and a hardware key.


Yes this whole thing is absolutely predicated on the concept of "if you lose access to your email you already have much bigger problems". But for me at least that's true.

The phone app would be more secure, but that's much higher onboarding friction than an email address, which everyone already has.


Well.. Your proposal adds more problems:

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


For lost email I'm inclined to agree with you. There would need to be some mitigation there (encourage or enforce users to have a backup email, etc).

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.


> for stolen email credentials [...] an attacker is going to [...] [reset] all your passwords to important services

I agree. You are saving them the effort of taking this step.


Just fyi, NIST is currently recommending against this flow. (I recently gave a talk about 2FA at BSidesSF, mentioned magic links via email, and after the talk a person from NIST came and pointed out that's against their recommendations.)

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.


I'd hate this. I'm using random strings as username and other random strings as passwords whenever allowed, my password manager keeps track of them. I have a physical backup of my password manager (two physical devices) which I keep synced, because I realize how screwed I am if I lost them.. I would prefer the option to set an "I do _NOT_ want to be able to reset my lost password" when creating an account.


I'm inclined to like this. It makes sense for users who don't have a password manager.

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.


I agree, but maybe encourage a U2F key option instead. I really like the idea of completely removing the possibility of password phishing.


Relying on a U2F key alone is single factor authentication. If a user is going through the very real/significant effort of using a U2F key, they presumably want/need real two factor authentication. That requires two forms of authentication, generally something you know (a password) and something you have (a key).


I think slack does this, you don’t need to type in password, instead it emails you a temp link, you use that to open the client.


I guess you're right. I was thinking they only do it for password reset, but you don't actually have to reset your password to use the link option.


How are they going to 'login'? If it's a link with a unique id associated with the email address, it's essentially a password that can't be changed.

The fact that a person will need to keep opening their email is really a deal breaker. Usage will drop off pretty quickly.


The email is the unique id.


Please don't assume that people can correctly enter their email address on a regular basis[0]. I get several emails per month that someone else with the same family name requested.

[0] https://xkcd.com/1279/


My mother currently has 8 entries in the alias file for this very reason.


Papa Johns does this, I think they call it a quick login.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: