Yubico Forum

This is my entry for the YubiKing 2009 contest.

It's basically an online password store with a twist, it's designed with the YubiKey's principles right from the start. My goal with this was to enable the usage of the YubiKey in OTP mode on any website, not only those that are YubiKey aware.

This is accomplished by installing a browser extension that adds an event listener to all password fields. The listener checks for an entered OTP, and if one is found (it matches any 44 char modhex) it does an asynchronous request to the server over SSL, with the OTP and the URL. If a password has been stored, this is returned and entered instead of the YubiKey OTP, and the form is submitted.

In effect, you get the same functionality as if the site had supported the YubiKey directly!

Check it out on the wiki, and the main page (check out the demonstration video).

And please vote for it if you find it useful!

Hello dain,

you've got a really nice concept here. You managed to add the usability of the Yubikey to practically anything. But this does not add any security out of the box, because the respective site does not know anything of Yubikeys and thus they cannot enforce OTPs to authenticate - so you could just use your normal password instead an OTP, right? And anyone else who wants to impersonate you can do the same, if I'm correct.
So it does not add any security per se - for that to work, one would have to use strong and random passwords for every site and store these hard-to-guess passwords in your database, just like you described in your FAQ. But under the line it's still a static password.

_________________
"Grant me the strength to accept the things that I cannot change,
the courage to change the things I can
and the wisdom to know the difference."

Yes, you are completely correct and make a very good point!

For this to add to your security requires that you select strong passwords, preferably different ones for each site. This is definitely something I will try to highlight more in my FAQ. The benefit to using KeyGenius is that while you are still limited to static passwords, you are now free to choose ridiculously long random strings, without having to memorize and re-type these again and again...
So while you could technically add the same level of security anyway, KeyGenius removes the (in my opinion) greatest obstacle for doing so.

Hi daim,

from my point of view the idea is great. I think only to store the password and not knowing the username is a good choice

There is an 'but' I can see: How to establish such a service as an unknown third party service provider.
Let me draw some examples and let me polarise deliberately.

If I have no focus on security I will not use this service because I do not have difficult or different passwords. I have my password(s) in my mind or written down somewhere. Why should I pay for a key and have to carry it with me all the time? And why only for online passwords? - To complicated for me.

If I am interested in security or secure storing of my passwords I will ask some questions, e.g.
- How liable are you as a service provider?
- How stable is your service?
- How secure is your backend service/infrastructure?
- What could happen if you loose my pairs of url and password?
- What about the risk if your service crashes or ends?

So I personaly would decide to use a standalone password store which is open source software and portable. I would be the responsible for backups or recovery possibilities and so on.

If this online password store would be optionally a solution which would be open source and I could use for myself on my server I would be easier to estimate the risk. So the decision to use it would depends on my skills but would be transparent to me.


I am sure there are enough kinds of users between these two drastic examples. I hope this could clarify my thoughts about the 'but...' I see.


Please do not misunderstand me, the idea is great and it is only my personal point of view.


Cheers,
Jens

Yes, I do see this particular problem. On the one hand, you're doing all this stuff (acquiring a YubiKey, setting long complex passwords) for security, and then in the end you're trusting a completely unknown party with your credentials. It kind of defeats the purpose. I am quite open to creating an open backend that anyone could host for themselves, but for the moment I wanted to focus on making the service available, even if it ends up only serving as a concept. And as a concept I'm thrilled that you guys like it, so I guess the next step for me will be cleaning up some of the code and releasing an open source backend with a nice API or something.

Thanks for the feedback, keep it coming!

I think this way could be a good choice. I could imagine a company which will not trust a third party but has the ability to build up their own internal system. So you have your system in place inside of a "trusted environment", have security focussed stuff or company based policies for the users. In other words you have the flexibility and security of your great idea and the liability of the service provider.
I think there would be a really good chance to bring it in place.

BTW: I am interested in the acceptance of your free service, hope you have the possibility for anonymous usage statistics.
And as an idea for your public service. Integrate some rules for filtering dead passes. With my experiences I can say there will be more than a handfull of users which will test the service and 'forget' their passes in your system.

Cheers,
Jens

This seems very much like the existing system that is in operation by MashedLife.com in which they store your passwords which you then access by means of a Yubikey. Is there an essential difference that I'm missing?

Dick

MashedLife and KeyGenius are similar in the sense that they both serve to store your various passwords in a central location so that you may access them from anywhere. Let me just make it clear that I'm not trying to bash MashedLife in any way, I'll just try to highlight the differences. Also, I have not really used MashedLife, so I apologize if I get anything wrong.

MashedLife started out without support for the YubiKey, making the focus of their service a single location for you to use for all your sites.
For instance, you start your browsing by logging in to MashedLife. Then, from there, you can access your other sites. They have added the YubiKey as an optional authentication device.

KeyGenius was designed from the start to allow you to access your sites directly, making the service invisible to the user.
The user experience, once set up, is identical to if the sites themselves supported the YubiKey.
To use MashedLife, you create a MashedLife account. You enter all your login credentials, such as username and password, for your sites. Then, you can select a site, and MashedLife logs you into that site.
To use KeyGenius, you just store a password-domain mapping under a particular YubiKey. Then you log in to any site as usual, replacing the password with a YubiKey OTP.

To summarize, MashedLife stores all your logins under a new, single account.
KeyGenius adds a layer on top of your existing logins, giving them YubiKey functionality.
Which of these approaches is better is really just a matter of preference.

Hope this makes it clear for you!

I really like your approach. I tried out mashed life but I think your solution is better. It's very clever idea to hook into password field and bring "secret" to that field only when needed -- Without even knowing username on your side.

Please look at the idea http://wiki.yubico.com/wiki/index.php/Applications:DRM. On that there is a need for "metadata store" that is authorized by yubikey (both read and write). That kind of metadata store could be implemented to extend current yubikey-server-j implementation. There could be some extensions for "meta data storing". On a run environment you could select in which mode server would run:

1) local (all key AES-secrets are stored locally = company's "own validation" server)
2) proxy (all queries are sent to yubico but this local server adds meta data storage layer setting/getting meta data for keys)
3) mixed (if key is found in a local database, query is not forwarded. If it's not found, query is forwared to Yubico). Still meta data layer is added

It believe like this kind of approach would provide backend to your KeyGenius also, what do you think?

Could you make this even more fluent? Idea would be:

1) browser script notices OTP on a password field (current implementation)
2) script uses https to query if there is password stored for that doman (current implementation)
3) New functionality: If there is no password stored, your script would popup new windows asking if you would like to store a password. You would ask same question you do now on your site and when you press OK, it sends that to your site and returns password to password field that activated script originally