Password-less login, continued

Last Thursday we wrote “Password-less login”, detailing our plans for building a password-less email login into Find Work. We had an ulterior motive to collect opinions from outside our organization so we can find any major flaws.

We received a bunch of comments on Lobste.rs and Hacker News (some supportive, some already doing this, some critical). This article will try to aggregate and address them.

Reframing our focus

We received some comments that zoomed in on a detail of password-ful login claiming that it wasn’t an issue. That’s missing the point of this decision.

The issue is humans are writing the software to manage/store passwords/authentication. We are error-prone and want to limit our attack surface area. How do we do this? Remove ourselves as an auth provider.

We are already using 3rd party services as auth providers (e.g. Google, Twitter, Facebook, etc) where all the authentication occurs within their domain. This similarly passes the buck to the email provider.

In the password-ful scenario, our service is the auth provider — we use email initially verify a common identifier (i.e. email) and then keep reauthentication contained within our application.

The problem with this is it’s a lot of pages (i.e. verification email, forget password initialization, forget password completion, settings page) with a lot of chances to get things wrong (e.g. too few rounds in hashing, using predictable forget password tokens, no session regeneration on forget password completion). While I can mostly guarantee that my team will get it right, I can’t guarantee that a first timer programmer will.

The purpose of this movement is to establish a simpler standard with less chances for error and less nuance for novices.

I’m sure some people are saying “Why would you let a novice programmer write your authentication software?”. Right, why would you?

It’s also a non-perfect world. Reasons might be: company is bootstrapping with no funding for senior engineers, not enough time to research best practices, poor code review process. Look at http://plaintextoffenders.com/ for fuck’s sake.

Okay, I think I’ve made my point on general focus. Now let’s work on direct comments/critiques.

Aliases

Comment: This is also known as one-time passwords (OTP) and magic links.

Response: Ah, I didn’t know that. Thanks!

References: https://news.ycombinator.com/item?id=13837620, https://news.ycombinator.com/item?id=13837409, https://lobste.rs/c/gvu9kv

Salting and hashing

Comment: Salting and hashing are good enough for preventing password leaks.

Response: Yes, this is good enough for password leaks. However, it’s a two way street. A poorly hashed password from another site reused on mine compromises the account on our site despite us putting forward our best efforts.

References: https://news.ycombinator.com/item?id=13837820, https://news.ycombinator.com/item?id=13837498

Paranoid leak

On a tangent to “Salting and hashing”, passwords can be captured via means outside of leaks (e.g. keyloggers, video cameras, submitting password to wrong server/application). There are defenses against this (e.g. using a sheet to cover keyboard, physical security, not being tired) but it would be even better to have a dynamic expiring token.

This is why we have things like 2 factor authentication. We are replacing the password based portion of 2 factor authentication with another token based authentication.

Greylisting

Comment: Verification emails have taken up to 60 minutes to arrive in my inbox or never arrive. It would be tedious/frustrating to deal with this on every authentication.

Response: You bring up a great point that we didn’t consider at first! We believe we can minimize the impact of this issue through a few means:

• Persisting sessions for 2 weeks since last access on an application that should be used at least once per 7 days (follow-up emails on job application cadence). This means ideally there’s no reauthentication necessary
• Providing alternate authentication providers (e.g. Google, Twitter)
• Using an established email provider with DKIM (e.g. AWS’ SES)

References: https://news.ycombinator.com/item?id=13838173, https://news.ycombinator.com/item?id=13837415, https://lobste.rs/c/80srph, https://lobste.rs/c/gvu9kv

Alternative authentication providers

On a tangent to greylisting, some people mentioned offering authentication via SMS, WhatsApp, Google Authenticator, or any other phone application. That’s totally in our line of thinking! Although, we should verify the security of such mechanisms first.

As we can use 2 factor authentication’s token system in any scenario, we can do the same for our 1 factor authentication! From https://twofactorauth.org/, it looks like the standard mechanisms are: SMS, phone call, email, hardware token, and software token.

References: https://news.ycombinator.com/item?id=13837970, https://news.ycombinator.com/item?id=13837409, https://lobste.rs/c/udckbq

Breach detection

Comment: I rely on detecting a breach due to my password being changed when I revisit my account. There’s no breach detection in password-less login.

Response: You make a great point and we hadn’t thought of that! If we zoom out, we should also consider scenarios for other authentication services (e.g. Google, Twitter). I don’t think there are any solutions in the general case yet.

In https://lobste.rs/c/47bos4, I proposed a blocking page on revisiting our application that requires approving new sessions. If you have any ideas for a better solution, we would love to hear them!

References: https://news.ycombinator.com/item?id=13838173, https://lobste.rs/c/p9bwc3

Browser extension vaporware

Comment: This magical browser extension you’re talking about doesn’t exist yet.

Response: You’re right but Rome wasn’t built in a day. We need time to build things and iterate. In fact, there was a semi-scary/semi-good idea on Hacker News about making it based on IMAP, https://news.ycombinator.com/item?id=13838262.

Chrome does support TCP via its Chrome Apps interface so maybe something is possible there. In general, browsers currently don’t support IMAP or TCP for that matter but there seems to be a W3C proposal in the works. If you have any ideas for a better solution, we would love to hear them!

References: https://news.ycombinator.com/item?id=13838262, https://news.ycombinator.com/item?id=13846347, https://lobste.rs/c/p9bwc3

Attribution

• Actual Advice Mallard meme, http://knowyourmeme.com/memes/actual-advice-mallard