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.