Yubico Forum

Great idea!
So you could add a new site's password without leaving the login-page. This would make the service more efficient and useful.

Thanks for the response regarding MashedLife. I like the simplicity of using your method and am going to give it a try.

I, too, like iipee's suggested feature.

Dick

Was just looking through your js code.

I have found two things to think about:
You are using document.location to identify the url of the login-page. AFAIK it would be slightly better to use window.location. Document.location seems to be depricated. You can have a look at http://javascript.royh.cn/document/location.html.
The disadvantage of window.location it the following: It is not only readable - it is writable. So it could be altered by clientside malicious code.
This brings me to the second point. I have read an article about bookmarklets and password managers. The conclusion was not to use the 'location' determined by javascript. It would be better to use the 'referrer header' in combination with an ssl secured transmission of the data. 5 of six commercial service provider changed their methods because of this.
Here is the link: http://www.technologyreview.com/computing/21907/?a=f , it's worth reading.

Cheers,
Jens

..and just one option more: That "first use" -window could have also "Generate Strong Password"-option (even query GRC strong password page for this?). The idea would be that when you go to the new site, you open "Create account" page. When they ask password, you would use Yubikey. New window (keyGenius script) is popped up and you press "Generate Strong Password". You either store it manually to your own local password storage (copy/paste) or leave it just to KeyGenius store (if it's not so important site, I just might do that). When popup is closed, you go to next field that asks to retype password. Just press Yubikey cause it's already stored!

Thanks for your comments and suggestions!

Regarding the window.location vs. document.location, I was unaware of this, and I have updated my code to use window.location. The problem with using the "Referer" HTTP header is that it is optional, so there is no guarantee that it will be included. More importantly, in my tests I've found that GreaseMonkey doesn't send the header when using the built in GM_xmlhttpRequest method. In the backed I do actually check for this header, and if found, it is used over the URL GET-parameter. However, this isn't really an issue, since if the site you're logging in to has been compromised to the point that a malicious user is able to inject his/her own JavaScript, then it would be possible to access your password from the page once it has been entered by KeyGenius (more likely it would target anyone by grabbing whatever is submitted, which has to be the password).

The "first use" window is something that I have on my todo-list. I need a better mechanism for triggering the window though, since I still need to allow existing YubiKey aware fields to function. This is the reason the form is submitted as it is now if a matching password isn't found on the server. Also, the key isn't verified unless a stored password is found, as to not invalidate the token if KeyGenius isn't the intended recipient. Thus, if you enter an OTP into a "real" YubiKey field, everything still works as intended. Perhaps I'll add a Bookmarklet for storing passwords from the current page or something. To use KeyGenius to get a password for registering a site, you also need some mechanism of preventing automatic submission, since you often have to enter a password twice on the same page. Well it's definitely doable, so I'll look it to it some more!

Lastly, I really like the idea of a "general purpose" datastore for the YubiKey. A nice API allowing you to store and retrieve arbitrary blobs. Perhaps some functionality to administer access to others as well. Maybe I'll throw something like this together if I feel like I all of a sudden have a lot of spare time


EDIT: A simple way to prevent automatic form submission would be to allow an optional prefix, for example, entering a "-" and then pressing the YubiKey could cause KeyGenius to fetch the password and populate the field, but not submit the form. On that note, prefixing the OTP with a "+" could cause KeyGenius to open the "store new password" window. Any thoughts on this?

I read (at least between the lines) you were already asked how you could implement your own "local" KeyGenius storage. It would mean you would need full OTP validation server locally. That is the reason I thought it would minimize the work by implementing datastore as an option to current validation server implementation. I believe it would be easy for you to implement KeyGenius on top of that architecture. And possibility to run it in "proxy" or "mixed" mode would give possibilities to provide "intranet services" where your own staff is authorized from local store and consultants can still use their own Yubikeys. Still having all meta data stored on local server.

I'm interested taking part if this kind of development is seen useful...

PS. "+" and "-" prefixes sounds just great. "+" to add, "-" to go without submission... And last +++ --> This would get strong password from GRC and go with that without even opening popup

One more thing you also have to consider, is the fact that some sites actually set the max field length to something less than 44 characters, which would prevent the entire OTP from being entered, and thus being able to read/verify it. I have seen a few sites do that. Can't recall which ones off hand, but its something to keep in mind.

Caitsith, thanks for pointing that out, I hadn't thought of that! KeyGenius now removes the maxlength attribute from any password field.

What's more, I've implemented the prefix stuff, so you can store passwords from the site you wish to log in to. By entering a specific prefix before generating the OTP, KeyGenius acts as follows:

Prefix, function
none Queries the server for a stored password for the domain, if found the field contents is replaced and the form is submitted.
- Same as none, but does NOT submit the form.
+ Opens a dialog to store a custom password for the current domain. Once stored, the password field is populated with the new password but the form is NOT submitted.
= Removes the prefix and submits the form with the generated OTP, without querying the server.
+<1-99> Generates and stores a random alphanumeric password of given length for the current domain. Once stored, the password field is populated with the new generated password, but the form is NOT submitted. For example, "+20<OTP>" would generate a 20 character password.
+++ Alias for +16. The number 16 can be modified in the source of the UserScript by changing the "default_len" variable.

Personally, I think this makes KeyGenius much more useful, and it's a pretty nifty addition if I do say so myself
When registering for a new site, you could use +++ for the first password field, then to confirm the password, you use - (or just the OTP if you don't mind submitting the form). The = probably isn't needed, you could save yourself the roundtrip time of querying the KeyGenius server for a stored password if you want to log in to for example this forum.

The randomly generated passwords can contain a-z, A-Z and 0-9. For extra entropy, I'm throwing in the changing part of the OTP as added "randomness" to the seed function. Does anyone see any reason not to do this?

Let me know what you think of the changes!

Oh, and Iipee, I'm not entirely sure what you mean. I was thinking of basically generalizing the KeyGenius backend to allow storing pretty much any key -> value pair instead of url -> password, and throwing in some other stuff, like administering read/write access to other YubiKeys than just your own. I doubt I'll have enough spare time for a while to realize this, but if I do get to it I'd make a nice API for accessing the functionality and open source the project. I wasn't thinking of a local storage thing, this would be accessed through the web. If we're lucky, maybe even Yubico would run a server as to minimize the number of parties you have to trust.

Wow, you are really fast

Your modifications sounds very good. Unfortunately I am not able to test it.
Seems to be not working on my windows machine an Firefox2. Tried both the Plugin and the bookmarklet with the same result... I do not know what my mistake is but I am sure the error is in front of the pc.

Tried it on different sites, eg. sourceforge and my own wordpress - with or without prefixes. The only result I can get is a wrong login at the site I am testing on.
As prefixes I tried none, -,+,+++. Looking at KeyGenius there are no entries for my YK (and this is OK).

Could you give me a hint what am I missing?

Thanks,
Jens

PS: For security aspects: would it be useful to set a minimum passwort length (e.g. 6) by autogenerating an pw with the prefix '+' ?

//EDIT: Did you changed something on your website, now the content flows out of the visual box.

Doh! Seems I had forgotten to upload the new version of the plugin! This has been fixed now, please update it and try again.

JensK, looking at that screenshot, it seems the [download]-link at the bottom right of the demo video makes the video much wider than it should be, forcing the right content to appear below instead of next to. That link shouldn't be there. Could it be that you have some other plugin installed that adds the link? Perhaps something to save flash videos to your computer or something?

If you still have problems with the updated plugin, would it be possible for you to update to Firefox 3? I have tested both Greasemonkey and Bookmarklet versions on Firefox 3.

About the minimum length thing, I don't know if that's necessary, since when you autogenerate a password you specify the length yourself (either by entering the length directly, or using +++, which should be long enough), so if you do specify it to be really short, then hopefully you have a good reason for doing so.