[HN Gopher] The "email is authentication" pattern
___________________________________________________________________
The "email is authentication" pattern
Author : Brajeshwar
Score : 55 points
Date : 2024-09-07 17:48 UTC (5 hours ago)
(HTM) web link (rubenerd.com)
(TXT) w3m dump (rubenerd.com)
| threatofrain wrote:
| People have already been building auth flows that take this
| password amnesia into consideration. Look at Anthropic. It's just
| one way of doing auth and I personally hate it.
| voiper1 wrote:
| I use a password manager. I don't like flipping back to my
| email, I already have a secure password.
| cpach wrote:
| Same here! But for most apps we are probably in the 0,1% or
| so.
| ydnaclementine wrote:
| The most secure password is no password
| hansvm wrote:
| Totally agreed. The account though, that's another
| question. Would you mind sharing the username of your
| favorite passwordless account?
| doctorpangloss wrote:
| Anthropic and others do this to inconvenience account sharing.
| It's not really about auth, it's about licenses...
| tptacek wrote:
| Email accounts are the highest common denominator in online
| authentication. Phones are competitive, but people lose phones.
| Phone numbers are more common and durable, but the security of
| phone numbers is leagues below that of a flagship provider email
| account. It makes sense that so many authentication flows work
| this way.
|
| When designing a "fantasy football" alternate authentication
| system for the Internet, start with account recovery: what
| happens when a user loses your fancy authenticator? If the answer
| is "they just don't get access anymore" or "a panel of their
| peers attests to them", your fantasy authentication system also
| needs a fantasy species of sentient beings to serve as users,
| because it won't work for humans.
| hgomersall wrote:
| It's an interesting design problem to have panel of peers
| attest an individual's identity. It could be made fairly
| seamless if there was a common system in which a suitably
| distributed authentication secret could be recombined under
| instruction from the relevant party. Can it be made to work for
| normal humans? I daresay we have the ingenuity to design
| something...
| unilynx wrote:
| except that those instructions will be handed out by phishers
| jlund-molfese wrote:
| Apple's Recovery Contacts are a similar idea. The main
| difference is that just one can help you recover your
| account, but it doesn't seem too hard from a UX perspective
| to make 3/5 recovery contacts required to unlock an account.
|
| https://support.apple.com/en-us/102641
| efitz wrote:
| We could also leverage trusted third parties for this
| purpose, for example, banks or DMV or Walmart.
|
| However, there needs to be a fiduciary interest by the third-
| party (eg liability for identity theft, etc) in order to
| incentivize them to avoid fraud. It is not clear that there
| would be enough profit involved to offset the liability.
| crooked-v wrote:
| Unfortunately, "they just don't get access anymore" is the
| usual pattern with major email providers like Google, as many
| people who have had a phone lost or stolen and then been locked
| out of their accounts forever can attest to.
| candiddevmike wrote:
| Government provided digital IDs would solve a lot of this. Yes,
| they may have their own problems, but outsourcing the action of
| identifying individuals to the government seems valuable and
| less prone to "lock outs" like Google and friends.
| jpalomaki wrote:
| Yes. I would very much like to tie certain accounts to my
| government issued digital identity and allow that as the only
| recovery method.
| JumpCrisscross wrote:
| > _Government provided digital IDs would solve a lot of this_
|
| A lot of what? It seems like the worst of all worlds, given
| that ID would not only unlock some _highly_ sensitive things,
| but also be difficult to change and tremendously revealing.
| quectophoton wrote:
| It certainly is an alternative we can at least think about.
|
| On one hand, the certs you'd use to login to websites
| wouldn't even need to include any personal info at all, just
| a valid signature from a CA that the website knows how to
| verify. And the certificate wouldn't need to be the same for
| every website, it could be one you generate for a specific
| website.
|
| On the other hand, a lot of thought would need to be put into
| how expiration/renewal and revocation would play into this.
|
| Of course there should be an evaluation of the ways this
| could go wrong if someone from the gov misuses this CA, and
| how that compares to someone from your current email provider
| misusing their permissions.
|
| But if nothing else, something I really want is to just be
| able to have an email address like
| `random_id@my_country.my_country_tld`, to at least have an
| email address where I don't have to worry about being locked
| out, so that I can give freely to ISP, bank, grocery delivery
| websites, other local companies, etc. Most of this stuff I
| wouldn't even mind receiving as postal mail anyway. And if
| shit hits the fan, I can recover access to this email account
| by walking to an office and identifying myself.
| ristos wrote:
| It exists for US citizens at least: login.gov
| (https://developers.login.gov/oidc/getting-started/)
|
| It has it's pros and cons, maybe more pros if you factor in
| that the biggest issue isn't authentication really, it's the
| fact that all of these private companies accrue everyone's
| sensitive info, which can be abused by any actor, private or
| public. If data were kept on the client side, and synced to
| other machines through P2P like WebRTC, then maybe this
| wouldn't be such a big deal.
| joncfoo wrote:
| Unfortunately login.gov is only available for use by
| companies doing business with the US government.
| capitainenemo wrote:
| Also login.gov isn't a government issued digital ID. It's
| just a centralised authentication platform for government
| use, much like using google or apple for authentication.
|
| It supports the usual options for multifactor (TOTP,
| text, yubikey/other hardware auth/PIV cards) but for most
| users it probably ends up being SMS. At best TOTP.
| DANmode wrote:
| Humans understanding the basic concept of public/private
| keys,
|
| wanting a Yubikey or similar,
|
| and/or being able to use basic tools to make a key,
|
| would also help.
|
| But I'll take the government-led method as a Plan B, if it
| works.
| nfw2 wrote:
| Can you expand what you mean when you say the security of phone
| numbers is leagues below email? If someone can gain access to
| someone's phone, it seems like they would gain access to their
| email as well.
| tptacek wrote:
| Phone _number_ , not phone.
| nfw2 wrote:
| How does an attacker gain access to a phone number without
| having the phone? Like physically stealing the sim card or
| something else?
| fragmede wrote:
| bribe, coerce, and social engineer a phone company
| employee into transferring the victims phone number to
| you, or a technical attack to get the system to send the
| sms messages to a device you control, without ever
| touching the victim.
| Zanfa wrote:
| The attacker just needs to convince/compromise a single
| carrier employee to get a new SIM for your number.
| 57FkMytWjyFu wrote:
| Sim swap via pretending to be a clueless customer who
| lost their physical phone, banking on lax checks at
| customer service.
| efitz wrote:
| Mobile phones identify themselves to the mobile network
| through a number called the IMEI. IMEI cloning is not
| particularly difficult nor does it require exotic equipment.
| This means that it is relatively easy for an attacker to be
| able to spoof your phone to a mobile network, for example, to
| receive SMS messages with one time passwords.
|
| Cloning your IMEI has nothing to do with the data that is on
| your phone, so if someone clones your IMEI it does not mean
| that they have access to any of the apps or data that is on
| your phone.
| nfw2 wrote:
| Thanks for the clarification!
| jpalomaki wrote:
| Phone companied have customer support. This is a weak point,
| because attacker can use social engineering to gain access to
| your number.
| gerdesj wrote:
| Auth apps are crap - each one pretends to be unique and
| authoritative.
|
| TOTP secrets are a string, not just a QR code that can only be
| seen once and never again - the QR code merely encodes that
| string! That string can be used in multiple places to generate
| codes. KeepassXC can do it and that can be shared. I've seen
| loads of organisations and sites with an elderly mobile phone
| that has the TOTP auth app on it. Normally MS Authenticator.
|
| To add insult to injury, MS Auth can only have one account per
| email address (id@realm/whatever you want to call it).
|
| PrivacyIdea can do email based TOTP with a PIN. That works well
| but does involve a two stage login with an email delivery in
| the middle.
|
| I totally agree with you: the only useful delivery mechanism
| available is email. PGP was a nice idea and authenticator apps
| need to have their owner's heads bashed together to get proper
| interoperability sorted out. Trying to silo people in your
| "cloud" without interoperability with others is so sad and
| needy. If you don't have absolute confidence in your offering
| then you are shit!
| ivanjermakov wrote:
| I never thought of using password reset as a permanent
| authentication method. Ingenious!
|
| Except when the service throws you back to the login page to
| authenticate with a fresh password you just typed in the reset
| form.
| tptacek wrote:
| Plenty of services do this already, right? It's called "Magic
| link" login. Am I missing a subtlety?
| ivanjermakov wrote:
| In my recent experience it's 50/50.
| jonnycomputer wrote:
| As long as the email account is secure, and the throw-away one-
| time passwords are good, you have the frequent-rotation passwords
| security advocates dream about. Indeed, hand them a secure
| password they have to use (and forget).
| voiper1 wrote:
| I just made it an option in the "I don't have a password" form
| that instead of setting a password it just logs them in. So
| they don't even see / have a password to remember.
| prng2021 wrote:
| "It offers a guaranteed, repeatable, low-effort solution"
|
| Doesn't this answer the question? I would have preferred to read
| and discuss what they believe to be better alternatives.
| Hugsun wrote:
| You posit a good question but it would be interesting to take a
| step further and discuss some potential alternatives, or expand
| on why "email is authentication" is/isn't the best option there
| is.
| paulgerhardt wrote:
| I'll be hyperbolic and say the login flow is identical.
|
| A) Go to website, click through a password manager to copy and
| paste an arbitrary string of characters, receive TOTP request
| sent to your email to confirm your identity.
|
| Or
|
| B) Go to website, click forgot my password. Receive link to
| login. Enter an arbitrary string of characters.
|
| In many instances, login flow B is actually quicker and seldom
| slower.
|
| Clicking the "remember me" checkbox has no effect.
| MBCook wrote:
| Who copy and pastes from a password manager?
|
| Here's my workflow, and I consider it superior to both of the
| above.
|
| Go to site, Safari offers to autofill, give TouchID/FaceID, get
| asked for a 2 factor code.
|
| Sent via SMS/email? Safari offers to autofill for me. TOTP
| style? Safari offers to autofill for me.
|
| Easy peasy.
|
| Passkeys are even easier as there is no second step and waiting
| for SMS/email.
| bigstrat2003 wrote:
| > Who copy and pastes from a password manager?
|
| People who don't use something which integrates with the
| browser. People who run into the (uncommon but noticeable)
| edge cases where the password manager decides to not auto
| fill the password.
| MBCook wrote:
| When it doesn't work I get. I run into that from time to
| time.
|
| But I don't think normal users want ones that don't sync or
| integrate with the browser. I believe you can turn both off
| for Safari but that defeats the whole purpose in my mind.
| paulgerhardt wrote:
| Yes, that is a nice solution.
|
| I suppose the reason is because the Bitwarden option is cross
| platform and I don't want to sync two password managers.
|
| However when using Bitwarden the recent guidance is to turn
| off autofill[1] but even with it enabled it sometimes breaks
| hence my "seldom" caveat.
|
| I am heavily biased to prefer passkeys but as with magiclinks
| before them saw the rollout was badly botched. Specifically
| with regards to supporting multiple keys and
| revocation[2][3]. The standard supports correct
| implementation but don't require it; meaning most current
| rollouts are half baked and will remain that way.
|
| [1] https://flashpoint.io/blog/bitwarden-password-pilfering/
|
| [2] ie: https://www.reddit.com/r/yubikey/comments/14h0d7y/sin
| gle_key...
|
| [3] https://news.ycombinator.com/item?id=40165998
| Rygian wrote:
| > Who copy and pastes from a password manager?
|
| Me. I don't know of any other LAN-only method that works
| consistently across my various desktop and mobile devices.
| fragmede wrote:
| okay, but you're using xclip/pbpaste/equivalent, yeah?
| kwhitefoot wrote:
| Doesn't your browser remember your passwords?
| fragmede wrote:
| This flow is made shorter if you have the TOTP stored and
| filled out by the password manager.
| dishsoap wrote:
| TOTP is not really something that would be sent to your email.
| The entire point of TOTP is that you can generate the auth code
| yourself, from the current time and a pre-shared secret.
| kevincox wrote:
| I think the OP meant OTP. The general concept of one time
| passcodes, not TOTP as per RFC 6238
| zajio1am wrote:
| With greylisting, the flow B could take like 10 minutes.
| cyrnel wrote:
| Somewhat related discussion from yesterday:
| https://news.ycombinator.com/item?id=41468486
| jwr wrote:
| Some apps enforce this flow, e.g. there is no way to log in with
| a password. I hate this.
|
| Because of the developers of these apps assuming that E-mail
| guarantees instant delivery (it doesn't), I can't use
| greylisting, which reduced spam very significantly.
| mgkimsal wrote:
| Amen, yes. Greylister here too, and password reset/magic links
| sometimes end up being painfully slow.
| yencabulator wrote:
| Your greylist setup really should learn good senders quicker;
| this shouldn't be an ongoing problem.
| TZubiri wrote:
| Because websites used emails as an identity, strictly in order to
| stop malicious use.
|
| An email ties a user to a domain, the domain issues a user for
| them. If too many users from a domain are malicious, the website
| can block the domain.
|
| It's a matter of identity and accountability.
| dogcomplex wrote:
| At this point why not just pass a one-time url link to your email
| address, and have it be a single click to login? Have it expire
| within 10 mins if not used, and be one-time use disposable.
| Still, anyone who has the link initially should be able to login
| with your account - but it's only accessible from your email.
|
| Obliterates all sense of security beyond the email account
| itself, but that's where we're at anyway. Do the same pattern
| with a message to your phone "click to authenticate login:
| www.someurl.com?p=134234535" and you've got 2FA without any dumb
| "enter this code".
| fragmede wrote:
| There are a number of sites that do exactly that.
| sunnybeetroot wrote:
| I agree this is a great way but don't forget not everyone is
| signed into email on their device.
| Saris wrote:
| Some sites do that, like Netdata.
|
| But it's slow compared to my PW manager just autofilling a
| user/PW combo, since I have to wait for the email and go click
| the link.
| byteflip wrote:
| I'm coding up a webapp with this exact login process - the
| issue I've found is on mobile phones - apps like gmail won't
| let you copy the link into a browser without a preview. The
| preview consumes the link. (next.js auth)
|
| It's a bit annoying, since I don't want to login into the gmail
| in-app browser, I want to login on my regular browser.
| aetherspawn wrote:
| Don't forget some people have antivirus scanners that will
| load up every link when the email is opened, so you can't
| have the link expire after 1 visit.
|
| This is I think why unsubscribe links now have a single
| button saying "Unsubscribe" or similar when you press them.
| Likewise anything interesting should require a 2nd user
| action after loading the page.
| righthand wrote:
| A work around could be: login link token is good for 24hours
| unused, or 5mins after the first use. That way you don't
| leave the user in a loop or risk them not clicking the link
| within a short amount of time. The token still expires after
| a reasonable duration too.
| stavros wrote:
| I do this for many of my web apps, it's confusing to users
| ("why do I already have an account here? I never signed up!"),
| expensive (email sending isn't free) and slow (sometimes the
| emails go to spam, sometimes they get greylisted and people
| can't log in for hours, sometimes it takes a minute to arrive
| and that's way too long to wait), etc. I don't know if I'd
| recommend it.
| fmeyer wrote:
| Identity is tricky. Proving who you are depends on a certain
| level of trust. Whether it's through email, devices, phones, or,
| in more advanced settings, some sort of digital certificate; you
| won't have much options.
|
| Unless you're in Germany using a service provided by the Vogons,
| you might end up getting a letter containing an activation PIN
| via snail mail or worst having to visit the post office to show
| your passport.
| gmuslera wrote:
| The second component of this, for people that doesn't care to do
| good track of their passwords, is that their email passwords are
| usually memorable in the wrong way. So both your mail and all the
| dependent services are all held together with the same weak clip.
|
| Double factor improved a bit this, or at least made it harder to
| break into this to some of the players, and simplified the
| process for some others.
| Ekaros wrote:
| Email passwords is interesting one. As my feeling with
| something like gmail is that you insert it approximately once
| or twice per device... Which leads to weird dynamic that you
| have to recall it way too rarely for actually to remember it
| properly...
| robertlagrant wrote:
| The problem is just that despite all the advantages it would
| bring, people won't pay for auth as a service, where your
| identity is tied to accounts outside of an email address, and you
| (say) get a browser/phone notification to log in when you log in
| with MyAuthProvider and it's quick. They'd rather go through the
| email route, which is the same thing but slower and goes via
| Google.
| jt2190 wrote:
| I swear the McDonald's app for the U.S. works like this on
| purpose. I'm prompted for my email then thus send me a link. They
| never ask me to set up a password.
___________________________________________________________________
(page generated 2024-09-07 23:00 UTC)