ab
Aki Björklund

SuperGenPass is not that secure

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.

Comments (41)

Timo Laak wrote (#):

And if you are on a different computer than your own, make sure to empty the clipboard after pasting your password.

Joe wrote (#):

Or you can continue to use SuperGenpass, and generate your password using the mobile version, which runs on the local machine.

W wrote (#):

Does the addition of salt / “stealth password” in the new versions solve this problem?

Dan F. wrote (#):

You say that your master password can be stolen by a rogue site. Is that really true? Can you prove that with a demo?

Jochen wrote (#):

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

YinYanger wrote (#):

This demo don’t works on my Opera 10! Tried SuperGenPass as bookmarklet and also as custom button…

larsp wrote (#):

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?

Aki Björklund wrote (#):

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.

Aki Björklund wrote (#):

I suppose that’s possible. I have no idea if the classic GenPass is actually built that way.

W wrote (#):

@Aki: Sandboxing as an extension, with Jetpack, is wonderful idea that I heartily support.

Mike Boylan wrote (#):

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.

Aki Björklund wrote (#):

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.

Mike Boylan wrote (#):

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?

Aki Björklund wrote (#):

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.

Mike Boylan wrote (#):

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!

YinYanger wrote (#):

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… :(

Tim Anderson wrote (#):

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

Tim Anderson wrote (#):

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

Aki Björklund wrote (#):

It is just a demo, I am sure the master password can be read in those scenarios also.

Ben wrote (#):

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.

vkubalek wrote (#):

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

George wrote (#):

@vkubalek: your advice is all right for the frist demo (http://akibjorklund.com/files/2009/10/supergenpass-vulnerability-demo.html) but not good for the second demo (http://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!)

Andy Kaplan-Myrth wrote (#):

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.

Michael Gough wrote (#):

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

Tim Anderson wrote (#):

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.

Andres Riofrio wrote (#):

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.

Martin wrote (#):

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.

asaens wrote (#):

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

asaens wrote (#):

correction: cut and paste with a mouse

Tim Anderson wrote (#):

@Andres Riofrio That doesn’t work in firefox 3.5.6

c wrote (#):

If I use the applet in a blank tab and then paste in the password, will it be secure?

steve lewis wrote (#):

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?

Tim Anderson wrote (#):

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.

geeknik wrote (#):

Your demo doesn’t work with the latest version of SuperGenPass and Firefox 4.0b7pre.

Chris wrote (#):

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.

Trackbacks/pingbacks (5)

Open Sesame « mindBloggin wrote (#):

[…] password even though the javascript is run locally. You can read about that particular issue here A combination of supergenpass and lastpass is possibly the ideal solution. Run supergenpass on a […]