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.
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).
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.
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.
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.
There is no better solution for the client-side web. getRandomValues() generates cryptographically secure random bytes in all current popular browsers.
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.
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.
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.
>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
- 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.
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.
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 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.
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.
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.
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.
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:
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).
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.
[+] [-] verytrivial|4 years ago|reply
Whoa. That's just ... Wow.
[+] [-] tomrod|4 years ago|reply
[+] [-] golergka|4 years ago|reply
[+] [-] enraged_camel|4 years ago|reply
[+] [-] muthdra|4 years ago|reply
[+] [-] simias|4 years ago|reply
Seeding with the current time is the real sin here.
[+] [-] sega_sai|4 years ago|reply
[+] [-] CyberRage|4 years ago|reply
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.
[+] [-] bruce343434|4 years ago|reply
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?
[+] [-] dheera|4 years ago|reply
[+] [-] omegalulw|4 years ago|reply
[+] [-] Tempest1981|4 years ago|reply
- 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?
[+] [-] dchest|4 years ago|reply
[+] [-] Scaevolus|4 years ago|reply
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.
[+] [-] CJefferson|4 years ago|reply
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.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] speedgoose|4 years ago|reply
[+] [-] 123pie123|4 years ago|reply
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
[+] [-] Hackbraten|4 years ago|reply
- 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.
[+] [-] wereHamster|4 years ago|reply
[+] [-] simias|4 years ago|reply
- 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.
[+] [-] whatsapps2020|4 years ago|reply
I’m on that list and I’m scared.
[+] [-] Tempest1981|4 years ago|reply
But good to note that mt19937 is still not cryptographically secure.
[+] [-] egze|4 years ago|reply
[+] [-] DevX101|4 years ago|reply
https://en.wikipedia.org/wiki/Kaspersky_bans_and_allegations...
[+] [-] mcintyre1994|4 years ago|reply
Pretty terrible bug to be unpatched and presumably uncommunicated for 2 years. Ouch.
[+] [-] waynesonfire|4 years ago|reply
[+] [-] jfktkrkfk|4 years ago|reply
Insert Kaspersky owned by Russia intelligence conspiracy here...
[+] [-] varjag|4 years ago|reply
https://cs6.pikabu.ru/post_img/big/2017/07/04/11/14991974131...
[+] [-] dncornholio|4 years ago|reply
[+] [-] dandanua|4 years ago|reply
[+] [-] mouzogu|4 years ago|reply
[+] [-] acidburnz|4 years ago|reply
[+] [-] propwash|4 years ago|reply
[+] [-] jpxw|4 years ago|reply
I rarely use the premium features, but I pay for premium anyway to support the project. Costs a dollar a month, so barely noticeable.
[+] [-] grammers|4 years ago|reply
[+] [-] tvanantwerp|4 years ago|reply
[+] [-] Hawxy|4 years ago|reply
[+] [-] Gatsky|4 years ago|reply
[+] [-] JackMcMack|4 years ago|reply
[+] [-] llampx|4 years ago|reply
[+] [-] justshowpost|4 years ago|reply
[+] [-] sysadm1n|4 years ago|reply
[+] [-] Snild|4 years ago|reply
[+] [-] mcintyre1994|4 years ago|reply
[+] [-] jmclnx|4 years ago|reply
tr -cd "[:alnum:]" < /dev/urandom | fold -w 20 | sed 10q
And a real TL;DR:
Upgrade your Kaspersky Password Manager
[+] [-] FabHK|4 years ago|reply
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).
[+] [-] seanhunter|4 years ago|reply
[+] [-] CyberRage|4 years ago|reply
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