1. 18
  1.  

  2. 11

    There is a third dimension: user perception. Even though hiding details about account existence is useless, people think it matters, and will therefore judge you negatively for “revealing” this information. You’re fighting the good fight to educate people, but too often it’s easier to play the game the way it is.

    Also, the signup leakage problem is not unfixable. If you use email as account login, which is increasing common, just always reply “We’ve sent you an email with signup details”. Then either send the signup email or a reminder that they already have an account.

    1. 1

      In my experience, the lack of information has been universally panned, but people accept it. They don’t fight it, but I feel it’s not because they like it but because Very Important Companies “say so”. Has your experience been different?

      1. 3

        I feel almost certain I received a customer complaint that we were leaking information by saying “username not found”. But maybe I’m only imagining it happened, because I know it would happen. :)

        Related: I remember people losing their minds at some change or another that Google made to gmail which “revealed” which addresses were valid and which weren’t. Never mind that you can get instantaneous answers to that question simply by sending “RCPT TO xxx” to their incoming mail server. “But now there’s two ways to find out!” As if that matters.

        I don’t think many people care. The ones that do are extremely noisy though.

    2. 2

      Yeah, I’ve found the same thing. Clients have sometimes heard of the idea of not leaking information, but the “we’re sending you an email whether you are a member already or not” thing is a step too far. Which is a pity, since I really like the “interested? Enter your email and we’ll send you a code!” approach to creating accounts … simple, elegant, hard for the user to accidentally drop out of.

      (see also my blog post: http://nick.zoic.org/etc/the-selfish-secret-logins-without-passwords/ )

      1. 2

        Nice! I have been thinking along the same lines, but slightly more paranoid. I’d make the emailed code a one-time code, with a 20 minute (or so) timeout. If you want to sign up from multiple devices, send multiple emails. Second, don’t log people in automatically when clicking the link, but present a form:


        Log me in:

        • [x] until I close the browser
        • [ ] for 48 hours
        • [Submit]

        The first would create a session cookie. Perhaps it is overkill… :-)

        1. 3

          Thanks! Yeah, that’s a good improvement for shared PCs, I hadn’t really thought about those. The email could also contain multiple links:

          • [Click here to log in for 24 hours, or until I exit the browser]
          • [Click here to keep this device logged in forever]

          Also, making the cookie secret different from the emailed secret means that you can add a “logout” button to your site which invalidates the cookie secret, without logging out any other devices you configured from the same email.

          1. 2

            Inspired by your post I wrote up my own thoughts: http://www.superloopy.io/articles/2014/passwordless-registration-and-login.html

            (I deliberately kept it simple and omitted details about cookie lifetimes, as that is not core to the idea.)

            1. 6

              Some problems I see with your scheme:

              • Email is not reliable. As someone currently battling with problems e-mailing Gmail users, most of my service’s e-mails go to a user’s spam folder by default and sometimes never arrive at all despite being accepted by Google’s SMTP servers. Adding the from address to the user’s contact list doesn’t solve it. In those cases a user wouldn’t be able to login at all. Even on a successful e-mail delivery, there can still be delays in the process that you can’t do anything about which will just frustrate the user. Greylisting and other tricks will absolutely delay your delivery to a user’s mailbox by at least a few minutes.

              • It requires a user to have two things open, a web browser and e-mail client. On a mobile device, especially one like the iPhone that doesn’t support push/idle e-mail for many servers, a user would have to wait up to 15 minutes for an e-mail to arrive (or at least be notified about it).

              • You are reducing the security of the user’s account to the security of all the SMTP servers in between you and them, instead of a direct SSL connection. I realize password reset e-mails do the same thing, but at least for a service like mine, I consider password resets a bad thing and clear all pending messages on a user account if the user goes through with the password reset.

              1. 1

                Thank you for responding!

                I’ve generally found email reliable (as a user) but I can see how it might be difficult to keep your emails from being blocked. I don’t have experience with sending emails at scale, so don’t know how much it takes to get blocked. Greylisting is an important point too, and one I had forgotten to consider.

                Do you mind me asking how you currently send emails? I did an AWS course recently and they mentioned they have a deal with Google which means if you use their email service you’re less likely to get blocked. (If I understood it correctly Google instead reports to AWS if users mark their mail as spam and they in turn crack down on the sender.)

                I accept the inconvenience, particularly on mobile devices, of the email roundtrip and delays particularly on login. (I think on registration you could just log the user in immediately.)

                I also realise there is a window of opportunity for attackers that have access to SMTP servers between the site and user. My gut-feeling is that by making the link self-expiring and valid for one time only the window of opportunity would be reduced sufficiently to be favourable to user-chosen (and often weak) passwords, but I don’t have any data to back that up and might be wrong. I failed to consider a malicious or compromised SMTP server though.

                BTW, clearing messages on a password reset is interesting. Thank you for that tidbit!

                This has definitively given me something to chew on.

                1. 5

                  Do you mind me asking how you currently send emails?

                  Nothing fancy, just mail from Rails or some other process injected into local Postfix, which pipes through dkim-proxy and signs most messages, then back to Postfix and out to the destination MX. The servers have proper reverse DNS, the IP addresses are dedicated and are not on any RBLs, the mails get DKIM signatures that are valid, a List-Unsubscribe header is added, the Auto-Submitted header is set to auto-generated, and the envelope sender is the same as the from address, which is monitored for bounces.

                  This is all about as proper as one can get for running one’s own mail server, yet Google still decides to auto-shitcan most of these messages and in some cases never even delivers them to the end user despite being accepted by their SMTP server and the user having the e-mail’s from (and envelope sender) address in their contact list. I’ve filled out Google’s ridiculous e-mail complaint forms multiple times, but like pretty much everything else with that company, it’s an exercise in futility.

                  Worst of all, when you try telling users that they can’t get your e-mails because Google is dropping them, the user thinks you are the problem and they have no way to contact Google even as a user.

                  I miss the days when you could just call up an ISP and talk to a real person with the ability to look at mail logs and figure out what was going on.

        2. 1

          I found your blog post really interesting! For a long time I have thought that passwords aren’t a very scalable solution to authentication on the internet but I guess it does hinge on securing the browser more.

          1. 3

            Yeah, that came as a bit of a shock to me. I’ve been a Linux and OSX desktop user for a long time, and I just assumed home directory encryption was everywhere by now! Apparently Windows can do it, but it isn’t commonly used.

            It seems to me though that the browser could easily enable encrypting cookies along with stored passwords, and given that quite a lot of sites use long-lived cookies for password-free access this would be a rather good idea anyway.