Kaspersky Password Manager: All your passwords are belong to us | Hacker News Reader

Kaspersky Password Manager: All your passwords are belong to us

donjon.ledger.com

263 pointssyck120 comments

> It means every instance of Kaspersky Password Manager in the world will generate the exact same password at a given second.

Whoa. That's just ... Wow.

I recall this was an issue too for certain RSA tokens.

"In the context of previous allegations about RSA and USA intelligence, there's some chance these errors were intentionally introduced."

https://en.wikipedia.org/wiki/RSA_Security#Relationship_with...

That was because some RSA tokens had identical seeds, it was only affecting some of the older time based tokens.

Precisely what I recall now -- the reason behind it I had forgotten. Thanks!

The real fun thing would be if we discovered that they deliberately added the 1+ second animation to hide the bug. :)

31536000 seconds in a year. Sounds crackable.

New in Russia, Kaspersky was used to be known as one of the places where the smartest, math-savvy developers went. So either they have completely changed in the last few years, or it was completely intentional.

Kaspersky is a former KGB officer

And, as everyone in the former USSR knows, there is no such thing as a former KGB officer

I feel like the discussion about uniform password generation and PRNG, while interesting, is relatively irrelevant here. Even a garbo xorshift-based non uniform PRNG is almost certainly good enough to generate strong random passwords, as long as it's seeded correctly. An attacker is unlikely to gather enough output (generated passwords) to predict other ones, and the passwords are unlikely to be all generated within the same session so the PRNG state probably wouldn't carry over anyway. It's shoddy craftsmanship for sure and it doesn't inspire confidence in the product, but I'm not sure that it could be meaningfully exploited on its own.

Seeding with the current time is the real sin here.

I think the issue is in both: seeding with time and using a generator that does not have an additional source of entropy (i.e. is fully deterministic given seed).

Bias simply weakens your password.

If you generate long elaborate passwords then they can resist some of these flaws but the point is you don't want to introduce a flaw when they are simpler and better solutions out there.

Mistakes are natural, you want to provide the utmost resistance to such exploits which can stack up to become viable.

What I've been wondering for a long time is how do these two passwords compare:

   hiKxChDiaHNAtgVz

vis-à-vis:

   kähdikyylkönekkimahdakerttaksa

One is a 16 random `[a-zA-Z0-9]` characters, the other is a 32 character long nonce word, containing <ä> and <ö> among others that conforms to Finnish phonology, but otherwise is devoid of any meaning and phonology but easier to remember to speakers of Finnish. One is a 16.

Does 32 characters opposed to 16 offset that the latter conforms to the phonology of a language with 6 million speakers?

It can IMO. The right thing to do is to consider the entropy in a pessimistic attack context. Enough dictionary-attackable words together still has good entropy

The second password can fail quite quickly assuming an attacker is going to target Finnish words to perform a dictionary attack, perhaps a Finnish website makes sense for something like this to be done.

Psuedo-random is always better because anything else usually follows a pattern that can be exploited(sequence, structure, words, statistical bias)

If we can't make assumptions about the secret, the only solution is plain brute-force when it comes to the number of characters squared the length of the password.

As I said; it's not a word.

It isn't a word and has no actual meaning or morphology; it's comparable to something such as:

   wrockrangnattentamploozakoshal

It conforms to Finnish orthography and phonology, but otherwise not a word.

It seems to be though that it is consisted of some structured elements(I don't know much about Finnish orthography\honology)

So if it has some predictable structure, statistical attributes etc, it can be exploited to reduce the search space and therefore can be weaker than the actual raw entropy.

Does that matter in the real world? I don't think so.

Yes it can, so I wonder if the double length offsets that.

I would assume that assuming an attacker knows that it is nonce Finnish, that he would be able to craft a specific algorithm that is faster than 32 random character for specifically this, but that in practice if he not know that with all modern approaches it is æquivalent to attempting to bruteforce 32 characters, giving priority to letters and vowels, especially with the inclusion of <ä> and <ö>.

Again, it is hard to compare because I don't know enough about Finnish.

the first option is rather simple, assuming we have a good psuedo-random generator with low bias margins. we get:

A-Z,a-z,0-9 = 58 options, Length = 16

58^16/2 is the target.

Second option is weaker IMO because we know that plain brute-force is rarely being used today for anything over 13~14 characters.

We mostly use masks\dictionaries to try common passwords, phrases, sequences. So even if there's a very small chance that someone would have some kind of heuristic rule that targets Finnish orthography\honology, it is still more likely than someone successfully brute-forcing 16 random chars+numbers.

Another interesting observation is that fact that it contains common English words by chance. things like rock or tent. those can increase the chance of a dictionary success(our 32 chars starts breaking apart) whereas the 16 chars are random so in nature there are less prone to contain common English words

I wonder if the xkcd comic about this is still accurate, being that it's generally safer to have longer passwords regardless of how it's formatted.

https://xkcd.com/936/

I recently signed up for a ticketing website to buy tickets for a concert and was appalled that the site wouldn't accept my 50+ character generated password... I had to enter something between 8 and 15 characters.

Still seems to me that "^Zh7*2wNfRG7ehj" would still be inherently less secure than "thisisasuperlongpasswordandithas12345alotofcharactersinitthatwouldtake12345rainbowtablesalongtimetocalculatefor"

15 vs 111 characters to find permutations for.

That is, of course, even assuming that the password db for the site is even hashed (AND salted) or not.

> I wonder if the xkcd comic about this is still accurate, being that it's generally safer to have longer passwords regardless of how it's formatted.

Indeed, that is what I am wondering. If the double length offsets that it is not random.

Twice the length is quite a lot, but it's also not random any more.

The comic is still accurate and always will be. It's just a mathematical law, even though it uses a popular display of it.

What you are wondering about is the size of base of the exponentiation. Let's look into that.

If you use individual, unrelated letters, this is 26 (or 52 when you allow uppercase, or 62 if you also allow numbers). At e.g. 12 letter, this is 62 to the power of 12. At 16 letters, it is 62 to the 16.

If you use words (as the comic proposes), then the dictionary size will be the base (in this case, 4000 or so). You have fewer words, so entropy is 4000 to the 4.

If you use phonologically grouped words or syllables, the base size is their number. I'm not a linguist, but I'd guess it is somewhere around 100 or so. If a syllable is 2 to 3 letters long and you use 32 letters, you get something like 12 syllables. Entropy is 100 to the 12.

It depends on your threat model. The simplest analysis assumes that the attacker knows how you are generating your password.

There are 36^16 possible passwords with the first scheme. I don't know how you generated the second. One way of doing it would be to generate all valid Finnish syllables and select randomly from that. If the number of possible syllables raised to the power of the number of syllables in your password is greater than 36^16, then it's more secure.

Minor nitpick: there are 62^16 possibles passwords in the fist scheme (passwords are case-sensitive in almost every scenario).

I don't get why it's so hard to just seed with some random sensor data from your computer? Noise from a microphone input would be perfect, and a million times better than this.

> Seeding with the current time is the real sin here.

As somebody who only ever uses rng for games, and then indeed seeds with os.microtime(), what's the issue and what is a better approach?

There are only so many seconds in a year, and if you know the PRNG and assume reasonable constraints for the password generator (length, symbols, numbers) you can iterate this space orders of magnitude faster than brute-force.

The proper way to do this for cryptographic purposes is use the RNG facility provided by the kernel, which mixes in local entropy. Or go directly to the CPU like Intel’s RDRAND instruction. But the kernel should be using this if it’s enabled.

The main issue is you generally want PRNGs, especially in terms of crypto, to be unpredictable. When you use something like the time, you've suddenly made the output VERY predictable.

In terms of a global password manager, it's extremely bad, you now can use things like "member since x" to guess a password. If, for example, a database with credentials are leaked, you've significantly shorted the amount of passwords that need to be brute forced for a given target (assuming you know what password manager software they are using)

A good approach would have been something as simple as adding the master password into the seed. (Master password + time). An even better approach would be using a more cryptographically secure random number from the system for either the whole thing or at very least for the seed. (On linux systems /dev/random). You certainly could combine all those approaches to make the password much harder to guess.

Seeding with the time makes the outputs predictable to an adversary. If your games are not moving real money based on your RNG (like online poker), you probably don't have any adversaries trying to guess your random numbers, so you're fine.

See here for an online poker game which actually had this flaw: https://news.ycombinator.com/item?id=7207851

What's wrong with seeding with time so long as you do it with nanoseconds?

That's not the case here, and even then why bother when modern operating systems have ways to easily get you good quality entropy? If you use a decent random library you won't have to bother reinventing the wheel.

I had to generate a 20 char random key string in Rust the other day, I just wrote:

        rand::thread_rng()
            .sample_iter(&Alphanumeric)
            .take(20)
            .map(char::from)
            .collect()

There. Uniform, decent entropy, explicit, simple.

You likely can't get a safe amount of entropy from the available resolution in time.

For example, even assuming nanoseconds, that's only log(10^9) bits of entropy if you can guess what second (not that hard, may even be public). That's nowhere near enough.

I'd also doubt that many ways you try to get a nanosecond resolution time actually have that resolution, there's probably discrete steps of lower resolution.

Ok, we know that Math.random() is bad, and they recommend using window.crypto.getRandomValues(). But the docs for getRandomValues() raise concerns too:

- getRandomValues() is not guaranteed to be running in a secure context.

- There is no minimum degree of entropy mandated by the Web Cryptography specification

- User agents are instead urged to provide the best entropy they can when generating random numbers, using a well-defined, efficient pseudorandom number generator built into the user agent itself, but seeded with values taken from an external source of pseudorandom numbers, such as a platform-specific random number function, the Unix /dev/urandom device, or other source of random or pseudorandom data.

From https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getR...

Is there a better solution?

Being able to call getRandomValues from HTTP endpoints doesn't specifically break a password extension unless it was somehow serving over HTTP and had its Javascript modified.

It doesn't mandate entropy requirements, probably because that's a somewhat contentious measure that not all OSes provide information about (see also: the long and tedious arguments about merging /dev/random and /dev/urandom). As long as the browsers use the underlying OS primitives, it will be fine.

Browsers do a thousand things essential for security that are far harder than providing cryptographically random numbers, and I highly doubt they'll screw it up.

There is no better solution for the client-side web. getRandomValues() generates cryptographically secure random bytes in all current popular browsers.

Side question: what are cryptographically secure random bytes? I assume that with random bytes all we care about is that they are random. And since it's impossible to tell if any finite sized output is random or not, I suppose we simply show randomness with statistical significance tests. But how, precisely?

Passing statistical tests is the lowest, most basic, requirement for cryptographic RNGs.

Beyond that, you need to prove that no other party (i.e., the 'attacker') can predict the output any better than random chance, even if they've seen all the output leading up to it.

Beyond even that, many CSRNGs attempt to recover from 'state compromise': even if a snapshot of all the contents of the secret state get leaked somehow the system will soon return to producing secure output.

If you don't fully trust getRandomValues, you can collect entropy in JavaScript and then hash everything you got using something like Blake2b. Touch/mouse inputs time and positions can give a few bits of entropy for example.

I can't imagine a situation when you don't trust getRandomValues, but trust touch/mouse inputs. If your getRandomValues is untrusted, why would you trust the whole JS runtime that implements it? If you think there's a Debian-like bug with the system PRNG, then you can't even trust the TLS connection that downloaded your JS code.

I think it's possible that TLS is functional, but getRandomValues is hacked/broken. A popular browser extension sold or given away to a hacker could inject everywhere the following code for example:

window.crypto.getRandomValues = (arrayBufferView) => arrayBufferView.fill(4);

For sure using more entropy from JS will not do much in case of a targeted attack that did compromise the downloaded code or the runtime, but the scenario of a larger scale attack on WebCrypto is what I was thinking about.

If an extension can modify getRandomValues, then all your other code is also untrusted, you can't work around it by using other methods to generate randomness.

I know. But the likelyhoood of a targeted attack on my code is much lower.

This is one of those areas where security in depth is a good idea.

Gather all the sources of random sources you can and hash them together -- add in any information based on user input (key presses / mouse movements), and personally I'd provide each users with a securely generated random 1K string (which could be sent once at install) to provide more random data.

I like cloudflares solution for entropy. A webcam pointed at a wall of lavalamps in their HQ

https://www.cloudflare.com/learning/ssl/lava-lamp-encryption...

Cool, but why are they on public display? Sufficiently hard to hack as-is?

You said it yourself: "Cool"

getRandomValues() already takes input from keyboard and mouse interrupts (via the OS PRNG) and lots of other sources, no need to create own bug-ridden implementations of the same thing.

That's true for good implementarions, but is it true for all implementations? I don't know, but I'd be worried about it.

>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

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.

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.

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.

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)

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.

> 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.

Ledger is the company that kept for no good reason, and did not secure database of names, phone numbers and home addresses of their customers putting them at risk of robbery.

I’m on that list and I’m scared.

The STL did a bunch of work to move away from rand() to mt19937. Like deprecating std::random_shuffle in C++ 14.

But good to note that mt19937 is still not cryptographically secure.

Also there are always FSB agents sitting in Kaspersky office. Let that sink in.

In the context of previous allegations about Kaspersky and Russian intelligence, there's some chance these errors were intentionally introduced.

https://en.wikipedia.org/wiki/Kaspersky_bans_and_allegations...

> After a bit less than two years, this vulnerability has been patched on all versions of KPM. Vulnerability has been assigned CVE-2020-27020.

Pretty terrible bug to be unpatched and presumably uncommunicated for 2 years. Ouch.

get your dice keys. https://dicekeys.com/

Getting some DUAL_EC prng vibes.

Insert Kaspersky owned by Russia intelligence conspiracy here...

Kaspersky's Advanced School of KGB graduation photos:

https://cs6.pikabu.ru/post_img/big/2017/07/04/11/14991974131...

KGB school student and later KGB officer...sounds plausible.

BTW: that whole thing must be before 1991 (KGB) and kaspersky was founded in 1997 (where KGB wasn't anymore).

KGB was renamed and split into four agencies (FSB, SVR, FAPSI and FSK) that were later merged down back to FSB and SVR. There are still KGB people working there that didn't even have to move their offices.

The country is now ran by a clique of ex-KGB hardliners but I guess that does not count because it was renamed in 1991.

So it's not KGB anymore right? And not a KGB School right? And your Picture has nothing todo with kaspersky right?

I'm not sure what is your point here. There is an unbroken contiunity of CheKa/NKVD/MGB/KGB/FSB.

I'm not sure what you try to proof with your picture and kaspersky.

>There is an unbroken contiunity of CheKa/NKVD/MGB/KGB/FSB

Same could be said about OSS -> CIA right?

>Kaspersky's Advanced School of KGB graduation

Then this can't be an official Name right?

That was the official name at his time of graduation, and the school is still the Russian security service primary institution.

> I'm not sure what you try to proof with your picture and kaspersky.

Oh, only that his link to Russian secret services is not ephemeral. He is still a bloody state security reserve officer.

Now of course there is no way of proving if this vulnerability was planted or merely a poor implementation. However to think that Kaspersky Labs has no substantial embedding of FSB is incredibly naive, it's simply not how things work in Russia (even if the CEO isn't an FSB reservist).

It was when he was enrolled in it (1980) and when he graduated from it (1987).

That's how education worked back then. If you wanna study cryptography, you go The Technical Faculty of the KGB Higher School, now known as Institute of Cryptography, Telecommunications and Computer Science (FSB still runs it).

One could say it's even comparable to National Intelligence University: https://en.wikipedia.org/wiki/National_Intelligence_Universi...

> In June 2021, the University officially transferred from the Defense Department to the Office of the Director of National Intelligence to better serve the diverse and varied needs of its students and the United States intelligence enterprise.

Just to remind you all why it's not a coincidence and also not an argument for conspiracy.

The only organizations in the USSR who were hunting for best talent were KGB and military. So when the first businesses emerged and started hunting, almost all talent came from there.

Factually incorrect: only a small minority of talented people went working for KGB. It had many perks but wasn't a place where a serious talent would thrive.

Are there any data, if we talk factual?

Poke any notable Soviet science and technology figure and see if they have KGB in their biography.

Soviet R&D wasn't structured within end users but was own network of research institutes and design bureaus. So if you wanted to work say on solid state rockets you wouldn't go to artillery school but rather something like Central Scientific Research Institute of Heat and Mass Exchange. There you'd be working for tactical rocket stuffings for the rest of your life, have a certain academic career track and as a perk have an occasional international publication with peripheral results.

When you are starting working on real rockets, the KGB must give you clearance.

So I bet every one of the notable figures had some KGB in their biography.

Being investigated by KGB is so categorically different thing than being a KGB officer that I'm not even sure where to start.

But sure: Sergei Korolev, the champion of Soviet space programe had his jaw permanently broken in one of NKVD/KGB torture sessions. This later led to his untimely demise.

Making the animation after generating a password exactly 1 second seems oddly suspicious.

Conspiracy, rofl? Also, he is not owned, he always wanted to serve to the "Big Brother", afaik. That's a mentality.

ledger, hmm...is that the same ledger that got hacked and leaked personal user info related to crypto wallets :D

same password != same password. Ignore this message just tryna git 2 karma.

I use Bitwarden and it's open source. Switched over from LastPass and haven't regretted it since

Bitwarden has the best UI/UX of any password manager I have used, by far. In particular it puts LastPass (which I switched from) to shame.

I rarely use the premium features, but I pay for premium anyway to support the project. Costs a dollar a month, so barely noticeable.

Yeah I evaluated a few team password managers for a friend's small business and Bitwarden was the clear winner (1Password was second, but fell due to the requirement for a long random master key). I was surprised by just how bad Last pass and Dashlane were considering how much they spend on advertising

Can you elaborate on the issues with Lastpass? I haven't looked at other managers but Lastpass seems fine.

it can be a bit club-footed on the mobile platform. but yeah its my password manager of choice as well.

Are you on Android or iOS? The iOS app is really well done IMO.

The iOS version won't remember my banking app password for some reason. That works on Android though.

Other than that it's been hands down the best.

Android.

I often run into problems where the bloody stupid "use bitwarden to fill this field" hover button pops up over the field i need to paste something into. I need to do that because the app hasn't detected the app i'm using is actually a password i currently only have the web URI password saved for.

Agreed, works on Android, but it's clumsy.

I have to use 1password for work and hate the UI compared to bitwarden

Could you please elaborate? I've been using 1password for a while, and I can't imagine how it could be any better

Same. We have it at work, but 1Password's UI is the reason I use it at home as well.

Seriously I LOVE 1password. I moved away from LastPass to it after reviewing some of the OSS offerings. I have not found a more feature-complete (and pretty for that matter) alternative.

One of the my favorite features that I cannot find in other password managers it the built-in 2fa support. Click to login to a 2fa enabled site and it copies the code to your clipboard so you just paste and voila at the next screen. Perfect!

One example is how 1password hijacks the ctrl+F key combination.

So, if I have a long secret, perhaps a config section, I have to manually copy and paste it into a text editor in order to properly search through it.

I mostly like Bitwarden but I really miss the 1password feature where it shows your password in big text with each character numbered. I have a few accounts that do that dumb "give us the 5th, 12th and 21st characters" thing.

What did you find was better about Bitwarden?

Not GP, but LastPass's weird restrictions on devices, for one.

No restrictions on number of devices for one.

Everything else was the same and I didn't feel like I losing out, so it was easy to switch. They have an import tool that made it easier

Killer feature for me is the URI matching options. Each entry can have URIs, and each URI can match based on: Base Domain, Host, Starts With, Exact, or Regex.

This simplified a bunch of things for me:

* Dev deployments of an app, where I have one or two different logins (eg, the default admin login) but it's deployed on a bunch of subdomains and/or internal IPs and/or internal non-FQDN hosts

* A bunch of work systems on different domains where there's old-style SSO (synchronized password, but login form as part of the app)

* Android apps just get a URI like com.domain.AppName and can otherwise be consolidated with other entries, etc

I looked into Bitwarden for work, but there's no password reset option for admins. I don't know how many times people have forgotten their password manager's password and I've had to reset it. Without that feature, Bitwarden is a non-starter for a corporate environment.

It was just added last week

https://bitwarden.com/blog/post/admin-password-reset-is-out/

I hope this makes it into bitwarden_rs, which is what we use at work, soon. That and/or the ability to disable personal vaults would go a long ways for us.

bitwarden_rs has been renamed to vaultwarden

https://github.com/dani-garcia/vaultwarden

Wouldn't be a HN password manager thread without someone randomly plugging Bitwarden when it has nothing to do with the actual topic :)

It is like being a Haskell developer (monads all the way down) or emacs/vim user.

It's somewhat related because OSS password generator logic has better observability than proprietary products.

Chose Bitwarden as well. I like that it's open source. I've heard good things about KeePass as well.

Has anyone had any success in getting your TOTP shared secrets out of Lastpass Authenticator?

I don't think it's quite what you were asking, but I always avoided Two Factor Auth because I don't use a smartphone and all the approved methods seemed to use phone apps.

A year ago, one of my accounts forced me to enable two factor auth, so I spent time looking into how to make it less onerous. Turns out the TOTP code stuff is an open standard and there is a command line tool [1] you can use to generate the codes.

Thought that was really neat. I wrote a little script to integrate with my password manager and went from avoiding two factor auth to enabling it everywhere.

[1] https://www.nongnu.org/oath-toolkit/oathtool.1.html

Kaspersky works for KGB, that was the main reason to avoid.

The title is misleading. Yes, the passes are generated using a crappy and predictable seed value, but the passes are stored in a vault, and good luck breaking into that vault providing you use a strong master password, like a six-word diceware passphrase.

Unless any of the services you sign up for decide to log passwords like Facebook did, or store password hashes insecurely and get their database dumped online. I think it's pretty unsafe to assume that none of the passwords in your vault will leak from the service side, you just have to rely on the important services not screwing it up.

The vault does no good if you're passwords can be identically recreated by the attacker. Which the "crappy and predictable seed value", in combination with account creation time data, makes trivial. That creation time may be explicitly shown by the service, or at least hinted at through something like the timestamp of the user's first post.

To me, using a Password Manager puts you at risk, no matter which one you use. I cannot speak to windows, but on Linux, I use a encrypted text file via emacs. And to generate passwords:

tr -cd "[:alnum:]" < /dev/urandom | fold -w 20 | sed 10q

And a real TL;DR:

Upgrade your Kaspersky Password Manager

How does that encrypted text file put you less at risk than a password manager?

A password manager might have extra features such as browser plugins that provide a larger attack surface, but they can be switched off entirely. So, if you use more functionality than the encrypted text file, you might have more risk, fair enough, but when you use the same functionality, the risk seems comparable (or even: a password manager seems to offer somewhat more functionality for comparable risk).

Mainly I am in control of it, not a company that may or may not have access to what you are doing.

For example, that company may not be able to see your passwords. But they probably can see the servers/sites the passwords are for and maybe the hash.

I will not even speak about all the break-ins that seem to be occurring on CLoud Systems.

Really? what about memory protection? temp file cleanup? keylogging?

Encryption? what kind of KDF are you using? probably something old and quite brittle when it comes to hardware cracking.

sit this one down boy

If you're happy with the command line, using something like pass (https://www.passwordstore.org/) is worth serious consideration rather than rolling your own. It is GPLv2 and has a number of benefits, including the fact that your passwords are stored encrypted in a git repo and if you do "pass edit" it will call out to $EDITOR to do your edits, putting encryption/decryption and git transparently on both sides.

Unless you're a cryptographer, don't even think about rolling your own crypto (I'm not one, I did, and I'm ashamed of myself).

The context here was rolling your own password manager, not cryptography.

Reply on news.ycombinator.com