Live data from Hacker News

The "email is authentication" pattern

rubenerd.com

391–400 of 474 posts

Re: The "email is authentication" pattern

#391
post #243

Earlier quoted context omitted.

Physical money is physically recoverable after lost

For the system yes, a dropped coin eventually reenters the market and a burned bill can be reprinted again. Can't say the same about a crypto wallet. For an individual though, in both cases, a lost wallet is a lost wallet. While an interesting difference to study, the average person is not going to care about the former case. They just don't want to keep their life savings in an asset as easy to loose as their pocket…

[deleted]

Re: The "email is authentication" pattern

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

How many forms of backup survive "the government threw you in prison for years?" Even Gmail will refuse to authenticate a correct password with "we couldn't verify it was you" if you never binded your account to a phone and just got out of prison 3 years later.

Re: The "email is authentication" pattern

#393

We run a pretty unserious business. That is, our users use our accounts only out of convenience. The system we've settled on is this: 1. User enters email 2. We send a verification code to their email 3. User enters code, is signed in "indefinitely" (very, very long cookie) Whether or not they had an account before hand is irrelevant, we just register a new account if the email is new. The occasional user has multipl…

How do you do very long cookie? I thought safari deletes them anyway after a certain time.

I mean, it doesn’t really matter. Just do it as long as it works and when it stops working they can sign in again. The point is to quit hassling your users in the name of “security” if you’re not a security critical application. YMMV.

Re: The "email is authentication" pattern

#394
post #392

Earlier quoted context omitted.

> [...] 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…

How many forms of backup survive "the government threw you in prison for years?" Even Gmail will refuse to authenticate a correct password with "we couldn't verify it was you" if you never binded your account to a phone and just got out of prison 3 years later.

Uh, well, in context of crypto - your (self-owned) crypto wallet totally would work.

As for email... Sure, I guess it depends on the service and their policies. But here's an anecdote. A few years ago, I've managed to log in in to a completely forgotten 10+ years old email account, finding its password in an old backup. It worked. ¯\(ツ)/¯

If an user cannot log in with a valid credentials, without brute-forcing them, after some years of absence, it's absolutely the service's fault. Of course, in the modern world, customer issues mean nothing so anything goes. But -quoting GP post - when designing a "fantasy football" alternate authentication system for the Internet, this probably shouldn't be a thing.

Re: The "email is authentication" pattern

#395
post #243

Earlier quoted context omitted.

Physical money is physically recoverable after lost

For the system yes, a dropped coin eventually reenters the market and a burned bill can be reprinted again. Can't say the same about a crypto wallet. For an individual though, in both cases, a lost wallet is a lost wallet. While an interesting difference to study, the average person is not going to care about the former case. They just don't want to keep their life savings in an asset as easy to loose as their pocket…

A burned bill can be replaced because its value is backed by an institution--the absence of such an institution is the premise of crypto.

Re: The "email is authentication" pattern

#396
post #183
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…

Maybe we should support logging in with an OTP to email for many more systems than we do currently? Combined with conditional access and MFA its actually not bad. No password to remember and supports this "pattern"

Sure, but please make it optional.

I've seen a couple of enterprise/corporate services switch to the "OTP via email" pattern (usually as mandatory 2FA), and I hate it, because there's no way for me to autofill that email OTP, unlike for e.g. WebAuthN or TOTP.

Re: The "email is authentication" pattern

#397
post #113
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…

I'm increasingly coming around to the idea that in reality, there's only one factor, at least as far as the Internet is concerned: Something you know. There's different ways of knowing it and various difficulties involved in knowing it, but "something you are" is only every a fancy way of presenting something you know (because if you know it, you can generally forge it with reasonable effort) and "something you have"…

> That includes even things like Yubikeys, which are things that can be cloned and stuck in a password manager. They're just really, really hard to clone, and that's a valid step up from "a password".

That's reductionist way past the point of being a useful model of authentication factors.

By that logic, even biometric factors are "something you know", as you can always (with a lot of effort) physically replicate a fingerprint/retina/genome you have a sufficiently high fidelity recording of.

Re: The "email is authentication" pattern

#398
post #36
post #30

Earlier quoted context omitted.

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.

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

That's completely wrong. The IMEI doesn't play any role in GSM/UMTS/LTE/5G authentication (if it's recorded, that's usually for debugging or tracking purposes).

While there are weaknesses, every mobile phone standard since GSM (not sure about the equivalent for the CDMA world) uses cryptographic authentication, many of which have been subsequently broken, but it's just not true that simple knowledge of a bearer token, transmitted over the air interface, grants you sufficient access to receive somebody else's SMS.

Most practical attacks actually focus on either attacking the core network via SS7 (and making it deliver SMS to the attacker instead of the actual recipient) or on breaking the air interface encryption, which requires you to be physically close to the legitimate recipient while they receive the SMS over the air.

You can change your IMEI to mine right now, and absolutely nothing would happen (other than maybe our phone operator getting mildly confused, if we share one and they're tracking IMEIs for whatever reason).

Re: The "email is authentication" pattern

#399
post #36

Earlier quoted context omitted.

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

IMEI or IMSI? I think it is the subscriber identity that is on the SIM that needs to be cloned, not the hardware identifier of the device (ie its the IMSI that matters, not the IMEI). SIMs and SIM burners can be purchased trivially on the open market, and cloned without too much difficulty. Although, a social engineering attack on the employee at the cellphone store is a superior method since it automatically gives y…

Neither the IMEI nor the IMSI is used for authentication. The IMSI is slightly closer to the truth (while still missing by a mile), but without the per-IMSI authentication key (which is never transmitted over the air interface, whether in plaintext or encrypted), it's useless as well.

Re: The "email is authentication" pattern

#400
post #390

Earlier quoted context omitted.

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.

Yea but you have multiple pieces of the secret to restart your Vault instance. Now you need to go to everyone’s office or home to get this secret to restore it.

I am referring to Shamir algorithm that Vault uses

Post reply on HN