<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">TL;DR; Kaspersky used time(0) as the seed for the PRNG used to create proposed passwords. So every copy creates the exact same password if run at the same time and predicting the passwords is utterly trivial.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><a href="https://donjon.ledger.com/kaspersky-password-manager/">Kaspersky Password Manager: All your passwords are belong to us | Donjon (ledger.com)</a><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The article takes us into a predictably hilarious tour of the code. Instead of doing it right (which would have been easy) they did it in the most complicated and wrong fashion imaginable.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Kaspersky is not a company I would trust to do anything ever since Kaspersky's son was kidnaped and released in very murky circumstances. Russia is a dictatorship run by a gang of mafia thugs that have murdered hundreds of people in the past few years. It is utterly ridiculous to trust any company headquartered in such a country or to expect a CEO to put the interests of his customers first when the KGB/FSB literally have a gun to his son's head.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But the same is unfortunately going to be true of Apple, Google and the rest. Sure, they are headquartered in a country where the Jan 6th insurrection failed. But they have many employees who are foreign nationals coming from countries with similar regimes. A favorite of the Chinese govt. is to hold healthcare for relatives of US based ex-pats hostage: Give us the keys or your mother doesn't get the chemo.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Any tech company has to think long and hard about the possibility that they are exposing their employees to this type of blackmail. Banks are very aware of it and impose separation of duties to protect. But that is only mitigating the risk, a much better approach is to eliminate the possibility of the compromise.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I would like to see browsers support an explicit password management interface so that users can easily install their own. This has the major befit for the provider of moving the 'steaming pile of liability' out of their cloud. Of course, they don't want to do this as the password management feature is one of the main things that keeps browsers sticky and deters customers from defecting to a different browser.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I am just taking a break from configuring the DNS for the reference service for the alpha release of the Mesh. The Mesh has a different approach to password management:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Passwords are bad, we want to replace them with public key auth as soon as possible.</div><div class="gmail_default" style="font-size:small">2) Passwords are the only technology that currently work across platforms and applications and fit the existing affordances</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Therefore:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Provision public key pairs onto every device connected to the user's personal mesh that can be used for strong, public key based authentication.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">2) Use the provisioned keys and threshold cryptography to allow connected devices to make use of passwords stored in a password vault service that controls the ability to decrypt but cannot decrypt by itself.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">3) Once users can rely on the password vault being available and usable on every device they might need to use, they can start using very strong passwords with work factors of 120 bits or more that would be infeasible otherwise.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">At this point, the code is relying on the cryptographic number generator provided on the platform (Windows, macOS, Linux) but always passes the output from that generator through a digest function so as to prevent dual-ec-rng type disclosure attacks. At some point, I plan to change that to using a MAC against a device specific secret key to minimize the degree of trust placed on the platform.</div><div class="gmail_default" style="font-size:small"><br></div></div></div>