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

411–420 of 474 posts

Re: The "email is authentication" pattern

#411

Post by Vegenoid »

drdaeman wrote: post #389
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. Humans need to be able to recover from their mistakes. Maybe it's my memory playing tricks, or I've only seen the good articles, but I believe nearly every single article about setting up a self-managed crypto wallet had stressed out the importance of having a backup. Serious ones had even explained the 3-2-1 rule. Then…

> I believe nearly every single article about setting up a self-managed crypto wallet had stressed out the importance of having a backup. Serious ones had even explained the 3-2-1 rule.

Yes, this is why it is incompatible with widespread adoption. Most people do not want to do this, and in fact could not do so effectively without learning and thinking a good deal more about computers and risk scenarios, which they don’t want to do and will not do.

You are correct that it is a solution. However, it is not a solution that will ever be adopted on a wide scale.

Re: The "email is authentication" pattern

#412

Post by Vegenoid »

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.

Are you referring to a physical lockbox? Because if so, that is certainly not as secure as your bank account, because criminals could not drain your bank account by breaking into a bank, nor could your account’s funds be lost if the physical location were destroyed by a flood or other disaster.

Even if you are referring to digital storage managed by the bank, presumably competently enough to avoid data loss, if that data is exfiltrated your wallet will be drained. It would be very difficult for a hacker to irreversibly drain your bank account (given the type and terms of the account, but will apply to most savings accounts), due to the protection and delay systems in place meant to catch fraudulent or unauthorized activity. Note that this definition of “unauthorized” actually means “not authorized by the human being who owns this account”, instead of the crypto definition of “not authorized by someone who knows the correct secret”.

Re: The "email is authentication" pattern

#413

Post by mewpmewp2 »

archerx wrote: post #334
system33- wrote: post #332

Earlier quoted context omitted.

I think their point is that no matter how secure your base password is, once one site leaks it, the bad guy basically knows your password to every site.

I have been using the internet since the 90s, my Hotmail account is 23 years old and I have never lost any of my accounts. I think it’s working quite well in my experience.

This is one of those things that works until it doesn't, though.

Re: The "email is authentication" pattern

#414

Post by zeroimpl »

> What if we could somehow design systems so that the people who use them evolve to use them in better ways?

I hate when people suggest that there is something insecure about using the password reset feature. Whether I chose to use it to get into my account without a password has no impact on the security of the account. The mere presence of this feature is what’s determining the security of my account.

Similarly, some services I use prompt me to verify via SMS or Email after I input the password, but oddly imply that using SMS is more secure than email. Makes no sense to me since either way the OTP should only be usable on this one session, and even if one is a less secure channel, it’s the presence of the weaker option in the first place that’s the problem, not the choice made by the user.

Re: The "email is authentication" pattern

#415

Post by dredmorbius »

mozzieman wrote: post #142

A physical key you have put in your computer and store on your keychain.

And if you lose / damage that physical key?

Look at the physical world analogue. If you lose a house key, you can force the lock, break down the door, re-key the door, pick the lock, or any number of other means of re-gaining access, up to and including going through the wall / ceiling / floor.

If you lose an authentication key, you're S.O.L.

Re: The "email is authentication" pattern

#416

Post by notpushkin »

presentation wrote: post #260
lolinder wrote: post #179

Earlier quoted context omitted.

Money occupies physical space, so for most of history there was a pretty low cap on how much you could bring with you at once, which placed a cap on how much a single mistake could cost you.

This is what transit payment cards in Japan at least do, you can tap to pay most places but there’s a cap of 20k yen you can add to your card, so there’s a cap to how much you can lose.

I love how these cards work in Japan. There’s a bunch of different operators but they all work across the country – for example, if you buy a KITACA in Sapporo, you can use it in Tokyo and Osaka and anywhere else. And of course you can use them in a bunch of places, from all the transit options to vending machines and coin lockers on stations to konbini everywhere and even some restaurants.

(Of course it’s a bit more complicated: https://commons.wikimedia.org/wiki/File:ICCard_Connection_en... – but still impressive nonetheless!)

Re: The "email is authentication" pattern

#417

Post by tomhallett »

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.

"soerxpso" said "store your key at the bank", but you are saying "two or N places". So it sounds like 1 bank is less secure for your key then 1 bank is for your money, because you need two or more banks for your key, while 1 bank for your money is sufficient. Correct?

Re: The "email is authentication" pattern

#418

Post by nucleardog »

mplewis wrote: post #361
adastra22 wrote: post #311

Earlier quoted context omitted.

I don’t have access to my email on the computer in which I am trying to login to your web service.

Why not?

Using someone else’s computer?

Using a work computer that you don’t want your personal email downloaded on?

Using a computer you don’t use often and don’t feel like setting your mail client up?

Re: The "email is authentication" pattern

#419

Post by nine_k »

kmoser wrote: post #376
terribleperson wrote: post #175

Earlier quoted context omitted.

Is a fake ID going to fly at the post office, where they can scan them? Also, I was imagining they'd want more than just an ID. edit: Also also, they have to go into a physical post office and be observed trying to steal your account. Given how it's quite possible to steal accounts via social engineering, this seems like an improvement in security, not a reduction.

I don't want a government entity, or really any entity I'm not paying directly for their services, to be the gatekeeper between me and my accounts. The social engineering attack surface of my account currently consists of a handful of support contacts at my ISP, who have been trained to deal with computer security. If you allow any USPS employee to access your account, you've suddenly increased the potential attack s…

(1) Your USPS-provided email should neither be mandatory nor the only acceptable email. It could be an extra convenience, and a low-friction way to get a reasonably secure email for first-time / technically unsavvy users.

(2) An entity you're directly paying to may go out of business, sometimes due to circumstances beyond their control. At least state-sponsored entities don't do it so abruptly in most of the "civilized world".

Re: The "email is authentication" pattern

#420

Post by nucleardog »

MBCook wrote: post #15
paulgerhardt wrote: post #8

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…

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.

> Who copy and pastes from a password manager?

I do.

I’d prefer my passwords, foundational identity documents, and other sensitive information are as separate as possible from the place where I execute untrusted remote code a bazillion times a day. Making it programmatically available is the opposite of separate.

Post reply on HN