Live data from Hacker News

The "email is authentication" pattern

rubenerd.com

381–390 of 474 posts

Re: The "email is authentication" pattern

#381

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.

To get a RealID drivers license in the US, which will be required to board a plane soon, requires all of the above and more. It’s a government in-person KYC.

RealID requirement for domestic flights (still) isn't happening, just like it hasn't happened since it was first announced for requirement in 2008.

Re: The "email is authentication" pattern

#382
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…

This is my gripe with 2 factor authentication: it increases security and as a second factor also increases the risk of you losing your account.

Re: The "email is authentication" pattern

#383

Earlier quoted context omitted.

Can you elaborate on „email sending isn’t free“? What are you using to host the webapp? Can’t you just set up your own mail server and send whatever you want?

I worked on email delivery systems. Your comment makes me realize that something that was free and trivial in the 90s is now painfully complex and expensive, because of monopolistic practices and spammers. We ruined something great.

A lot of email reputation at this point, in fact I'd say most of it, is FUD. Here is a current example I am a hostage of:

Sys4 (an ESP) uses Abusix as a reputation service. Because this is poorly thought out (I've been a member of the mailing list for many years) I can't unsubscribe from the postfix-users@ mailing list (can't post either). Ok that's weird and funny in a way. We could talk about Sys4's procedural failures which go into it but we would be here all day.

I did Abusix's PYLM and they unblocked me, only to eventually block me again; that's when I found out I couldn't unsubscribe. I could PYLM again but I don't care. But that gave them an email address in the domain that they block. Do you see where this is going yet? I promise you there will be a twist at the end!

Funny thing is, I can send email to support@. Well, ok, so I think it's probably good that they don't subject their support channel to their dog food, because third parties reporting vulnerabilities is a trope in cybersecurity.

Aaand, here we go. So last week they sent UCE to that email address. That's right: they sent a marketing email to a domain that they block. I did not check any boxes "please, I'm a hostage, send me your marketing info and saaaave meeeee!" when I was talking to their support about what I could provide to my ISP. No boxes are checked now either, I verified this.

So, I responded to that email and said I'd be delighted to learn more about their product, please have Sales contact me. The marketing SPAM came from support@, the reply from Sales came from a person's email. Now we're no longer talking about that hypothetically exempt support@ channel, we're talking about corporate infrastructure. If their dog food is so good:

* Why is corp accepting email from a domain they block?

* Why is Sales sending email to a domain they block?

Here's the twist I promised you:

Do a DNS lookup for their MX: it's Google! They don't eat their own dog food, at all! Google has no problem with my domain; that's a general observation. If Google doesn't use their reputation service, why should you?

For the skeptical: http://athena.m3047.net/pub/soe/abusix-spam-backstory.html

My call with their Sales department is tomorrow morning; should be good times.

Re: The "email is authentication" pattern

#384
post #288

Earlier quoted context omitted.

It won’t even be delivered in most cases.

What would prevent delivery? I do some work for a small organization and we send out registration confirmations with a self-hosted webserver. I am not aware of any delivery problems there. Thats why I was surprised. Are we just lucky?

You are just lucky. You can contact me if you want to discuss further, I would strongly recommend you don't do it here.

Re: The "email is authentication" pattern

#385
post #68

Earlier quoted context omitted.

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…

A little off-topic from the matter of adoption and usability by the greater masses, but I personally prefer these RFC 6238 TOTPs that I have the choice to take into my own hands, as opposed to internet-required, server-side based like my banking app and Okta. I have a copy of all my TOTP generators (minus my dev Okta account) in a common authenticator app and an offline copy stored in an offline password manager, fur…

I agree, for personal use cases, RFC standard TOTP that can be backed up and managed by the user is the ideal balance of security and availability.

Enterprise TOTP apps like Okta and MS Authenticator have some enhancements. Push notifications are convenient when you have to access things many times a day. More importantly, push notifications with a number-matching confirmation reduces the chance of TOTP poaching, since the user themselves are interacting with the service requiring auth.

In enterprise environments, there should be a restore process for a lost phone or authenticator. Some kind of backup code with voice/manager approval, or coming into a physical office to reset credentials. This isn't available for regular people/regular retail services except maybe banks, but banks can't even do regular TOTP correctly.

Re: The "email is authentication" pattern

#386
post #351

Earlier quoted context omitted.

If you accidentally burn cash you cannot recover it. The paper in your hand isn't replicated in another place. Humans have been unable to recover from mistakes since day zero

That is a funny example to use because the US Government has a service specifically designed to help you in that situation: https://www.bep.gov/services/mutilated-currency-redemption Yes obviously if your money is completely burned then it's gone, but that is generally pretty unlikely to happen. Losing your digital key is many orders of magnitude more likely to happen in my opinion. And there is - by design - absolut…

It doesn't need to be completely burned to be gone:

"No redemption will be made when (...) Fragments and remnants presented which represent 50% or less of a note are identifiable as United States currency but the method of destruction and supporting evidence do not satisfy the Treasury that the missing portion has been totally destroyed"

Not that unlikely, in my opinion.

Re: The "email is authentication" pattern

#387

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.

"Mom, I already told you: you have to generate a key pair, split the private key into three parts using Shamir' secret sharing algorithm, then give each part to three banks. Whenever you want to use it, you have to go collect it from each of those banks---but DON'T write it down anywhere---and perform your transaction"

And to think the conversation started with an observation that people can't even remember one password.

Re: The "email is authentication" pattern

#388
post #346

Earlier quoted context omitted.

I run a small B2C app. Users sign up with their email address only, a password field isn't even present. This creates the account and logs in the user "indefinitely" on this device. If they ever need to login on another device, they can request a new password. This way, this removes a) signup friction und b) weak passwords, because most people never need to login on another device anyways.

I like the concept but at the same time I hate having to open my email to login to a site. I already have a password manager. I rather just generate a password on one go.

It's "temporary". You can set a password later and use it to login with email + password and store it in your password manager. Only the initial signup and the first login on a new device will require the "reset password" workflow. Imho, that's the best of both worlds.

Re: The "email is authentication" pattern

#389
post #120
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…

> 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 the hype came, with it came scams and pumps-and-dumps and NFTs and whatever, and crypto became a clusterfuck that a lot of people didn't want to touch. Yuck.

That's probably the one thing cryptocurrency communities undeniably got right. Quite unlike the Passkeys, where I've yet to see any official or semi-official demo site that even has a flow for adding a second token (some actual sites do, but not the demos).

We should start teaching basic backup strategies in schools. It's not some advanced rocket science, and it's a knowledge that's useful to anyone who deals with information (that is, literally anyone participating in the modern society).

Also, this user unfriendliness is extremely temporary, because computers and Internet are new (at the scale of societies), and there are plenty of folks who had only started to use them later in their lives. After you lose some file or account (ideally, as a kid, so it's not something serious) you start to understand the old adage about those whose do backups and those who don't do them _yet_.

Re: The "email is authentication" pattern

#390
post #374

Earlier quoted context omitted.

> These safes are certified for classified use and they are safe. The website says "10 minutes against forced entry". That's not safe. No safe is safe against a state level actor. No safe is safe against "hit you with a crowbar until you open the safe". Whatever secrets you have, it's better to hide them than to put them in such a conspicuous place. The only reason one should use a safe is as a plausible decoy...

This isn’t the safe to rule all safes. You have other mitigating factors like access control. If you have state level actors physically breaking into your facilities then we might be at war

If you have enough books (which doesn't even have to be that many), it's much better to store your secrets in one or more of the books.
Post reply on HN