Update 2 (2014-08-02): The developer of SuperGenPass, Chris Zarate, sent me an email detailing the solutions for the vulnerability described below explaining how the master password is never exposed to the master web page no more. I have not taken the time to review the solution, but the idea seems legit and the attack described below does no longer work.
Update: SuperGenPass vulnerability demo for people who don’t believe me.
I know, I have recommended that you use SuperGenPass for several times. It took a long time, but I finally realized there is a serious security flaw in the root of the implementation.
The SuperGenPass UI is rendered within the DOM of the current page when you click the bookmarklet. The UI is where you enter your master password. And because the UI is part of the current page, any script running in the page can read your master password. Remember that script can be external too, as in advertisements or widgets of some kind.
It is safe to say that using SuperGenPass is not that different from using the same password for every site. It just has a little bit different issues.
If you use the same password everywhere: When a site gets compromised in a way that the attacker can read the user account information, your account in every site can be compromised – depending on how the site stores their passwords.
If you use SuperGenPass on a site that is compromised: Your master password can get stolen and thus, your account in every site is compromised.
The difference is in the way site gets compromised. Something as common as a cross-site scripting attack will get your master password in jeopardy.
Fortunately, there is a safe way to use SuperGenPass. Just visit a page you absolutely trust not to have any unauthorized script running. Generate your password within that page by manually entering the domain name that you are trying to log in to. Then copy & paste it into the login form. Cumbersome, but it works.
At this point, I would not recommend SGP to anyone but security experts.
And if you are on a different computer than your own, make sure to empty the clipboard after pasting your password.
Or you can continue to use SuperGenpass, and generate your password using the mobile version, which runs on the local machine.
Does the addition of salt / “stealth password” in the new versions solve this problem?
You say that your master password can be stolen by a rogue site. Is that really true? Can you prove that with a demo?
Sure: SuperGenPass vulnerability demo.
Yeah, you are right. If a website owner wants to have the master password it is possible. The only really safe, practicable and somewhat luxury solution would be OpenID or SSO (something like Yubikey). But unfortunately not every website supports that… :(
But thanks for you comment on my blog!
Bye Jochen
I did not write that comment.
This demo don’t works on my Opera 10! Tried SuperGenPass as bookmarklet and also as custom button…
Some older versions similar to SuperGenPass use a popup box to ask for master password, are they also affected? How could a malicious script possibly intercept what you write in the popup box?
I don’t know what you specifically mean by a popup box, but whatever you do, the value you input must be taken into a variable of some kind and thus probably can be read by a script running on the page.
Hi Aki
I meant a popup window / inputbox, as in GenPass classic: http://supergenpass.com/genpass/ or the original Password Generator by Nic Wolff: http://angel.net/~nic/passwdlet.sha1.1a.html
Yes, the naked password will eventually get into a variable. But can’t you make that variable private in the javascript class?
I suppose that’s possible. I have no idea if the classic GenPass is actually built that way.
By the way, I made a draft of a simple Jetpack (a Firefox extension) feature that encapsulates SuperGenPass safely(?). I mentioned it here and am still waiting for some feedback:
http://groups.google.com/group/supergenpass/browse_thread/thread/c6193084045f4376?pli=1
@Aki: Sandboxing as an extension, with Jetpack, is wonderful idea that I heartily support.
You wrote a comment on my blog awhile back and I e-mailed you, but I didn’t hear back. I had no idea my blog was coming up on the first page of Google’s results for “SuperGenPass.” Because of this, I want to be very clear. If my blog post is misleading, then I’d like to correct it. If you enter your master password in the field on the site and THEN click the button, does that change this vulnerability at all? I never click it first and enter my master password like you have it on your demo.
I did not write that comment. I did not receive any email either.
No, it does not change the vulnerability. Your master password can be read from the password input field just as easily. Test it yourself on an another demo page.
Well if you didn’t write the comment then that obviously explains why you didn’t get the e-mail. I sent it to whoever did leave the comment. Anyway, let me ask you this – a more practical approach. Your demo was able to show my master password as I typed it in, sure. But, even if I didn’t use SuperGenpass and a script like yours was being used, wouldn’t they know my password anyway then? Regardless of if I was using SGP or not? Also, I’m sure you could make this work, but your site showed my master password, but after I clicked SuperGenPass, it did not update to show the new, generated password. How would a site using this script know we were using SuperGenPass in the first place? Couldn’t they steal your password, regardless of what it is, after it’s entered, with or without SGP?
It is trivial to detect if you are using SGP, but that is not the point. Yes, they could steal any password. The problem is that SGP is promoted to enhance security by providing unique passwords but in fact is not any better than just using the same password on every site. Unique passwords are good because if your password gets stolen other sites you are registered on are not in jeopardy. The whole point in using SGP is lost if your master password can get stolen on any of the sites you use.
I spoke with the developer and here’s what he told me:
“I am aware. I spoke with the original (academic and benign) discovers
of this technique some time ago. The DOM exploitation is fairly easily
circumvented, but the crux of the issue is that JavaScript is
extremely permissive when it comes to redeclaring built-in functions
and object calls. It is impossible to completely circumvent this kind
of attack.
I’m working on an update to SGP to make it extremely difficult to
carry out (randomization) and I’m working on something to add to the
FAQ, but my basic response is this:
1. This attack would need to be implemented on a site you somewhat
trust (i.e., a site you have an account with).
2. SGP has an quite small user base and the attack probably wouldn’t
be worth the effort.
3. If in doubt, use the mobile version.”
Just FYI!
Now I can confirm your 2 demos does work!! :(
And using the SGP mobile version isn’t enough if the site can read the typed password… :(
I tried the demo with the master password hardcoded in and it didn’t work. It also doesn’t read the password in the regenerate password field
Sorry about the repost, but I was wondering if there is a way to detect the stealth password that you can put in as an advanced feature
It is just a demo, I am sure the master password can be read in those scenarios also.
I’m still not sure why you’ve retracted your recommendation. Obviously a unique password for all sites is desireable, but for many people it simply isn’t practical.
For all the reasons in Mike Boylan’s post, I would still recommend it over using a single passowrd for all sites. It’s also still better in cases like the recent theft of a huge list of username/passwords from hotmail. In cases like that they’re stealing the generated password, and not the masterpassword so your other accounts would still be safe.
My easy way to prevent this.
Just rename ‘gp2_master’ element in script. I’m not a Java Script programmer, but it should work.
How to:
1) Copy your SuperGenPass bookmark url (whole javascript) into any editor (notepad for example)
2) Replace each occurrence of ‘gp2_master’ for your own expression (for example ‘gp3_master’)
3) Save the script as a new bookmark in your browser.
4) Use it.
Boys from SuperGenPass could(should) generate a different names of elements for each bookmark to prevent this.
The Best
Vlada
@vkubalek: your advice is all right for the frist demo (https://akibjorklund.com/files/2009/10/supergenpass-vulnerability-demo.html) but not good for the second demo (https://akibjorklund.com/files/2009/10/supergenpass-vulnerability-demo-2.html).
The point is this: the demos write the content of a field. for this the demo script need to know the field name. if you replace fieldname gp2_master and password the demos are not working anymore.
(I’m not a java-script programmer, so please correct me!)
I’m running the SuperGenPass Chrome Session extension which seems to sandbox the master password in the extension’s object space — or something. Anyhow, your demos show the SGP randomized password, not the master password.
I hope that helps others.
That is why many of us use and LOVE No Script… so any malicious scripts while we logon to a website do NOT affect things like SuperGenPass
I have created a bookmarklet version of SuperGenPass that only stores your password in a modal pop-up. As the pop-up is modal, all JavaScript in the host page is stopped and thus it cannot read the master password. It is availiable here.
I think probably the best way to circumvent this is to use an iframe with a data: URL. I haven’t tested it, but I think that major browsers will see any access to this iframe as a XSS violation and forbid it, thus making the SuperGenPass form secure.
Hi!
I’ve found why your demos didn’t work on my Opera!
I’m using a little UserJS for ad-blocking from Thomas von Frommannshausen at http://www.miurasoft.de/opera/docInspector/blog/
As I’m not a java script programmer, I don’t know why it has this effect on your demos. Just a coincidence, maybe?
If you want to take a look to the file: http://files.myopera.com/YinYanger/files/adBlocking.js
I’ve tried the advanced version of the bookmarklet generator (http://supergenpass.com/customize/?advanced) which adds a “stealth” password as salt in the hash. The salted bookmarklet still shows the Master password in Aki’s demo pages but the stealth password and the added salt appear immune. Or have I missed something? Adding your own salt seems to address the point George was (indirectly) trying to make.
for whatever it’s worth: I cut and paste some text to the end of the master password as a form of salt … doesn’t help the hard-core keyboard users but might help others
correction: cut and paste with a mouse
@Andres Riofrio That doesn’t work in firefox 3.5.6
If I use the applet in a blank tab and then paste in the password, will it be secure?
Yes, it will.
If SGP was changed to open a HTML file in an Iframe saved on the computer containing the application, that portion of the DOM might be isolated from the suspect page. The bookmarklet could possibly pass the domain as a parameter to the HTML file. Would this work as sort of a “secure” version of SGP?
steve lewis: in order to open the page in an iframe, some DOM manipulation procedures need to be called. These procedures can be overwritten to steal your password by changing the ‘local’ page to one on a remote server. Even if it did work, the portion of the iframe isolated from the evil stuff on the page would be isolated from SGP.
Your demo doesn’t work with the latest version of SuperGenPass and Firefox 4.0b7pre.
Just a note to say that the use of a JavaScript filter like NoScript will prevent this kind of attack on untrusted websites. SuperGenPass, as a bookmarklet, is implicitly trusted while the malicious code is blocked. However, this protection is limited since tyour determination of which sites are “trusted” might be flawed.