3 ms·

>All the passwords it created could be bruteforced in seconds Can somebody please correct me if I'm wrong, but to bruteforce a password attackers need offline

>All the passwords it created could be bruteforced in seconds Can somebody please correct me if I'm wrong, but to bruteforce a password attackers need offline access to the stored passwords data and I'm assuming it mustn't be stored in a proper encrypted way why should the onus be on the end client/ user to use 'crazy' lenght and complex passwords(I'm excluding stupidily simple passwords such as 123456 etc..) surely a well design vault/ safe for the passwords and a restricted client logon system would stop all/ most attackers

wereHamster 5y ago
The seed to the PRNG was the current time (in seconds). There are ~31556952 seconds in a year. That means there are at most that many passwords generated by all users of KPM in any given year (assuming same charset was used). That makes it trivial (both in computation and time) to generate a table with all the passwords generated over the whole lifetime of KPM.
simias 5y ago
I think the attack vector would be something like: - Website is compromised, database is dumped - It contains hashed user passwords that you'd have to bruteforce if you want to recover them - If you know roughly how long the password is and when it was generated (and what character set it uses) and that you know that it was probably generated by this Karspersky product, you can use that to generate all possible combinations and speed up the bruteforcing considerably. It definitely hinges on a very specific set of circumstances and wouldn't be trivial to exploit, but it's still a pretty silly and easily avoided flaw for a password generator to have.
- Anunayj 5y ago
  Another would be sharing a encrypted file using password-based key derivation scheme over a unsecure channel. This could mean even if you use a client side password encrypted (Think Matrix, Bitwarden) with a supposedly "strong" password. The password is much much much much less secure. One thing though with the database dump scenario is, password managers by design discourage password reuse, so bruteforcing a password in a past leak might not help with the current passwords. Which imo makes using a password manager (albiet a bad one) still a net positive.
- stef25 5y ago
  This creates the weird scenario where using the Kaspersky product to create unique passwords + a leaked database would be super bad because the created_at value of the profile would give you a good indication of when the password was generated (in my case usually less than 60 sec before)
Hackbraten 5y ago
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.
- yosito 5y ago
  > wait a year or two, and check how much spam you get on those addresses Anecdote: I've been using a catch all email address on my own domain for about six months, and signed up for hundreds of services. So far, excluding aggressive marketing emails from the services I signed up for, I've gotten about five spam emails, and all of them were to random aliases on my domain that I've never used or shared like sales@yositosdomain but I am very curious to see how many spam emails I get to different aliases over time.

wereHamster 5y ago

The seed to the PRNG was the current time (in seconds). There are ~31556952 seconds in a year. That means there are at most that many passwords generated by all users of KPM in any given year (assuming same charset was used). That makes it trivial (both in computation and time) to generate a table with all the passwords generated over the whole lifetime of KPM.

simias 5y ago

I think the attack vector would be something like: - Website is compromised, database is dumped - It contains hashed user passwords that you'd have to bruteforce if you want to recover them - If you know roughly how long the password is and when it was generated (and what character set it uses) and that you know that it was probably generated by this Karspersky product, you can use that to generate all possible combinations and speed up the bruteforcing considerably. It definitely hinges on a very specific set of circumstances and wouldn't be trivial to exploit, but it's still a pretty silly and easily avoided flaw for a password generator to have.

Anunayj 5y ago
Another would be sharing a encrypted file using password-based key derivation scheme over a unsecure channel. This could mean even if you use a client side password encrypted (Think Matrix, Bitwarden) with a supposedly "strong" password. The password is much much much much less secure. One thing though with the database dump scenario is, password managers by design discourage password reuse, so bruteforcing a password in a past leak might not help with the current passwords. Which imo makes using a password manager (albiet a bad one) still a net positive.
stef25 5y ago
This creates the weird scenario where using the Kaspersky product to create unique passwords + a leaked database would be super bad because the created_at value of the profile would give you a good indication of when the password was generated (in my case usually less than 60 sec before)

Hackbraten 5y ago

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.

yosito 5y ago
> wait a year or two, and check how much spam you get on those addresses Anecdote: I've been using a catch all email address on my own domain for about six months, and signed up for hundreds of services. So far, excluding aggressive marketing emails from the services I signed up for, I've gotten about five spam emails, and all of them were to random aliases on my domain that I've never used or shared like sales@yositosdomain but I am very curious to see how many spam emails I get to different aliases over time.