6 ms·

Do not generate passwords with it, it uses insecure Math.random: https://github.com/antelle/kdbxweb/blob/906e927d3e3384db4dd393f6a9cbba00b1c85720/lib/crypto/ra

by dchest 11y ago

Do not generate passwords with it, it uses insecure Math.random: https://github.com/antelle/kdbxweb/blob/906e927d3e3384db4dd393f6a9cbba00b1c85720/lib/crypto/random.js#L19 https://github.com/antelle/kdbxweb/blob/906e927d3e3384db4dd3... https://github.com/antelle/keeweb/blob/master/app/scripts/util/password-generator.js#L29 https://github.com/antelle/keeweb/blob/master/app/scripts/ut... (in meme form: https://imgur.com/FcZNflQ https://imgur.com/FcZNflQ) Filed issue: https://github.com/antelle/kdbxweb/issues/5 https://github.com/antelle/kdbxweb/issues/5 (embarrassing/funny: it was me who wrote Salsa20 "user-space" generator used here (https://github.com/antelle/kdbxweb/blob/906e927d3e3384db4dd393f6a9cbba00b1c85720/lib/crypto/salsa20.js#L3 https://github.com/antelle/kdbxweb/blob/906e927d3e3384db4dd3...), but it should be properly seeded from secure random number source to be secure. Added this note to the gist where the author found it: https://gist.github.com/dchest/4582374#file-salsa20-js-L1-L16 https://gist.github.com/dchest/4582374#file-salsa20-js-L1-L1...)

judofyr 11y ago
Is there a practical attack for this usage? The attacker would need to have a bunch of your passwords already? EDIT: Not that I'm justifying using Math.random, I just don't see why you so strongly recommend against using this tool.
- blakesterz 11y ago
  >> Is there a practical attack for this usage? This is the question I ask every single time I read about anything in security. It feels like there's just SO MANY THINGS wrong about every damn thing now the only way I can figure out what I have to really worry about or focus on is anything with a PRACTICAL attack that's easily automated and remotely exploitable.
  - dchest 11y ago
    Cryptographic attacks become better, some of them become practical. RC4 attacks were not considered practical until recently, and now everyone runs with their heads on fire replacing it. The best answer is to listen to what security people say. When they have a practical attack on something it is already too late.
    - Touche 11y ago
      Security experts, by in large, only care about academics and care very little about usability, so I do not trust them unless they give me specific scenarios where I am in danger.
      - dchest 11y ago
        Eh, okay? Your choice, dear Touche, your choice.
        Touche 11y ago
        Just to clarify what I mean; we have to make decisions based on tradeoffs. Having the most secure password possible is not the only thing that matters. So "trust security experts" is not a good response; I need to know threat levels so I can make informed decisions. I'm not just going to do the same thing a security enthusiast does because I value different things, to different degrees.
        dchest 11y ago
        Looks like you didn't understand the sadness of the issue I was reporting. The author of the software constructed his own random number generator from two primitives: Salsa20 stream generator and Math.random. The last part is what makes this PRNG theoretically insecure: because Math.random is not guaranteed to give cryptographically secure random numbers, thus, theoretically, the generated passwords can be guessed. (The fact that there are no current attacks on current implementations of Math.random in browsers doesn't mean that we won't get them in the future.) The secure alternative to author's PRNG is ~one line of code: window.crypto.getRandomBytes. There are no tradeoffs involved! On the contrary, the author's insecure construction is more difficult to write than the secure one. (BTW, while we here argue about security experts, the author said "Thank you, I'll replace it of course.")
        Touche 11y ago
        This is what I'm talking about. You, a security enthusiast, are only interested in the technical security details. You respond to a comment about tradeoffs with details on the bug. I don't care about why the bug happened or how easy it is/isn't to fix. I care about whether the existence of the bug is something I should be so concerned about as to not use the software. In order to gauge that, I need a little more info about the threat level.
  - DenisM 11y ago
    I feel like your conclusion is the opposite of proper. Proper would be: don't roll your own crypto, use what professionals created, and only in the way they document it to be used. When in doubt, email tptacek or another professional he would point out.
  - marcosdumay 11y ago
    It's (relatively) easy to verify a software against a strict security definition and decide if it meets the definition or not. It's incredibly difficult (I'd say "impossible", but I'm being pedantic for now) to check a flaw against such strict definition and check it against all possible use cases and all possible inputs and decide if one of them will lead to bad consequences. Thus, if there's any practical attack? How the hell would I or anybody else know. We can only know a resounding "yes" after you get owned, nobody can ever tell you a honest "no" to this question.
- dchest 11y ago
  I don't know of any published attacks on XorShift128+, which is used in most browsers for Math.random. What I know is that it's not a cryptographically secure PRNG, though, so all you have to do is sit and wait for one ;-)
  - eterm 11y ago
    I believe window.crypto should be used. https://developer.mozilla.org/en-US/docs/Web/API/RandomSource/getRandomValues https://developer.mozilla.org/en-US/docs/Web/API/RandomSourc... > The RandomSource.getRandomValues() method lets you get cryptographically random values. The array given as the parameter is filled with random numbers (random in its cryptographic meaning). > To guarantee enough performance, implementations are not using a truly random number generator, but they are using a pseudo-random number generator seeded with a value with enough entropy. The PRNG used differs from one implementation to the other but is suitable for cryptographic usages. Implementations are also required to use a seed with enough entropy, like a system-level entropy source.
    - dchest 11y ago
      Correct, I provided browser (using window.crypto) & Node (crypto) compatible implementation in the bug report: https://github.com/antelle/kdbxweb/issues/5 https://github.com/antelle/kdbxweb/issues/5
- Spooky23 11y ago
  Its all about risk/impact. IMO, in most cases it is a non-issue. But... If you use a badly generated password as a key for a encrypted volume, then you might have a problem.
dangerlibrary 11y ago
Just so we're clear: your assertion is that because the password generator uses a non-cryptographically secure PRNG, generating unique 20+ character alphanumeric passwords for every login is worse than people's default behavior? I mean, I get that it's worse than other keepass implementations - that's obviously a problem - but if this gets people to stop using "hunter2" or "p4$$w0rd" that's got to be worth something, right?
- dchest 11y ago
  No, it's not worse for your scenario. (That wasn't my assertion) However, this is an alternative to KeePass/KeePassX, so the typical behavior of KeePass users is to generate passwords with it, not reuse bad passwords. For example, I use KeePassX to generate strong passwords for long-term encrypted archives, and if I switched to this app, I wouldn't get the same security. I'm confused, though, should I say: "All right, people, fuck it, generate your passwords with Math.random! YOLO!"
  - wodenokoto 11y ago
    I use KeePass and I don't use it to generate passwords. It's a pain to open and close every time I need to login somewhere, especially if I'm on mobile. I use it for when I forget my passwords, and I honestly believe that is the common use case, but who knows?
    - brbsix 11y ago
      I hope that's not a common use case (among the technologically literate). I would expect said individuals to have far more passwords of sufficient length and complexity (not to mention duration) than could reasonably be remembered.
    - takluyver 11y ago
      Lastpass, being primarily a browser plugin, makes generated passwords much more convenient. When I'm setting up a new account, I press Alt-G to bring up the generator dialog, and then it auto-fills when I need to log in. I honestly don't know most of my passwords (I still memorise my primary email password, so I'm not totally stuck if I lost access to LastPass). This is a compromise, because I'd prefer to trust an open source tool and an encrypted local file, but I trust Lastpass enough, and the convenience is very nice.

by dchest 11y ago

judofyr 11y ago

Is there a practical attack for this usage? The attacker would need to have a bunch of your passwords already? EDIT: Not that I'm justifying using Math.random, I just don't see why you so strongly recommend against using this tool.

blakesterz 11y ago
>> Is there a practical attack for this usage? This is the question I ask every single time I read about anything in security. It feels like there's just SO MANY THINGS wrong about every damn thing now the only way I can figure out what I have to really worry about or focus on is anything with a PRACTICAL attack that's easily automated and remotely exploitable.
- dchest 11y ago
  Cryptographic attacks become better, some of them become practical. RC4 attacks were not considered practical until recently, and now everyone runs with their heads on fire replacing it. The best answer is to listen to what security people say. When they have a practical attack on something it is already too late.
  - Touche 11y ago
    Security experts, by in large, only care about academics and care very little about usability, so I do not trust them unless they give me specific scenarios where I am in danger.
    - dchest 11y ago
      Eh, okay? Your choice, dear Touche, your choice.
      - Touche 11y ago
        Just to clarify what I mean; we have to make decisions based on tradeoffs. Having the most secure password possible is not the only thing that matters. So "trust security experts" is not a good response; I need to know threat levels so I can make informed decisions. I'm not just going to do the same thing a security enthusiast does because I value different things, to different degrees.
        dchest 11y ago
        Looks like you didn't understand the sadness of the issue I was reporting. The author of the software constructed his own random number generator from two primitives: Salsa20 stream generator and Math.random. The last part is what makes this PRNG theoretically insecure: because Math.random is not guaranteed to give cryptographically secure random numbers, thus, theoretically, the generated passwords can be guessed. (The fact that there are no current attacks on current implementations of Math.random in browsers doesn't mean that we won't get them in the future.) The secure alternative to author's PRNG is ~one line of code: window.crypto.getRandomBytes. There are no tradeoffs involved! On the contrary, the author's insecure construction is more difficult to write than the secure one. (BTW, while we here argue about security experts, the author said "Thank you, I'll replace it of course.")
        Touche 11y ago
        This is what I'm talking about. You, a security enthusiast, are only interested in the technical security details. You respond to a comment about tradeoffs with details on the bug. I don't care about why the bug happened or how easy it is/isn't to fix. I care about whether the existence of the bug is something I should be so concerned about as to not use the software. In order to gauge that, I need a little more info about the threat level.
- DenisM 11y ago
  I feel like your conclusion is the opposite of proper. Proper would be: don't roll your own crypto, use what professionals created, and only in the way they document it to be used. When in doubt, email tptacek or another professional he would point out.
- marcosdumay 11y ago
  It's (relatively) easy to verify a software against a strict security definition and decide if it meets the definition or not. It's incredibly difficult (I'd say "impossible", but I'm being pedantic for now) to check a flaw against such strict definition and check it against all possible use cases and all possible inputs and decide if one of them will lead to bad consequences. Thus, if there's any practical attack? How the hell would I or anybody else know. We can only know a resounding "yes" after you get owned, nobody can ever tell you a honest "no" to this question.
dchest 11y ago
I don't know of any published attacks on XorShift128+, which is used in most browsers for Math.random. What I know is that it's not a cryptographically secure PRNG, though, so all you have to do is sit and wait for one ;-)
- eterm 11y ago
  I believe window.crypto should be used. https://developer.mozilla.org/en-US/docs/Web/API/RandomSource/getRandomValues https://developer.mozilla.org/en-US/docs/Web/API/RandomSourc... > The RandomSource.getRandomValues() method lets you get cryptographically random values. The array given as the parameter is filled with random numbers (random in its cryptographic meaning). > To guarantee enough performance, implementations are not using a truly random number generator, but they are using a pseudo-random number generator seeded with a value with enough entropy. The PRNG used differs from one implementation to the other but is suitable for cryptographic usages. Implementations are also required to use a seed with enough entropy, like a system-level entropy source.
  - dchest 11y ago
    Correct, I provided browser (using window.crypto) & Node (crypto) compatible implementation in the bug report: https://github.com/antelle/kdbxweb/issues/5 https://github.com/antelle/kdbxweb/issues/5
Spooky23 11y ago
Its all about risk/impact. IMO, in most cases it is a non-issue. But... If you use a badly generated password as a key for a encrypted volume, then you might have a problem.

dangerlibrary 11y ago

Just so we're clear: your assertion is that because the password generator uses a non-cryptographically secure PRNG, generating unique 20+ character alphanumeric passwords for every login is worse than people's default behavior? I mean, I get that it's worse than other keepass implementations - that's obviously a problem - but if this gets people to stop using "hunter2" or "p4$$w0rd" that's got to be worth something, right?

dchest 11y ago
No, it's not worse for your scenario. (That wasn't my assertion) However, this is an alternative to KeePass/KeePassX, so the typical behavior of KeePass users is to generate passwords with it, not reuse bad passwords. For example, I use KeePassX to generate strong passwords for long-term encrypted archives, and if I switched to this app, I wouldn't get the same security. I'm confused, though, should I say: "All right, people, fuck it, generate your passwords with Math.random! YOLO!"
- wodenokoto 11y ago
  I use KeePass and I don't use it to generate passwords. It's a pain to open and close every time I need to login somewhere, especially if I'm on mobile. I use it for when I forget my passwords, and I honestly believe that is the common use case, but who knows?
  - brbsix 11y ago
    I hope that's not a common use case (among the technologically literate). I would expect said individuals to have far more passwords of sufficient length and complexity (not to mention duration) than could reasonably be remembered.
  - takluyver 11y ago
    Lastpass, being primarily a browser plugin, makes generated passwords much more convenient. When I'm setting up a new account, I press Alt-G to bring up the generator dialog, and then it auto-fills when I need to log in. I honestly don't know most of my passwords (I still memorise my primary email password, so I'm not totally stuck if I lost access to LastPass). This is a compromise, because I'd prefer to trust an open source tool and an encrypted local file, but I trust Lastpass enough, and the convenience is very nice.