Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The "email is authentication" pattern

rubenerd.com

Post reply on HN
Print view View original

261–270 of 474 posts

Re: The "email is authentication" pattern

#261

Post by throwaway290 »

soerxpso wrote: post #259
simonw wrote: post #120

Earlier quoted context omitted.

> 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. This has been my single biggest argument against blockchain/cryptocurrency stuff for years: the "lose your key, lose your wallet" thing is fundamentally incompatible with real users.…

> the "lose your key, lose your wallet" thing is fundamentally incompatible with real users. You're allowed to store your key at the bank if this is an issue for you. It's less secure than memorizing it, but obviously equally as secure as your bank account is.

It is not equally secure, if bank loses you money you have recourse, if bank loses your key (a fire, a flood) it's gone.

Re: The "email is authentication" pattern

#262

Post by throwaway290 »

chii wrote: post #214
terribleperson wrote: post #82

Earlier quoted context omitted.

I think I've said it before, but I want USPS-provided email. To set one up you'd go to a post office, verify your identity in some way, and set up an email. If you forget your password and want to recover it, you'd have to go back into a post office and verify your identity again.

I don't want a semi-gov't authorized service like this. Because its existence means services would want to mandate it (even if they don't truly need it), and force users to identify themselves directly - may be even across services (by matching their email address, which now must be unique as it is identity-linked). I personally sign up to all online services with a different email each. I would like to be sure that…

Australia is working on zero knowledge proof. The end service only knows that you are legit/of age/etc (only what it needs) because gov service confirmed it, but does not know who you are

Re: The "email is authentication" pattern

#263

Post by perceptronas »

throwaway290 wrote: post #261
soerxpso wrote: post #259

Earlier quoted context omitted.

> the "lose your key, lose your wallet" thing is fundamentally incompatible with real users. You're allowed to store your key at the bank if this is an issue for you. It's less secure than memorizing it, but obviously equally as secure as your bank account is.

It is not equally secure, if bank loses you money you have recourse, if bank loses your key (a fire, a flood) it's gone.

You can store it in two or N places. Or bank can do this for you.

Re: The "email is authentication" pattern

#264

Post by [deleted] »

9cb14c1ec0 wrote: post #109
candiddevmike wrote: post #29

Earlier quoted context omitted.

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.

How about a bank-provided digital id that you get when opening an account by walking into a physical bank location and providing your photo ID? It would tick the "less prone to lock out" problem without placing even more power in government hands.

[deleted]

Re: The "email is authentication" pattern

#265

Post by throwaway290 »

perceptronas wrote: post #263
throwaway290 wrote: post #261

Earlier quoted context omitted.

It is not equally secure, if bank loses you money you have recourse, if bank loses your key (a fire, a flood) it's gone.

You can store it in two or N places. Or bank can do this for you.

More places is more opportunities for the baddies to get it.

Re: The "email is authentication" pattern

#266

Post by tzs »

gerdesj wrote: post #68
tptacek wrote: post #3

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 wit…

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

> To add insult to injury, MS Auth can only have one account per email address (id@realm/whatever you want to call it)

When this was discussed [1] on HN a few weeks ago, I don't recall anyone reporting reproducing it. Several people, including me, reported having many accounts in MS Authenticator that have the same email address with no problem.

The otpauth URI that is encoded in a TOTP QR code looks like this:

otpauth://totp/LABEL?parameter_list

The LABEL is supposed to serve as a unique identifier for the account. It has the format "Issuer:Account". The "Account" part is required. The "Issuer" is optional (and the ":" omitted if the issuer is not present).

The parameter list is an & separated list of name=value pairs. It includes the "secret" parameter which gives the TOTP secret. An optional parameter is "issuer", which should match the "issuer" part of the label if that is present.

It sounds like what is happening is that there are some sites who do not include the "issuer" part the the label, and they let the user use a user provided email address as the account name.

If a given user uses two such sites and provides the same email address to both, then there will be a collision. If they also do not include an issuer parameter an authenticator app has no way to know just from the data in the codes that they are from different sites.

[1] https://news.ycombinator.com/item?id=41275846

Re: The "email is authentication" pattern

#267

Post by antimemetics »

wruza wrote: post #254

When I ask people why they do this, they either don’t have an answer, or respond with “huh, I never thought about why”. And that’s interesting to me. Is that a storytelling touch? Users aren’t dumb or unreflective, they know that they have nowhere to store their passwords, that’s why. Even if they aware of password managers, they can work on a shared cloud pc, so switching PM accounts would be a bigger hassle. How do…

> work on a shared cloud pc

That sounds insane, is that actually happening in practice? What is the point?

Re: The "email is authentication" pattern

#268

Post by dalke »

9cb14c1ec0 wrote: post #109
candiddevmike wrote: post #29

Earlier quoted context omitted.

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.

How about a bank-provided digital id that you get when opening an account by walking into a physical bank location and providing your photo ID? It would tick the "less prone to lock out" problem without placing even more power in government hands.

Bank provided causes problems with people who don't have bank accounts. Here in Sweden most people use bank-provided electronic ID called "BankID".

Quoting "Foreign citizens in Sweden blocked from BankID after several banks roll out new rules" https://www.thelocal.se/20220117/foreign-citizens-in-sweden-...

> “We have been working systematically for six months to get residence permit cards, then a personal number, then a Skatteverket national ID card, and finally bank accounts. To our shock, we were just told by ICA Banken that the Skatteverket National ID – the only one available to non-citizens – is not a valid source of identification for BankID.”

BankID causes problems because it isn't designed for the interests of the whole population. For example, it requires proprietary software which only runs on Microsoft Windows, macOS, iOS, or Android, with hardware verification and Google services.

This makes it unacceptable to free software advocates, and to privacy advocates, and to national data sovereignty advocates .. the total population of which is so small as to not affect the banks' commercial interests.

One thing I learned recently is how the US can, with its control over the SWIFT banking network, tell banks in other countries to shut down the account for a local citizen who the US has designated a terrorist. At least that's what I gather from the news I read after two leaders of the biggest neo-nazi group here in Sweden were designated as terrorists by the US.

If the goal is to keep power out of government hands, don't look to highly-regulated banks which are subject to the whims of multiple governments.

Re: The "email is authentication" pattern

#269

Post by antimemetics »

mewpmewp2 wrote: post #228
archerx wrote: post #224

Earlier quoted context omitted.

Remembering passwords is easy this is just just convoluted and stupid.

Since you wouldn't want to reuse passwords how is it to remember them?

Let the machine do the work, sit back, and relax You have to remember 0 passwords and can still have a unique one for every account

Re: The "email is authentication" pattern

#270

Post by elric »

JadeNB wrote: post #141
jerf wrote: post #111

Earlier quoted context omitted.

Self-hosting outbound email is hard. Self-hosting inbound email is trivial. Anybody will send email to any random domain, they're just not willing to accept it from random sources. And the latter is what is relevant for password recovery. I self-host inbound but use established servers for outbound through my ISP and have had no trouble with that setup for a while. Forwarding to people through my domain has gotten a…

> Self-hosting inbound email is trivial. Anybody will send email to any random domain, they're just not willing to accept it from random sources. In terms of authentication, this is not entirely true. It's less common these days, but I used to have a lot of trouble with sites rejecting my attempts to create accounts with e-mail addresses from my disposable-e-mail-generator of choice.

Just yesterday I tried to register for a service using one of my own domain names with self hosted email. The confirmation mail arrived, but as soon as I clickes the link I was told that my email address wasn't allowed.....

Not sure what kind of crap some folks are smoking, really.

Post reply on HN