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

461–470 of 474 posts

Re: The "email is authentication" pattern

#461

Post by lwansbrough »

mercenario wrote: post #443
lwansbrough wrote: post #339

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…

I have seen some logins like this, can't you just send a link in the email that sends you to the app home and you're logged in already? I find it a hassle to copy the code, finding the right tab where I left the login page and pasting the code to login.

Magic links make assumptions about how users are accessing your sign in. That the device opening the email is the device using the authorization. Or that the user is signing into a web page and not a native/mobile app.

Re: The "email is authentication" pattern

#463

Post by bouncing »

throwaway290 wrote: post #262
chii wrote: post #214

Earlier quoted context omitted.

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

And what does the Australian government know? Could it collect who you identified with?

Re: The "email is authentication" pattern

#464

Post by bouncing »

terribleperson wrote: post #175
kmoser wrote: post #174

Earlier quoted context omitted.

No, thank you. I don't want anybody with a fake ID of me to be able to take control of my email. I want to use my password, I want it strongly encrypted at rest, and I want to be able to reset it remotely any time of day, without waiting for the USPS office to open.

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.

The account recovery process for commercial email providers usually involves you photographing your ID. Presumably the post office, in person, would be far less likely to be fooled.

Re: The "email is authentication" pattern

#465

Post by bouncing »

lwansbrough wrote: post #339

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…

I’ve seen projects do the same, but also issue passkeys. That lets them seamlessly sign in across ecosystem devices.

Re: The "email is authentication" pattern

#466

Post by Vegenoid »

EVa5I7bHFq9mnYK wrote: post #458
Vegenoid wrote: post #427

Earlier quoted context omitted.

> We manage to explain people to not poke with scissors into electrical outlets (and make it hard to do so accidentally) - we can manage similar stuff with computers too. I don't think this is a good analogy, because the example is simply warning people of a thing not to do. It takes no effort. Maintaining backups does take effort. This is more like getting people to pick up a new chore, just like how many people see…

People's bank accounts are irreversibly hacked, emptied, frozen, seized, blocked, impounded, garnished on a daily basis. That you haven't encountered it yet, doesn't mean it's not happening. People should have a choice which system suits them more.

Is there not a choice? What is stopping you from converting all your fiat into crypto?

This is simply about what choice the majority of people have made, and likely will continue to make.

Re: The "email is authentication" pattern

#467

Post by lxgr »

jerf wrote: post #437
lxgr wrote: post #397

Earlier quoted context omitted.

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

"By that logic, even biometric factors are "something you know"," You clearly mean that as a reduction to absurdity, but, yes, I mean exactly that. Pretty much said so. It is "reductionist" if you insist the only valid framework is "what have have/know/are", and you view what I'm saying as the intersection of what I'm actually saying and that model. I am claiming the have/know/are is reductionist, and to a large degr…

I suppose then we have to agree to disagree.

While the "something you x" model has many limitations (and I practically disagree with some regulatory bodies on what does and does not constitute a "true" expression of one of these factors), I don't think that these limitations refute it in the abstract.

Re: The "email is authentication" pattern

#468

Post by EVa5I7bHFq9mnYK »

Vegenoid wrote: post #466
EVa5I7bHFq9mnYK wrote: post #458

Earlier quoted context omitted.

People's bank accounts are irreversibly hacked, emptied, frozen, seized, blocked, impounded, garnished on a daily basis. That you haven't encountered it yet, doesn't mean it's not happening. People should have a choice which system suits them more.

Is there not a choice? What is stopping you from converting all your fiat into crypto? This is simply about what choice the majority of people have made, and likely will continue to make.

>> What is stopping you

Possible disapproval by fine HN community.

Re: The "email is authentication" pattern

#469

Post by roryokane »

EnigmaFlare wrote: post #406
SPBS wrote: post #272

Wow, that's awful. So they abuse "forgot your password" as a login method, with the added obstacle of having to come up with a random password every time. And they don't see any problem with it. My hunch is that all these people are very non-technical users.

I do that for some sites. It's the initial effort required to set everything up that's the obstacle. This kind of behavior is taking the easiest route at every step instead of investing time into making the future easier. I stopped using a password manager after it got hacked and haven't bothered setting up a new one. The most annoying sites require you to confirm your throwaway password or log in again using it, and…

I can save you some of that research. The KeePass family of password managers are open source and based around a shared file format. They save your passwords in an encrypted file on your computer or phone’s local drive. An ecosystem of apps by different people can parse that file format (after you enter your master password), and at least one app can export as CSV or HTML, so migration is not a problem.

Since your passwords are in a local file, there is no online password manager that can be hacked. If you worry that your local password manager software will have malicious updates posted, you only have to read news at the time you download an update, which can be as infrequent as you like.

If you need to share passwords among your devices, you can store the encrypted file in a generic file syncing service such as Google Drive or Dropbox. Those services are less of a target for hackers than dedicated password managers, and even if someone obtains that file, your passwords will be safe as long as your master password is strong.

Specific KeePass clients I recommend: https://keepassxc.org/ on desktop, https://github.com/PhilippC/keepass2android on Android.

Re: The "email is authentication" pattern

#470

Post by conradklnspl »

EnigmaFlare wrote: post #406
SPBS wrote: post #272

Wow, that's awful. So they abuse "forgot your password" as a login method, with the added obstacle of having to come up with a random password every time. And they don't see any problem with it. My hunch is that all these people are very non-technical users.

I do that for some sites. It's the initial effort required to set everything up that's the obstacle. This kind of behavior is taking the easiest route at every step instead of investing time into making the future easier. I stopped using a password manager after it got hacked and haven't bothered setting up a new one. The most annoying sites require you to confirm your throwaway password or log in again using it, and…

> Then keeping on top of the news for the rest of your life to see if your password manager is going down the gurgler or been hacked. Also, will my passwords be available when I travel to a country with restricted internet? Who knows. Can I export my passwords to any other password manager or a text file if I need migrate? That's part of the research needed to even get started using a password manager.

These are pretty much the exact reasons I created https://github.com/conradkleinespel/rooster. It's a simple password manager for the command line. It's offline. It's open source. It's stable. It can export passwords to plain text in different formats.

And its feature-set is intentionally limited, so I can maintain it with little work, to avoid it going down the gurgler. It's been available and maintained since 2015.

Post reply on HN