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.

48 Replies to “SuperGenPass is not that secure”

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

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

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

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

  5. 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

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

  7. 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?

  8. 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.

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

  10. 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.

  11. 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.

  12. 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?

  13. 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.

  14. 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!

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

  16. 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

  17. 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

  18. 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.

  19. 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

  20. @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!)

  21. 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

  22. 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.

  23. 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.

  24. 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.

  25. 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

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

  27. 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?

  28. 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.

  29. 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.

Comments are closed.