Yubico Forum

OK, my mistake...
The download link was integrated because of the default plugin form greasemonkey.

Now it works. I will have a deeper look inside the next days.
To ideas to improve your service:
Actually you compare the domain for choosing the depending password. There are cases with more than one login forms under a domain. In this case only the last saved pw is stored. By using more than the domain-name this could be improved. You could use e.g. the complete uri or the length of the script path if you want to keep it anonymously.
By showing the stored passwords there is a flicker-effect if the password is shorter than the asterisks and your pointer is not directly over the pw.

As I wrote I will test furthermore the next days.

Thumbs up,
Jens

I love the changes. You've got my vote already

It would be really cool if you would create that kind of data storage service (you already have that partly implemented, it would need just API to use it in a more generic way, like you said).
I guess my idea was just few steps ahead. When you implement that next thing "we" ask is "hey, I need to store my data locally inside our corporate network". Then it needs backend code to be opensource. Yesterday I wrote it could be functionality of authentication server. Today I believe it should be separate "proxying" server that does only data store/retrieval. It would still be possible to install also authentication server locally.

I'm been testing this out. It is awesome. Really Killer-app I've been waiting for!

Few ideas:
1) possibility to register backup keys to backend (they share same passwords: Could also been used in family to share photo galleries, family calendar etc.) I know you have to consider how to do this safely. Maybe ask for revoke code. So revoke code is actually "secret id for group of keys". With that code you could revoke passwords or add new keys.

2) If I have used "remember password", field may already have password in field. If my password is "123XYZ222", result ends to be forexmple "123XYZ222jaaddeebgthilrtguutlcghuijclbecrlrunrtfdgfn". If you change your algorithm to see that last 44 chars are modhex and send only those --> it would still work

3) When I was demoing "+"-option, it noticed that it would be nice if password entry popup would hide password. Maybe just asking it twice like usually this is handled?

I will do more testing both in XP and MacOS and check if I can get it working with NoScript installed.
Here is some test results:
- OS: MacOS, Browser: MineField (daily build of Firefox), NoScript: On -- Works just fine
- OS: XP, Browser: Firefox -- Works just fine

KeyGenius works in most of sites I tried. I find two kind of problems on few of them:
1) Automatic post didn't occur -- I had to press Login
2) After registering password ("+" followed by OTP) password field was filled with password I gave in popup -- Site says "Wrong password". When entering same password manually I can logon into site (tried several times, can't be typo)

List of sites that has one of those problems:
http://www.geocaching.com (problem 1)
http://www.helsinkilainen.com (problem 2)

Hey guys,

I just updated the script, mostly compatibility fixes. The current version has been tested in Bookmarklet form under Opera, IE8 (beta), Firefox 3 and Safari (windows), and under Greasemonkey in Firefox 3. iipee, hopefully this version fixes the problems you were having!

JensK, I've been trying to decide how to best do the checking of the url. On one hand, you might have different logins for different pages on the same domain. You might also have the same password for several pages on the same domain, which I think is more common. Also, it's common for pages to be available both using a www-prefix and not using it. The way I do things now is that I take the domain only (including any subdomains, except for www specifically) to determine which password to retrieve/store. Maybe I should switch this to also use the rest of the url, but I want to save the user from having to store the same password many times, for essentially the same login. Also, if I give the user more power over this, by adding for instance wildcards into the mix, then it's not as simple to use. It's difficult to balance ease of use and configurability...

iipee, thanks for the ideas.
1. This would be nice to have, I think it ties in with the "meta-data" store, having multi-user privileges, etc. This may come in a future version!
2. I'm not exactly sure what this would accomplish. If you use a "remember password" function, then you don't need the YubiKey at all, correct? Wouldn't it be pointless to then input your token? Maybe I'm missing something.
3. The reason it is like it is now, is that JavaScript provides the prompt for asking the user for a password. I could replace this with a regular form, but it makes the script much more advanced, because I then have to inject a bunch of html and add more listeners, etc. Maybe I'll do this later, but right now it's not a big priority.

Again, thanks for trying out KeyGenius and helping me improve it!

It didn't fix them:
http://www.geocaching.com (problem 1: still doesn't auto-post)
http://www.helsinkilainen.com (problem 2: retrieved password is said to be wrong. Tried several times).
Helsinkilainen is just basic Horde-mail service. Maybe somebody else can test some other Horde-based service? Dain, that one is free email service, maybe you could create one dummy account there?


Sound's like a right way to do it.


This has something to do with "ease of use" for non-technical user. I myself can clear my browsers saved passwords, but I can think some "end-user" testing KeyGenius and saved password causes it to fail...



Yep, I like simplicity of your script and if there isn't a way to ask password this is fine.
Maybe you wait and see how popular this get's and make that form later
If you create that form, here is suggestion what kind of functionality there could be:

_______________________________________________________
Password (*********)
Retype Password ( )

Share this password with your other keys
Backup key (X)
Ann ( )
Mike ( )

You have not set your Revocation code or created a backup key.
You can do it _here_.

You can order new keys _here_
_______________________________________________________

Iipee, regarding problem 2. The problem is that the page has it's own javascript in place which adds an event listener to capture the enter keystroke and submit the form. This causes both event listeners to be executed, so while KeyGenius is is requesting your password from the KeyGenius server, the form is submitted containing your OTP before the reponse is able to come back. I'm not entirely sure about how to fix this, I'd rather not attempt to cancel out any other javascript that may interfere with my own. One workaround that I found, though, it using the NoScript plugin for Firefox. It disables the page javascript, but allows Greasemonkey.

On the Geocaching page I wasn't able to reproduce the problem. It autosubmitted just fine when I tried it, though I haven't actually created an account, I just stored a password for the site anyway and tried logging in with it. The point is, it submitted autmatically both with NoScript activated and disabled. Strange...

Just as an idea:
The default-length for the generated PW (16) is customisable. What about an option to keep the check against domain-name or url changeable in the backend to?
Now this is not useful. In case you want to give the possiblilty to build up own backend infrastructure this could be interesting eg for companies and their intranet based solutions in the same domain with different systems and logins.

At the moment you have to authenticate to list your passwords and again to delete one of them. After that you are redirected to the manage-index. To delete another pw you have to authenticate again twice. Would it be possible to be redirected back to the list of your passwords - after process of deleting?
I think the less on security would be acceptable and the handling will be better.

If you plan to do a localisation of your project in future I could support you to get the German version.

Cheers,
Jens

I've been giving a bit of thought to your project and really like what it does and, mostly, how it does it. The one thing that makes me (and possibly other potential users) a bit uneasy is that I have to turn over the URLs and passwords to someone that I don't know. This isn't meant certainly as a personal question of your integrity, of course, but a theoretical issue.

I understand that your system does not give you my username, but that is trivial to guess in many cases since an increasing number of sites are merely using one's email address as the username and in other cases you could guess the username if you knew my name.

I was wondering if it might be possible to encrypt the password on the user's end so that what you stored was only the encrypted version which you had no ability to decrypt. It could be returned to the user, decrypted, and inserted into the form when needed. I realize this adds complexity, but I think the security might make it worthwhile. As I understand it, this was the original system used by Hushmail.com for storing email. They later developed a second simpler system which did the encryption on their end and made them able to decrypt stored email. Apparently it was this second system which led to problems when the government ordered them to provide information on users' emails.

If you only store encrypted passwords that you are unable to decrypt, you eliminate the potential problem of being faced with such an order (perhaps not a problem in your country, I don't know) and further provide more confidence in the use of your system to your users.

Regards,

Dick

I believe that some additional security aspects should be covered. I don't know if this hack or not but I was able to collect passwords -- Idea been that if you get access to the key that has been used with Keygenius, you are able to collect quickly passwords against every site where it's been used.

Hack goes like this
1) Go to page http://key-genius.appspot.com/manage.html and "List passwords" and press Yubikey

OH-NO! No hack is needed, you show passwords right away! When I last time tested it, you only showed domains, not passwords. I think this is way TOO DANGER now.
Why you have chosen to show passwords?

Anyway, I'll continue to describe my simple hack
2) Create local web service that returns page
<html><body><form name="form1" method=post action="form.html">
Password : <input type="password" id="pwd" name="pwd" value=""></form></body></html>

3) Edit hosts file to contain for example
"127.0.0.1 www.google.com"

4) Open that url --> Your own webservice on localhost provides page with only password field

5) Use OTP

6) KeyGenius collects password and does post

7) Grab password from post variable pwd

If you fix the first serious problem, how this other scenario could be avoided? If client side could get IP of server and get it delivered to the server, it could do reverse-DNS to check it. But I believe it would be hard to implement this hacker proofly.

JensK, the plugin always sends the whole URL, so taking just the domain is up to the backend, meaning I could change this easily at any point. My final goal is to do something smarter than what I'm doing now, so your suggestions are welcome! Unfortunately I don't know when I'll have time to implement them :/
Several aspects of the website in terms of usability should be improved, one of those is managing passwords. Thanks for offering to help with translations, I'll let you know if I get to the point of internationalizing it!

Dick, I completely understand the issue you have with supplying a third party with your passwords, I would have the same issue. I'll look in to encrypting/decrypting passwords locally with a password for a future version of KeyGenius as a potential optional addition. As it is now, I encrypt the passwords in the backend with several things, one being the id part of the YubiKey OTP, since it doesn't change. This is not stored anywhere either. I know that this doesn't exactly prove anything, since it's still a matter of trusting that I know what I'm doing, and that I'm not malicious. Also, I could very easily start storing this without the users knowing it.

Iipee, I've always shown the passwords on the list password site, though if you have JavaScript enabled, they are only in clear text if you hover over them with your cursor. The reason for this is that it really doesn't add any security not doing so. The whole idea with KeyGenius is that only you have access to your YubiKey, and if you were to lose it, you use the revocation code to destroy all stored data as soon as possible. If someone gets a hold of your YubiKey, then they can obviously use it to access your passwords, very easily. The simplest probably by going to the site they want the password for and using KeyGenius to populate the form but not submit it. Then they could just use any DOM inspection tool, Firebug for instance, to look at the contents of the input field. This is unavoidable, and is inherent in all password management programs and services. Even if you make sure the form submits automatically as soon as the password has been entered, and SSL is used, then if the hacker has control of the box, he could use some other plug-in to get the request data.

To summarize, don't give your YubiKey to anyone else but you!