5 ms·
Ask HN: Tell me why this auth system is a bad idea
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.
- billconan 7y agoI 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.
- anderspitman 7y agoI 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.
- lostmymind66 7y agoHow 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.
- anderspitman 7y agoThe email is the unique id.
- rahuldottech 7y agoSomething 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.
- anderspitman 7y agoWould 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.
- Wowfunhappy 7y ago> 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.
- 7y ago
- itcrowd 7y agoFirst 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..
- anderspitman 7y agoYes 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.
- itcrowd 7y agoWell.. 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
- anderspitman 7y agoFor 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.
- itcrowd 7y ago> 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.
- Wowfunhappy 7y agoI'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.
- anderspitman 7y agoI agree, but maybe encourage a U2F key option instead. I really like the idea of completely removing the possibility of password phishing.
- deleted 7y ago[deleted]
- Wowfunhappy 7y agoRelying 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).
- bootloop 7y agoUsed 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.
- ecesena 7y agoJust 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.
- jhinds 7y agoAs 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.
- amzin 7y agoCame 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.
- nudpiedo 7y agoIt 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?
- oops 7y agoTo 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.
- tjalfi 7y agoPlease 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/ https://xkcd.com/1279/
- zimpenfish 7y agoMy mother currently has 8 entries in the alias file for this very reason.
- saluki 7y agoPapa Johns does this, I think they call it a quick login.
- badrabbit 7y agoI 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.
- anderspitman 7y agoI 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.
- badrabbit 7y agoSMS is more secure than email. I challenge anyone to prove me wrong.
- dusted 7y agoI'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.
- robgough 7y agoFWIW 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.