User Centered

[Part 3]

Now, I’ve been harsh on the one-ring, OpenID, but in truth I’m very interested in “unified login”. Really I would like having less passwords and more transparent Internet access. I hate managing passwords (or in my case, like many, mismanaging).

So, what’s the answer?

Instead of a single ring, we need to build a strong chain. Luckily, much of what OpenID has provided could, theoretically be harnessed as I’m about to suggest. Since this article is directed toward the average user, I’m going to use an analogy before diving into my theoretical technical discussion.

Back to that real world scenario, a keycard that unlocks everything. Dangerous, right? Most people would see the inherent danger in having a single key for everything. Really, though, it isn’t the single key, it’s this question, “How do you know you can trust the keyhole?” – That is, if anyone could make a copy of your key very easily, you’d want to make sure you only stuck your key in trusted keyholes.

So, let’s take the danger of a “keyhole” copying your key out of the equation. How do we do that?

Make the keycard worthless until you verify it.

“Huh?” – Seriously, what if your keycard was completely worthless and disabled until you put it into, let’s just say for fun, your cell phone. Let’s say this make-believe cell phone has a simple program that accepts your username and password, verifies it against a central database and then unlocks your keycard.

Then your card would be active until you close the program on your phone or it’s shut off or whatever the software states. Not exactly as easy as just a card would be but way more secure because as soon as you pull it from your phone, the key is rendered useless. So long as you only enter your username and password into your trusted phone, your keycard can’t just be copied easily.

In other words, we cast the one-ring back into the fiery forge and instead build a chain, a strong one.

So, let’s translate this into the online world. What’s the online analogy to this magical cell phone or this stronger chain? Web Browsers.

They are the missing link.

As of now the OpenID system relies on only two parties to verify a safe connection: the user and the webpage. A user can be dupped, a webpage copied.

Any successful unified login system should rely on something more trustworthy and should eliminate the idea of putting a username and password into a web page. It should represent a fundamental shift in user behavior, to assist in providing more inherent security.

This is where a web browser could step in and provide a robust solution. It could maintain your authentication with your OpenID Provider.

You choose your OpenID Provider and whenever a website makes some sort of OpenID request the browser handles the transaction instead of a websites. When you enter your OpenID information, it always sends to the proper domain (your OpenID Provider). Then you train users to only ever enter that OpenID Username and password combination into a web browser when they click that “OpenID Login” button.

Imagine this flow:

Initial Login:
A user opens their preferred browser and begins surfing, they go to check their email and it simply shows the OpenID Logo and says “Use your web browser to log into your email account by clicking the OpenID button” – the browser pops up a native but very counterfeit resistant display. It sends that information to the trusted server, only. There’s no list’s for browsers to maintain here, just use the OpenID protocol (preferably using SSL).

The page reloads after the data submission and… voila!

Encountering a new site:
Now suppose you go to www.SomeNewWebsite.net and they want you to login but they have the OpenID mark. You don’t click anything on the webpage but instead click your OpenID button on the web browser. It pops up that counterfeit resistant display again and asks, “Do you wish to provide www.SomeNewWebsite.net access to your OpenID?”

The browser doesn’t keep track, it simply handles the transactions with the OpenID Provider in a context that makes it clear that it is “out of band” (that term from Mr. Slot).

A note on the “counterfeit resistant login display” – This is obviously an important component to making OpenID Login truly out of band. I would suggest something that dims the entire browser interface and shows only username and password inputs. Better: temporarily minimize the whole window, showing a background you can recognize (your desktop). Whatever it is, some behavior a website can’t duplicate with internal coding.

Obviously, there are still potential pitfalls, a user might accidently download a virus that corrupts their web browser. Browsers might try to become OpenID providers themselves (yuck). Different implementations of a counterfeit resistant login display might be confusing or impractical, or worse, they might be easily mimicked by clever website coding. These are relatively small technical challenges in comparison to the major advantage over the current OpenID implementation: Security and usability.

The other challenge I conveniently skip over is how to have browsers submit OpenID Identifier (very loosely translated: username) to a website displaying the OpenID Logo. I would propose a method whereby hidden input fields are standardized for use in OpenID. Browser developers, however, would probably be best at determining how to handle this.

The advantage of this system, though, is compelling: A unified login system with a forced behavioral change to provide heightened security against relatively easy phishing attacks.

I can explain to someone or anyone (grandma or brother), “Never, ever, ever enter your OpenID username and password into a website. Never do it. Ever.” – That is a rule that is simple. “Only enter it into your browser.” A browser then can set a default OpenID timeout when it automatically logs out. It can clear your OpenID data when you close it. It can prompt you later. You can set your own user preferences.

In other words this is a very simple workflow path that allows users one proper method and if they use the same browser, a similar behavior that will become habitual. Anything else, they can say, “that stinks”.

Now, that is an OpenID protocol I could get onboard with. Assuming you could get Internet Explorer, Safari, Firefox, Android, our dearly beloved Opera, and all the rest to implement a standard.
Comments?

Yum

WillYum is a Internet aficionado and all around security junkie since 1995. This is an overview article on a difficult technical problem presenting one possible solution.