[HN Gopher] Kaspersky Password Manager: All your passwords are b...
___________________________________________________________________
Kaspersky Password Manager: All your passwords are belong to us
Author : syck
Score : 235 points
Date : 2021-07-06 10:38 UTC (12 hours ago)
(HTM) web link (donjon.ledger.com)
(TXT) w3m dump (donjon.ledger.com)
| verytrivial wrote:
| > 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.
| enraged_camel wrote:
| The real fun thing would be if we discovered that they
| deliberately added the 1+ second animation to hide the bug. :)
| tomrod wrote:
| I recall this was an issue too for certain RSA tokens.
| dogma1138 wrote:
| That was because some RSA tokens had identical seeds, it was
| only affecting some of the older time based tokens.
| proactivesvcs wrote:
| "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.
| ..
| Tempest1981 wrote:
| 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?
| CJefferson wrote:
| 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.
| dchest wrote:
| 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.
| htrp wrote:
| 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...
| Tempest1981 wrote:
| Cool, but why are they on public display? Sufficiently hard
| to hack as-is?
| wlonkly wrote:
| You said it yourself: "Cool"
| Scaevolus wrote:
| 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.
| [deleted]
| speedgoose wrote:
| 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.
| dchest wrote:
| 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.
| dchest wrote:
| There is no better solution for the client-side web.
| getRandomValues() generates cryptographically secure random
| bytes in all current popular browsers.
| omegalulw wrote:
| 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?
| marshray wrote:
| 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.
| jfktkrkfk wrote:
| Getting some DUAL_EC prng vibes.
|
| Insert Kaspersky owned by Russia intelligence conspiracy here...
| varjag wrote:
| Kaspersky's Advanced School of KGB graduation photos:
|
| https://cs6.pikabu.ru/post_img/big/2017/07/04/11/14991974131...
| nix23 wrote:
| 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).
| varjag wrote:
| 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.
| nix23 wrote:
| So it's not KGB anymore right? And not a KGB School
| right? And your Picture has nothing todo with kaspersky
| right?
| input_sh wrote:
| 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/Na
| tional_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.
| varjag wrote:
| I'm not sure what is your point here. There is an
| unbroken contiunity of CheKa/NKVD/MGB/KGB/FSB.
| nix23 wrote:
| 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?
| varjag wrote:
| 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).
| ComodoHacker wrote:
| 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.
| varjag wrote:
| 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.
| ComodoHacker wrote:
| Are there any data, if we talk factual?
| varjag wrote:
| 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.
| ComodoHacker wrote:
| 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.
| varjag wrote:
| 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.
| dncornholio wrote:
| Making the animation after generating a password exactly 1
| second seems oddly suspicious.
| dandanua wrote:
| Conspiracy, rofl? Also, he is not owned, he always wanted to
| serve to the "Big Brother", afaik. That's a mentality.
| simias wrote:
| 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.
| dheera wrote:
| 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.
| bruce343434 wrote:
| > 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?
| ericbarrett wrote:
| 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.
| cogman10 wrote:
| 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.
| comicjk wrote:
| 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
| CyberRage wrote:
| 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.
| Blikkentrekker wrote:
| What I've been wondering for a long time is how do these two
| passwords compare: hiKxChDiaHNAtgVz
|
| _vis-a-vis_ : kahdikyylkonekkimahdakerttaksa
|
| One is a 16 random `[a-zA-Z0-9]` characters, the other is a
| 32 character long nonce word, containing <a> and <o> 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?
| ludamad wrote:
| 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
| CyberRage wrote:
| 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.
| Blikkentrekker wrote:
| 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.
| CyberRage wrote:
| 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.
| Blikkentrekker wrote:
| 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 aequivalent to
| attempting to bruteforce 32 characters, giving priority
| to letters and vowels, especially with the inclusion of
| <a> and <o>.
| CyberRage wrote:
| 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
| techrat wrote:
| 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 "thisisasuperlongpasswordandith
| as12345alotofcharactersinitthatwouldtake12345rainbowtablesa
| longtimetocalculatefor"
|
| 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.
| Blikkentrekker wrote:
| > _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.
| omegalulw wrote:
| What's wrong with seeding with time so long as you do it with
| nanoseconds?
| kadoban wrote:
| 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.
| simias wrote:
| 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.
| sega_sai wrote:
| 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).
| propwash wrote:
| I use Bitwarden and it's open source. Switched over from LastPass
| and haven't regretted it since
| JackMcMack wrote:
| Has anyone had any success in getting your TOTP shared secrets
| out of Lastpass Authenticator?
| war1025 wrote:
| 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
| llampx wrote:
| I have to use 1password for work and hate the UI compared to
| bitwarden
| Biganon wrote:
| Could you please elaborate? I've been using 1password for a
| while, and I can't imagine how it could be any better
| kspacewalk2 wrote:
| Same. We have it at work, but 1Password's UI is the reason
| I use it at home as well.
| chewmieser wrote:
| 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!
| jlund-molfese wrote:
| 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.
| mcintyre1994 wrote:
| 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.
| Gatsky wrote:
| What did you find was better about Bitwarden?
| propwash wrote:
| 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
| square_usual wrote:
| Not GP, but LastPass's weird restrictions on devices, for
| one.
| gregmac wrote:
| 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
| jpxw wrote:
| 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.
| kalleboo wrote:
| 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
| convery wrote:
| Can you elaborate on the issues with Lastpass? I haven't
| looked at other managers but Lastpass seems fine.
| senectus1 wrote:
| it can be a bit club-footed on the mobile platform. but yeah
| its my password manager of choice as well.
| Grimm665 wrote:
| Agreed, works on Android, but it's clumsy.
| jpxw wrote:
| Are you on Android or iOS? The iOS app is really well done
| IMO.
| senectus1 wrote:
| 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.
| artificialLimbs wrote:
| 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.
| tvanantwerp wrote:
| 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.
| josu wrote:
| It was just added last week
|
| https://bitwarden.com/blog/post/admin-password-reset-is-out/
| AnIdiotOnTheNet wrote:
| 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.
| andrewkdinh wrote:
| bitwarden_rs has been renamed to vaultwarden
|
| https://github.com/dani-garcia/vaultwarden
| Hawxy wrote:
| Wouldn't be a HN password manager thread without someone
| randomly plugging Bitwarden when it has nothing to do with the
| actual topic :)
| SEJeff wrote:
| It is like being a Haskell developer (monads all the way
| down) or emacs/vim user.
| grammers wrote:
| Chose Bitwarden as well. I like that it's open source. I've
| heard good things about KeePass as well.
| jmclnx wrote:
| 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
| seanhunter wrote:
| 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.
| denton-scratch wrote:
| 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).
| war1025 wrote:
| The context here was rolling your own password manager, not
| cryptography.
| FabHK wrote:
| 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).
| jmclnx wrote:
| 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.
| CyberRage wrote:
| 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
| sysadm1n wrote:
| 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.
| Snild wrote:
| 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.
| mcintyre1994 wrote:
| 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.
| waynesonfire wrote:
| get your dice keys. https://dicekeys.com/
| 123pie123 wrote:
| >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
| Hackbraten wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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)
| acidburnz wrote:
| same password != same password. Ignore this message just tryna
| git 2 karma.
| mcintyre1994 wrote:
| > 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.
| Tempest1981 wrote:
| 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.
| justshowpost wrote:
| Kaspersky works for KGB, that was the main reason to avoid.
| DevX101 wrote:
| 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...
| whatsapps2020 wrote:
| 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.
| mouzogu wrote:
| ledger, hmm...is that the same ledger that got hacked and leaked
| personal user info related to crypto wallets :D
| egze wrote:
| Also there are always FSB agents sitting in Kaspersky office. Let
| that sink in.
___________________________________________________________________
(page generated 2021-07-06 23:03 UTC)