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.
> 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.
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.
#2 - the password generation options are part of the input to the generation function for LessPass. Problem of course is that you have to either remember those or store them somewhere, at which point you might as well store the password database.
In principle you could add a post-generation step that takes a description of the site's particular brand of password limitation damnfoolery and munges the output to fit. Then this profile would need to be saved somewhere so the same step could be done at password filling time.
(Still less sensible than doing this once and encrypting the result.)
If there's any format regularity in the output, like it's in one of the PKCS message formats, that could be detected. Or if it's a fixed length that could give it away.
Webcam hack. Social engineering. Binoculars. All the things.
Just sweeping them up en masse and trying popular keys.
> If there's any format regularity in the output, like it's in one of the PKCS message formats, that could be detected.
After entering some junk data, and incrementing the counter field, /every/ generated password has started with one of [aeiouy], so there clearly is some regularity in the output, and I guess more if analysed in detail.
Same here, it seems like every password starts with one of these [aeiouy] characters. So it seems these passwords are not as safe as they seem. Brute force may not be necessary to break these passwords. Is there any alternative services out there that require no storage?
I suspect that if a hacker were focused on a person (say a person under investigation or a celebrity), they could simply use that as one of many strategies in compromising the password.
