We are also very interest in the progression of OpenID. We are developing a implementation of strong,
multi-factor authentication for OpenID, which is currently in Beta:
TrustBearer OpenID.

We’ve been concentrating on simple user experience at this point, and we are interested to learn what sort of features user will look for in this type of implementation.

With our OpenID, you basically just set-up a strong authentication device and then link the device to your OpenID URL. Factors besides devices, are interesting to us, however.

It wouldn’t work in all situations but one way would be to redistribute a bookmark to known secure email address upon request by the user. It would require them to replace their old bookmark but it would prevent an attempt and someone hijacking that information and passing you on to the actual site.

Think I’m outside of the initial scope this was meant to address but if the bookmark was only provided by email I think it may add something for some.

Long time no-see by the way!

I’ve been meaning to write about this all week, but kept forgetting. Ben Adida has proposed a two-factor authentication scheme using a bookmarklet which looks pretty cool. Ben calls this a “bookmark,” but I prefer “bookmarklet” since it’s a……

- Richard: I like BATkey! Or BATlogin, because Authentication Token Key is a bit much. But that’s a great acronym, I think I’ll try it out on a few people.

- Ed: in the case of OpenID and other single sign-on providers, email isn’t ever part of the phishing problem. You go to a site, e.g. a blog, you click “login using my OpenID”, you enter your OpenID URL, and the web site sends you to your OpenID provider to log you in. So yes, in the classic email-based phishing scenario, email clients can do a lot to protect users. In the single sign-on case, email isn’t part of the loop. Regarding other browser-based solutions: yes, many approaches might work. I was looking for something without browser modifications.

- Christopher: you make an important point. There cannot be a backup login system that is single-factor. If you lose the bookmark, it can be sent back to you via a different channel, like email. But you can never log in with your password alone, otherwise the entire scheme is shot.

>Alice was expecting to log in to a specific web site (which is now lost)

It doesn’t need to be lost 99% of the time. When the user first hits the site with it in the URL and you show them a page that says please use your bookmark, if they have cookies enabled and you can do session tracking, start the session when they first hit the page add the URL parameter to the session and retrieve it after they use their bookmark to log in. Not pretty but more usable.

What are you going to do if they loose their bookmarks, or are traveling and don’t have them? What will be the “back up” login be? How will you secure it so phishers don’t just use that method instead. ie the phisher puts a page to the user which says, sorry we are having problems right now, please enter your username, password, and additional info to authenticate (The info required if you loose your bookmark.) I guess I don’t have a clear understanding of how guable users are. Would they just believe your system was having problems and enter the additional info?

Also, aren’t there other ways to solve this that would work 99% of the time? So maybe a browser could, before hitting any site that wasn’t typed in by a user, check online and see if the site existed a month ago. Or maybe it would see if anything on that site was in my cache first (as my real bank site would have entries there). These would require browser changes, though.

Lastly, what about what Brookline Bank just did to me? It forces me to “register” my IP to use their site now. So if I hit it from somewhere else, I must re-register that by them sending a passcode to my email address. In this case, if I got phished, someone couldn’t access my site even with my credentials.