Email-based Authentication

From a user's point of view, OpenID works something like this:

  1. You browse to a site you like that uses OpenID, and click the "login" button
  2. You enter your OpenID
  3. You are redirected to the site that authenticates your OpenID.
    Note: You may be asked to login with a username and password for that site if you haven't done so recently.
  4. You are redirected back to the original site you browsed to, and are automatically logged in

Today I got to thinking that this is quite similar to how the "reset my password" link on most websites works:

  1. You browse to a site you like, and click the "reset my password" button
  2. You enter your username or email address
  3. You Alt+Tab to your email client, or Ctrl+Tab to your web-based email client.
    Note: You may be asked to login with a username and password for your email server if you haven't done so recently.
  4. You Alt/Ctrl+Tab back to the original site you browsed to, paste in the newly generated password, and are logged in

In OpenID terms, I guess this means that email is a relying party.

Which makes me wonder: if a browser plug-in could automatically receive, extract and paste replacement passwords from emails, we'd get most of the benefits of OpenID without any adoption issues. Thoughts?

A picture of me

Welcome, my name is Paul Stovell. I live in Brisbane and work on Octopus Deploy, an automated deployment tool for .NET applications.

Prior to founding Octopus Deploy, I worked for an investment bank in London building WPF applications, and before that I worked for Readify, an Australian .NET consulting firm. I also worked on a number of open source projects and was an active user group presenter. I was a Microsoft MVP for WPF from 2006 to 2013.

28 Oct 2010

You forgot the "wait 10 minutes for the email to show up" part

28 Oct 2010

Or the "oops, it got stuck in my spam filter"

Caleb Vear
Caleb Vear
28 Oct 2010
You forgot the "wait 10 minutes for the email to show up" part

+1

This would work find if email was fast enough, but sometimes you can wait awhile. I find that sending and receiving with a lot of ISP and shared hosting mail accounts can take several minutes for the email to appear.

29 Oct 2010

Good idea, but unfortunately, you're still relying on people having the plug-in.

Ujjaval
Ujjaval
29 Oct 2010

Emails should not be the relying party. However it is a mechanism for identification.

What I would like though, is to be able to have OpenID, to access all emails from different service providers.. or just different emails through same login.

19 Nov 2010

I agree with what I think you mean, but I think you have your terms around the wrong way.

Every website that has an email-based forgot password function is a relying party, in fact they have an implicit trust reliance on any and all email providers.

The email system functions as the identity provider in the scenario.

I find it strange the reluctance of some sites to adopt OpenID for authentication (as a relying party) as they don't feel they can trust providers, yet are currently already trusting all email providers!

Do note, however, that there is one vulnerability in OpenID (and similar systems like Facebook integration) related to fraudulent relying parties -- that is step 3 where you are automatically redirected to the identity provider.

This provides an opportunity for a fraudulent relying party to instead redirect you to an imposter site where your password can be captured.

Similar with Facebook -- ever see a site with a Facebook link where you can sign in "via Facebook" -- it would be very easy for the site to instead pop up an imposter site that looks like Facebook login.

The email example does not have this vulnerability because in step 3 you aren't redirected but instead access you email directly.

This is an area where technologies like identity selectors (such as CardSpace) can help provide verification. The CardSpace interface is a lot harder to impersonate, either at the relying party level or if used by the identity provider.

16 Dec 2010

I actually proposed an idea similar to this in 2004: http://seclists.org/webappsec/2004/q4/291

The link is dead now; I'll try and find the original (but the responses are worth reading) but the idea is similar, the core concepts being:

1) The end user never needs to know the password, they just click "let me login" 2) This sends them an shortly-expiring login token that lets them log in once.

It make phishing a moot concept, for the given site, as the user now has nothing to give away. The "problem" most people saw was that it pushes the security "back" onto your email provider (i.e. your email service can't use this system).

The general consenus at the time was "Yeah, it's nice, but too similar to X and still has Y faults". Personally, I still think it is legitimate (I'll need to go back and find the article and re-publish it somewhere permanent).

I agree it's interesting to think about. I don't agree that a plug-in is the correct way to do it, but nevertheless, the underlying concept - in my clearly biased opinion - is good.