Help me find the flaw in this authentication paradigm

Recently, I tweeted this:

It prompted a discussion with my super-colleague, Mark, about why no one has implemented that as an authentication process yet. Consider a process like this (I’ve bolded steps that the user would actually see):

  1. User enters email address, clicks LOGIN.
  2. User is prompted to close their browser tab or window, then go check their email.
  3. Cookie is set on user’s browser.
  4. User clicks time-sensitive, encrypted link in the email which opens a new tab or window.
  5. Cookie and link are required to actually be logged in.
  6. User is logged in.
  7. Server is flushed and encryption algorithm changes.

Four steps.  No passwords.

So, what is the flaw in this process? How is it not both as quick and as safe, if not safer, than the existing authentication paradigm of creating a new password every time you go through the forgot password flow?

Just to be thorough:

  • What if I type in the wrong email address? That would send an email to an account you don’t have access to and would thus prevent you from signing in as that account-holder.
  • What if my email gets hacked? First of all, the links in these emails are active for a brief window of time, say 30 minutes at the very most.  Second, if your email has been hacked you are already screwed because the hacker can reset your password to every account in the current paradigm anyway.
  • What if your server gets hacked? Again, the generated url is valid for a very short time and is then completely erased from the server.  Also, logging in requires not just that url, but also the presence of a cookie on the same machine.  Further, the algorithm changes constantly. Thus, it would have to be an inside job performed in under a minute, just to gain access to a single login. Not a very economical way to make a living.

Help me find the flaw in this because, for the life of me, I can’t figure out why every website doesn’t already work this way, saving us all from the utter farce of passwords.

3/4/2013 Update:

Thanks to @andystalick for pointing out the post I had been searching for before writing this one: Is it time for password-less login? Its follow-up is also essential: More on password-less login.

And more on why we need SOMETHING other than the current password system: 30 years of failure: the username/password combination

Help me find the flaw in this authentication paradigm

6 thoughts on “Help me find the flaw in this authentication paradigm

  1. rufo (@hilare_belloc) says:

    if you lose access to your email account you can’t change your email on the website, unless you’re already logged in
    (cf logging in with a password and updating your email in the traditional flow)

  2. Marc says:

    If I re-state your proposal as: Use Google two factor authentication every time I enter a site and don’t allow me to store passwords, then I think you have the answer: You are providing a mechanism to speed that process by emailing a link to click the second factor, and you reduce the frequency at which the second factor changes.

    So, I’ll say I think you’re on the right track, because I don’t understand why now that Google has made two factor authentication very easy, everyone doesn’t use it for everything, more or less.

  3. BJ says:

    This all sounds doable to me, but I do see a few flaws.

    1. The processes for managing tons of time-sensitive, encrypted links for all users on the server side might be very costly from a performance and maintenance standpoint.

    2. I think it’d be a difficult process to explain to people

    3. It’s more-than-slightly inconvenient to have to refer back to your inbox and click an additional link just to access your account within another web app. People are used to the u/p scenario, which allows for instantaneous access. This would look/feel like a degraded UX.

  4. @BJ: My point is that if I’m going to have to go through the “forgot password” flow every time I log into a site anyway, why not make it the primary path? I’m already having a bad user experience, just with an added layer of guilt and frustration.

    See my update to the original post for some people discussing this in more and better detail!

  5. I think BJ’s number 3 is the most important for me here – if you DO actually succeed in usually remembering your passwords (which I do, but I’m not sure how common this is), sending me to my inbox every time I try to log-in somewhere will be a significantly degraded user experience.

    Also, it offloads the UX to my browser/email program combination, which maybe wouldn’t work quite as well if were using a separate email program as it would for people using webmail – would it accidentally open a separate instance of Outlook, maybe? Would it interrupt me in the middle of typing an email? That’d be annoying.

    Finally, how would it deal with systems that allow you to remain logged in? I don’t log into Twitter every day, for example, it’s just stored in my browser history. Would the system be able to continue to provide me that level of ease of use without passwords? Just with a browser cookie, perhaps?

  6. I strongly urge all the commenters here to follow the two links I posted above — they address many of the scenarios you mention that I failed to identify (which I assumed would happen; hence the title of this post).

    @Mike I’m not sure what you mean about a mail client interrupting you in the middle of typing an email. Does that happen when you receive a new email now?

    Regarding your first point, if you have no trouble remembering your passwords, then obviously there is no UX flaw for you. My experience — and research backs this up — is that if you follow security guidelines on creating passwords, they are likely long, not memorable, and different for every site. That does not bode well for people trying to remember all of them.

    As far as remaining logged in, why would that be a problem? The site could just do what all sites do now, provide a “keep me logged in” checkbox and give it an expiration of 30 days or something.

Leave a Reply

Your email address will not be published. Required fields are marked *