Login via email, great idea or terrible idea?


  • Banned

    One big annoyance I have on many sites on mobile is that I need to remember my password. My password is tucked away in a password manager so I need to dig it up just to log in to a site.

    I was thinking, what if there was an extra link on login pages that just said "login via email", have it send a once-off token to your email for logging in. So the workflow would be, click on "login via email", get email, click on link in email, you are logged on.

    It would make logging in when on mobile devices, other peoples computers, etc much simpler.

    Great idea? Terrible idea?


  • Considered Harmful



  • Why not OpenID?


    Filed under: because Google's discontinuing it


  • Discourse touched me in a no-no place

    We're not there yet. Too many scenarios still which can't handle those sorts of stateful workflows. (There's more to the internet than simple user-facing stuff.)


  • Discourse touched me in a no-no place

    @sam said:

    Great idea? Terrible idea?

    How will you cope with a user completely losing access to the email account that they registered with? Any process you put in place to deal with that (and you have to have something because email mailboxes aren't guaranteed to exist indefinitely) will be a weak-point in your auth scheme.


  • Banned

    @dkf said:

    How will you cope with a user completely losing access to the email account that they registered with? Any process you put in place to deal with that (and you have to have something because email mailboxes aren't guaranteed to exist indefinitely) will be a weak-point in your auth scheme.

    I guess I would only want this kind of scheme, in conjunction, with what we have today, as a generally accepted "convenience method", everyone already does "forgot password" thingy.



  • @sam said:

    I guess I would only want this kind of scheme, in conjunction, with what we have today, as a generally accepted "convenience method", everyone already does "forgot password" thingy.

    And most sensible websites ask you a question, too. You need the "something you know" part of 2FA even if you don't have the other one. Otherwise, someone gaining access to your email would be completely catastrophic.

    Imagine that I have access to your mail account. I haven't changed your password, so I'm sitting there waiting for an email. You try to log in into your bank, get an email, I quickly read this email, mark as unread and follow the link.

    You get the "access denied" message, blame the solar flares and try again - this time succeeding. Only to see you're $infinity poorer.



  • This needs to be a poll!

    Anyway, given that most sites currently allow you to reset your password by email, access to the email account is really all that's required to log in. Under those circumstances, I think a "login via email" option would be perfectly sensible.


  • ♿ (Parody)

    @error said:

    http://passwordless.org/

    I hate this new thing of showing some kind of header that fills the entire viewing area and hides the actual text down below. It took me a minute to realize that's what this site was doing. Who thought this was a good idea?



  • I'm pretty sure it's just medium.com doing that.



  • Terrible idea.

    Only about 70% of outbound mail from Gmail is encrypted with STARTTLS; Only about 60% of inbound mail to Gmail is encrypted with STARTTLS.

    Comcast is only just beginning to beta test STARTTLS. Verizon apparently has not yet implemented it at all, either.


  • Discourse touched me in a no-no place

    Even TTRSS uses it, so It should be easy to implement...



  • That's 2FA, as opposed to what @sam proposes (which is basically backward 1FA).



  • The web absolutely NEEDS a standard authentication protocol. The link about passwords being obsolete is right, anyone who defends that users should memorize a different password for every site and enter it every time they want to log in (yay phishing) is an idiot.

    Personally I think it should involve a physical element, like a smart card (those still exist right?), an USB key or perhaps their cell phone (though that has some problems in its own). To the average user, keeping a small physical object secure is probably much easier to understand (and accomplish) than keeping a magic string secure. So you could walk around with your Facebook and Gmail logins in your wallet. Need to use a public computer? Plug it in, scan your fingerprint or enter your PIN or whatever, and bam, you're logged in. Pull it out, and nobody else can access it, even if the machine was malicious (though they could have done something evil in the meantime, not much we can do about that).

    Obviously there are still lots of problems to solve, like what if you lose it or if someone steals it, etc. I suppose most people would end up relying on a trusted third party to keep a copy of their keys for them. But what the hell, it's still better than what we have now.


  • Banned

    You can read my proposal here, but TL;DR requires browsers to support universally logging in to the browser across all platforms, sort of as Chrome does now....



  • @codinghorror said:

    as Chrome does now

    I dunno. I really dislike these kind of things. Quite often I use other people's computers. I'd rather enter one password for one site on it, than give it access to my entire "identity".

    Also, I don't necessarily have the same identity for each site. The Stack Exchange thing works well, but it works well only because Stack Exchange is one organisation. It's basically all the same website with different subcategories. One identity makes sense there. It's not separate sites. The cultural expectations are the same across the board and every Stack Exchange board is ultimately run by the same people.

    But usually, separate sites are, you know, separate sites. I'm not necessarily the same person here as I'd be on another forum. To come up with a 'philosophy' as you so often do: outer_personality = inner_personality % environment. If I get only one identity, all my expressions everywhere would have to be modulo every community's expectation everywhere. There wouldn't be anything left. Easy logins are not worth that.



  • @anonymous234 said:

    The web absolutely NEEDS a standard authentication protocol.

    Cue the token xkcd... There's OpenID, there's Facebook login, Google Authenticator, and some more stuff I've never cared about.

    And relying purely on a physical object is a WTF. Somebody snips your wallet and has access to everything, from your Facebook through your email to your porn site premium accounts? Thanks, I'd rather memorize a random line from "War and Peace" or something.

    Now, combining the two is a whole other idea. But there's still the 15-competing-standards hurdle to jump over.

    @marinus said:

    I'm not necessarily the same person here as I'd be on another forum.

    Well duh, I'd really hate to have my LinkedIn account linked to my TDWTF account.


  • Discourse touched me in a no-no place

    @anonymous234 said:

    The web absolutely NEEDS a standard authentication protocol.

    With plenty of experience, the only thing that comes even close to that is Basic Auth (possibly over HTTPS). Which is 💩

    There are other ones about as you note, but by far the most widely deployed is the worst of the lot (because it's simple and every general client supports it). Virtually all the fancier ones require cookies and javascript and an actual browser with the user right there; that's only a small fraction of use cases.

    It's all compounded by the fact that when almost anyone with a clue about security sees the 💩, they go 😱 and set about inventing their own new auth scheme that will fix all the problems. A few months/years later, they finish their ✨ brand ✨ new ✨ solution ✨ and let users have a go at it and find that all they've done is make the 💩 pile even higher. It's amusing the first few times, but once you've seen it happen dozens of times it really palls.

    (OpenID is one of the better efforts, but it only has a very restricted domain of applicability. SSH's key-auth is even better, as it offers real usability advantages, but isn't used for HTTP at all.)


  • Banned

    What killed OpenID is that it completely ignored one of the truest facts of online identity: basically that for 99.9% of the population, identity = email.

    OpenID assumed the world was OK with identity = URL. No, not so much.

    Filed under: Oh, you'd like to mail a password reset to WHERE EXACTLY?



  • @dkf said:

    With plenty of experience, the only thing that comes even close to that is Basic Auth (possibly over HTTPS). Which is 💩

    Why not digest auth? It's at least ✨💩✨


  • Discourse touched me in a no-no place

    @codinghorror said:

    What killed OpenID is that it completely ignored one of the truest facts of online identity: basically that for 99.9% of the population, identity = email.

    Shibboleth is better (and actually quite close to OpenID but with less suck) but has zero traction outside large institutions. Kerberos is another decent security system that nobody deals with without a big company (or government, or other large org) to support it. Then there's the whole business of identification of users via client certificates; it would be great, except that users absolutely detest doing anything with certificates at all and just balk at doing anything like that.

    And email's just a great honking big pile of disaster and WTF.

    I hate dealing with security specialists. This comes of having had a lot of experience with them. The area attracts the user-hating autistic pedantic dickweeds. They might not flat out spend their time insulting you (unlike some people in other areas) but producing something that ordinary users will accept and actually want to use is like pushing an octopus up a saguaro cactus with Zune charger cable.



  • There are three kinds of technology:

    • 💩
    • ✨💩✨

  • Discourse touched me in a no-no place

    … one … two … ?


  • Discourse touched me in a no-no place

    @Maciejasjmj said:

    That's 2FA,

    If you're also requiring a password, yes. If not you treat the auth as a OTP.



  • The third had an off-by-one error.


    Filed under: Three hard things...



  • @boomzilla said:

    I hate this new thing

    FTFY.

    For what it's worth I completely agree.


    Filed under: Not all "progress" is progress


  • @boomzilla said:

    I hate this new thing of showing some kind of header that fills the entire viewing area and hides the actual text down below. It took me a minute to realize that's what this site was doing. Who thought this was a good idea?

    But But But ... Marketing wants a splash page and I told them it was so 90's! Isn't this so much more better? I mean it's demonstrably NOT a splash page since we're using a fancy SPA! WOO! GO MARKETING TEAM!


  • Discourse touched me in a no-no place

    @ben_lubar said:

    Why not digest auth?

    It's quite a lot more complicated, and so it is less frequently implemented correctly. (Client-certificate solutions are quite nice from a code perspective, but users detest them.)


  • Discourse touched me in a no-no place

    @boomzilla said:

    I hate this new thing of showing some kind of header that fills the entire viewing area and hides the actual text down below.

    Also: font-size: 22px;



  • font-size: 222px;
    


  • @error said:

    http://passwordless.org/

    This still requires access to email or SMS. If email, you probably are going to have a password for that still so that access is limited to a valid user. And the problem with actually implementing this is that it narrows the point of attack to the SMS or email chain, and once that's breached, then everything is breached. Much better to have security protocols everywhere which spread the points of attack so that there isn't just one single point of attack. (You could argue that this isn't the case because of password resets, but remember that many password resets require some sort of secondary validation, such as a security question).



  • @anonymous234 said:

    Personally I think it should involve a physical element, like a smart card (those still exist right?), an USB key or perhaps their cell phone (though that has some problems in its own).

    But this has it's own complications:

    • Handling lost/stolen tokens (you mentioned this)
    • How to handle access from devices that can't attach the token? For example, say you have a USB key, how do you get access on your phone which does not have a standard USB port?
    • What about shared accounts, say between spouses?

    As for biometric access, I think that this shows the weakness in those methods on a mobile platform. And don't think for one second that the public is going to let mobile access be taken away from them.


  • Discourse touched me in a no-no place

    @abarker said:

    As for biometric access, I think that this shows the weakness in those methods on a mobile platform.

    It's worse than that:

    But biometrics cannot, and absolutely must not, be used to authenticate an identity. For authentication, you need a password or passphrase. Something that can be independently chosen, changed, and rotated.



  • @PJH said:

    It's worse than that:

    But biometrics cannot, and absolutely must not, be used to authenticate an identity. For authentication, you need a password or passphrase. Something that can be independently chosen, changed, and rotated.

    I liked this bit from that:

    But let's just say you're okay with Apple sharing your fingerprints with the NSA, as I've already told you, they're not private at all. You leave them on everything you touch. And let's say you're insistent on using fingerprint (biometric) technology because you can. In that case, your fingerprints might identify you, much as a your email address or username identifies you, perhaps from a list.


Log in to reply