Hacker News new | ask | show | jobs
by stephenr 3287 days ago
> I disagree. With opportunistic encryption, if the recipient' server supports STARTTLS, then the communication between the sender' server and the recipient' server is encrypted using TLS. Nowadays, all major email service providers support STARTLES.

With regular passwords via a browser, you can ensure the channel is encrypted via HTTPS.

Opportunistic encryption is exactly that: it uses encryption if it can, but will fallback to unencrypted if not.

How is "sometimes encrypted, if its available" not less secure than "always encrypted, unavailable if encryption doesn't work"?

> Just use the GMail to avoid the delay with fetching third party accounts.

So, you're simultaneously suggesting that everyone use 'email links for login' and suggesting everyone use a single email provider? Sure, that doesn't sound terrible at all.

> most users don't use a password manager

What's your basis for this? Every browser in use today has a password manager built in. People promoting these bullshit "not a password" alternatives always claim "average people" don't use password managers, but never present any evidence of that.

> If the user uses an email server that doesn't support STARTTLS, then theoretically an attacker could request a password reset and "catch" the unencrypted email.

Firstly - the main security concern with emailed 'login' links isn't the transport at all - it's storage/accessibility via the mailbox. Breach the mailbox, and you've breached the third party sites. The part people always ignore when suggesting emailed links as an alternative, is that if an attacker breaches your mailbox, they could conceivably use that to access your third party service that uses login links, and the victim would never know, because there is no password being reset, no killing of previous sessions.

> My conclusion: Passwordless login is an interesting solution. But there are other issues to consider, discussed in other comments (email delivery latency/greylisting, ergonomy, need to remember which email address you used, etc.).

My conclusion: password-less login is a thing that exists via public key cryptography: see ssh, TLS client certificates. Emailing links to people is nothing more than a fucking stupid idea, and frankly it's ridiculous that your "other issues to consider" makes literally zero mention of any security concerns.

1 comments

> With regular passwords via a browser, you can ensure the channel is encrypted via HTTPS.

I agree. But there is still the issue of forgotten passwords and the infamous password reset emails. How do secure them in the face of "opportunistic encryption with STARTTLS"?

> So, you're simultaneously suggesting that everyone use 'email links for login' and suggesting everyone use a single email provider?

As I said in another comment, I was specifically answering to a sentence starting with "If you use GMail with several accounts and POP3". My point being, if you are already using GMail, then just use your GMail address to avoid the delay in fetching other POP3 accounts.

But it's true that password login has the strong advantage over passwordless login to let you login instantly if you (or your password manager) remember your password.

> > most users don't use a password manager > What's your basis for this? Every browser in use today has a password manager built in. People promoting these bullshit "not a password" alternatives always claim "average people" don't use password managers, but never present any evidence of that.

My basis for this is that, year after year, I keep reading publications showing that most users reuse the same password on multiple websites. Just search for "password reuse statistics" and you'll find a lot of evidence: https://www.google.com/search?q=password+reuse+statistics. "Average people" probably use the password manager built-in in their web browser, but it doesn't necessarily solve the main issue which is password reuse. Since you're asking for evidence, what evidence do you have to support your own claims?

> Firstly - the main security concern with emailed 'login' links isn't the transport at all - it's storage/accessibility via the mailbox.

I agree. My mistake to emphasize attacks on the transport when the biggest worry is the storage.

> The part people always ignore when suggesting emailed links as an alternative, is that if an attacker breaches your mailbox, they could conceivably use that to access your third party service that uses login links, and the victim would never know, because there is no password being reset, no killing of previous sessions.

This problem is not ignored. We can for example watch IP addresses used to connect, and notify the user connecting on the "usual" IP that we have detected another connection on a new/unseen IP. I'm not saying this is easy, but this is probably solvable.

Moreover, I notice that most non-technical users around me, when they are unable to connect because their password is refused, tend to think this is an error on their side, and just reset the password, without thinking they could have been hacked, which weakens your argument.

> My conclusion: password-less login is a thing that exists via public key cryptography: see ssh, TLS client certificates. Emailing links to people is nothing more than a fucking stupid idea, and frankly it's ridiculous that your "other issues to consider" makes literally zero mention of any security concerns.

A civilized discussion would be easier if you could avoid the words "fucking" and "ridiculous". You're claiming that passwordless login ignores important security concerns. I think that the human factor (forgotten passwords, password reuse, etc.) is big in the list of security concerns, and passwordless login can be an — imperfect — answer. That said, I agree that using public key cryptography in the vein of ssh would be a lot better than password and passwordless login combined.

> I agree. But there is still the issue of forgotten passwords and the infamous password reset emails. How do secure them in the face of "opportunistic encryption with STARTTLS"?

Realistically, you can't without some secondary auth for password resets (i.e. secret questions, a phone call, or things like 'send a message signed with your public key' (which the service operator obviously needs to know beforehand) - all of which are either easy to game, or not particularly user friendly for the non-technical - but even without those options, the password reset scenario still has one advantage over the 'login link' system: at the very least the user will know the breach occurred, because they will a) lose their current sessions and b) not be able to create new ones (due to the password having changed).

> My point being, if you are already using Gmail, then just use your GMail address

There are plenty of reasons not to use the 'primary' email address of a system which also offers pop3 download into webmail, and your response just highlights how short sighted this "solution" is.

> "Average people" probably use the password manager built-in in their web browser, but it doesn't necessarily solve the main issue which is password reuse.

So if we agree that most people probably do use the built in password manager, wouldn't a better solution be, for the password manager, which knows all your passwords anyway, to take action, and suggest better passwords? "Hey, we just noticed you logged in with a password that you've used on at least 389 other sites. That's not very secure, if you'd like to change your password for this site, <Browser> can suggest a strong password, remember it for you and sync it to your other devices too".

> Since you're asking for evidence, what evidence do you have to support your own claims?

You just admitted that average people probably use the password manager built-in. It's pretty well observed now that non-technical people (and even technical, in some situations) will blindly click "OK" or "Accept" or "Yes" to whatever buttons appear on screen when they're trying to achieve something. I don't have any evidence I can link to, just 14 years of anecdotal stories about how people clicked "yes" to "do you really want to delete this now?" and then call helpdesk because it deleted something, etc.

> This problem is not ignored.

It's never mentioned as part of the actual proposal, it's always a "well you could do X and then Y and then Z" and pushes responsibility to the USER to determine if someone else is using their account.

> We can for example watch IP addresses used to connect, and notify the user connecting on the "usual" IP that we have detected another connection on a new/unseen IP.

a) most people barely know what an IP address is, much less what theirs is. Even with GeoIP info, you still have the risk of people being attached by someone actually in, or spoofing, a close proximity. GeoIP info for my current IP has recently changed to my current city, but recently showed me as being in a city 70km away, with a population of 10M people.

> I'm not saying this is easy, but this is probably solvable.

So is a cure for Cancer but I'm not going holding my breath for that either.

> Moreover, I notice that most non-technical users around me, when they are unable to connect because their password is refused

A decent auth system would notice two successive password resets in a short span of time, and send a notice with the second one that a password reset was just performed <X> minutes/hours/days prior, with information to contact the service provider if the earlier reset was not initiated by the account holder.

> A civilised discussion would be easier if you could avoid the words "fucking" and "ridiculous".

Maybe I should have changed the use of certain words, so let me be more clear:

The idea is ridiculous:

    ridiculous |rɪˈdɪkjʊləs|
    adjective
    deserving or inviting derision or mockery; absurd
Discussing an authentication method and not discussing the security concerns is fucking stupid:

    fucking |ˈfʌkɪŋ|
    adjective [ attrib. ] & adverb [ as submodifier ] vulgar slang
    used for emphasis or to express anger, annoyance, contempt, or surprise


    stupid |ˈstjuːpɪd|
    adjective (stupider, stupidest)
    lacking intelligence or common sense

> You're claiming that passwordless login ignores important security concerns. I think that the human factor (forgotten passwords, password reuse, etc.) is big in the list of security concerns

Sure, this and every other concept for emailed links for auth addresses that same single factor: people re-use, and forget passwords. I'm claiming that every "passwordless" solution based on email login links I've seen, conveniently ignores any problem their "new" idea introduces, some of which I've highlighted above.

Some like Homakov go a step further: when I suggested that his version of this concept is insecure because mailboxes aren't secure, his response was literally "Yeah but I'm not trying to solve the whole problem". Right. Well I've got a great cure for an ingrown toe-nail: I'll cut off your leg. You won't be able to walk, but I'm not trying to solve the whole problem.