I'm using [SuperGenPass] for exactly same thing. I forked the project on Github so I'm sure that algorithm won't be changed.
[SuperGenPass]: https://chriszarate.github.io/supergenpass/
[SuperGenPass]: https://chriszarate.github.io/supergenpass/
Other 'problem' is that it uses a fast hash function. There was a fork going round that used bcrypt I think, I'm not sure what happened to that.
I also use salted master password for each site, so I'm feeling safe at this.
Regarding "quick hash" or "slow bcrypt" - it doesn't matter here. Bcrypt complexity is to prevent obtaining real password from it's hash. Here we're dealing with real passwords but not hashes.
It does matter. If a website knows that you use SuperGenPass, they can conceivably guess your master password if it's weak as a direct result of SuperGenPass using a fast hash function to generate the site-specific password.
In a scheme like this, the "real password" is the output of a hash function (albeit munged a little bit), so choice of hash function is important. I'm not a cryptographer, but really a key-derivation function seems like it would be a lot more appropriate here than a simple hash like MD5.
Exactly. The threat here is that a single SuperGenPass-generated site-specific is leaked somehow (if you use it for a lot of sites, one of them is bound to be storing a password in plaintext, or not using https, or whatever–or, for all I know, the OP is such an important target maybe someone specifically sets up a website to capture a sample site-specific password). Then, using that site-specific password, a determined attacker might be able to recover your master password and then be able to login to all the other websites you use SuperGenPass with. That's the danger of using a 'fast' hash function to generate your site-specific password.