Good points but I beg to differ. - For internet-facing systems, your threat model should acknowledge that the user database is going to leak. It happens all th

Good points but I beg to differ. - For internet-facing systems, your threat model should acknowledge that the user database is going to leak. It happens all the time, even though many businesses don’t admit it. (You can tell how rampant the problem is: use unique email addresses per service, wait a year or two, and check how much spam you get on those addresses.) - Encryption is irrelevant when your threat model involves a leaked user database. That’s because if a service keeps passwords encrypted at rest, decryption keys may be available to the system at runtime. So you can assume that the decryption key is going to ship along with the leak. - Hashing passwords, if done properly, will buy you some time against an offline brute-forcer. But not if the space of possible passwords is as tiny as in the Kaspersky case. So hashing isn’t going to help much here as well. In other words, if a database of Kaspersky-generated passwords is ever leaked, consider them easily brute-forced, no matter what. - Even if logon attempts are limited and the database never leaks, the password is still at risk. The attacker may learn the time where the victim’s account was created, guess the timestamp in seconds, apply the Kaspersky algorithm and get the password right in four or five attempts if they’re lucky.