| The GP's points are all a bit weak, especially if this method uses a good KDF like bcrypt to generate the keys. I used SuperGenPass for a while, before switching to KeePass, and the major drawbacks I found were: 1) No way to change a password. None at all. If a site required you to make up a new password, you're out of luck (or you have to come up with a new master password every time and remember which master password to use for which site). 2) If a website is incompatible with the generated password, you're out of luck. My bank (because of course it would be the bank, cat sharing websites are more secure) would throw a fit because I had a number in my password and refuse to set it. 3) If someone has a keylogger or otherwise steals your master password, you're done for everywhere. This is not so with password databases, because the attacker also needs the file. 4) It's just not really that much more convenient than KeePass + KeePassAndroid. Hell, the latter is more convenient because I don't have to keep retyping my password, I can store it in memory protected by my fingerprint, which is something that no SuperGenPass-compatible app I've found does. In summary: Go with KeePass, it's better. |
It's about equivalent though. If someone can keylog you, they can probably obtain the file. If that's through malware then they simply grab the file with the malware, if that's through a hardware keylogger then they just grab it off your machine when you're not around. Even if you used FDE, you're dead in the water because they logged your FDE password too.
Heck, if I were the malware author I'd inject into KeePass or similar and dump your decrypted database as soon as you login, immediately bypassing any anti-keylogger tools, keyboards, alternative authentication methods for your password manager, etc that you might have used.
It's important to think about realistic threat models with things like this. If you're keylogged you're already screwed unless you use your password database on a separate machine.