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

431–440 of 474 posts

Re: The "email is authentication" pattern

#431

Post by stemlord »

gloosx wrote: post #236

>why they do this There is always a simple answer to such question, and it's usually about some inconvenience the service provider decided to set-up for the user. In this particular case I think the answer is obvious: email provider usually have a session which never really ends, and just sits there logged in unless the browser cache is wiped. Make your service auth token to live for the same time as Gmail's, and as…

Preach. I'm tired of platforms nannying me with session limits and forced 2fa. Just have toggles in the settings

Re: The "email is authentication" pattern

#432

Post by cx42net »

There are two (deep) thoughts about this article.

First, about using the "Lost password", saying “huh, I never thought about why” is an easy way out with not much of a research from the author (sorry). One of the main reason people do that is because websites are enforcing dumb rules for a password that user tend to repeat on every websites (Your password must be 16 chars long, with lower and upper case, numbers and special characters. No more than 2 identical characters in a row ... yes ... I'm looking at you Twilio.com). Of course in that scenario I'll hit my keyboard in a random way and never login using my password.

But this article leads to the alternative; login via email. Some HNers here have mentioned having implemented that on their website, either by sending a one-time login link, or a verification code by email. We did that too for ImprovMX.com initially, and it has a lot of advantages (no password, no password-lost flow, no security measures for storing the password, etc). But it turns out it also have quite a few downside that we haven't thought about:

1. Emails get lost. We had quite a few support request because users couldn't connect to our service because the login email never arrived. This is a major issue, mainly when user wanted to upgrade but couldn't because of that. If you decide to implement this, you must use a really good email provider (Postmark is really good. Mailgun, not so much) 2. Emails are async. When your user goes to your website, they want to connect now. Waiting for an email can take quite some time and they might loose focus 3. Security "measures" will tell you to not indicate if the email you entered is valid or not, to avoid listing your users (... I won't go in that); If you implement login by email, it means your user will enter their supposed email, you'll tell them something like "If your email is registered on our website, you'll receive a one time login link", wait what feels like an eternity to get the login email in their inbox, and at some point wonder if the email they entered was the right one. Will try another, wait, rince and repeat.

So yeah, relying on email move all the security issues and added workflow back to a trusted service (login/lost password/2FA/OTP/etc to services like Gmail) but it will definitely add friction too.

In the end, it depends on what service you offer.

Re: The "email is authentication" pattern

#433

Post by ddmf »

This is why I skip the password step altogether.

We do have a list of customer email addresses already linked to the information they can view - if they enter their email address and it's in the list they get a link that will log them in for 12 hours and can see their associated data. If their email address isn't registered they're told to speak with their sales rep.

This of course trusts that email accounts are the highest level of security a user has, which it should be because so much relies on it these days.

Re: The "email is authentication" pattern

#435

Post by account42 »

dagw wrote: post #408
bburnett44 wrote: post #336

Earlier quoted context omitted.

Is a bank deposit box not insured against those things? I've never really thought about it but always assumed they would be

Probably varies from bank to bank, but in my experience you have to specifically buy separate insurance if you want the content of your deposit box insured. The big problem from the bank's point of view is that, unlike your bank account, the bank doesn't know what you have in the box and thus has no idea what to insure it for and no way to verify any claim.

More importantly the bank doesn't profit more from something more valuable being in your safety deposit box so it doesn't make economic sense for them to be the one insuring it.

Re: The "email is authentication" pattern

#436

Post by jerf »

bscphil wrote: post #127
jerf wrote: post #113

Earlier quoted context omitted.

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

I don't think this is right. If there's a shared secret like a TOTP seed, that's in theory a "something you know", but if I don't know it, then who does? The point of "something you have" is that you own a device that "knows" it for you, and you never even need to see or expose the underlying secret, you just copy a token proving that the device you have knows the secret. I think that does count as an additional fact…

"that's in theory a "something you know", but if I don't know it, then who does"

An attacker. Your knowledge is much less interesting that the knowledge the server has, which is what the attacker can obtain. Grabbing a TOTP key out of a database is not materially different than a password.

TOTP's different characteristics mean it's harder to intercept, but passwords tend to be stolen nowadays moreso than intercepted, if only because you can intercept only one at a time but can steal the entire database.

The different characteristics mean it can add a bit of utility to a normal password, but I think it's less night-and-day than it was presented as.

Re: The "email is authentication" pattern

#437

Post by jerf »

lxgr wrote: post #397
jerf wrote: post #113

Earlier quoted context omitted.

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 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 degree outright wrong, because it is focusing on the wrong thing. Look at it the way I'm looking at it and the authentication questions become richer and easier to understand.

Unfortunately, it also means that there's more things that are either hard or impossible than the have/know/are methodology promises, because two of the things that methodology promises effectively don't exist. (Unless you are controlling physical access, and willing to spend a lot of money on hardware and human verification of the correct use of the hardware.) But since I believe that is an accurate reflection of reality, blame reality, not the model.

Re: The "email is authentication" pattern

#438

Post by verzali »

kibwen wrote: post #343
paxys wrote: post #320

Earlier quoted context omitted.

Banks have been a thing almost as long as money.

And the notion of credit has been a thing even longer than both money and banks. You don't need to carry money around for every little transaction if people know you're good for it someday in the the future.

Don't you need an idea of credit for money to work at all? You need to be able to trust that the shiny rock you give me today for my wheat will be worth anything tomorrow when I want some of your meat.

Re: The "email is authentication" pattern

#439

Post by throwaway290 »

Djdjur7373bb wrote: post #369
throwaway290 wrote: post #318

Earlier quoted context omitted.

Either shuffling those keys stored in N different deposit boxes is overly complicated for a normal person, or it is not overly complicated for a moderately dedicated baddie either

Unless the "baddie" in this case is the government, why would it be easy for anyone to obtain access to multiple secrets stored in multiple boxes/banks? Multisig is a pretty common setup for crypto and there is software that makes it easier.

Can you show how it can be easy to use in normal life for a regular person and at the same time really difficult for the attacker?:)

Re: The "email is authentication" pattern

#440

Post by Sammi »

WA wrote: post #388
eddd-ddde wrote: post #352

Earlier quoted context omitted.

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.

When do you ask for a password? Do users have to seek it out themselves?

Can users still login using only email after setting a password?

Post reply on HN