5 ms·

I feel like the discussion about uniform password generation and PRNG, while interesting, is relatively irrelevant here. Even a garbo xorshift-based non uniform

by simias 5y ago

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.

sega_sai 5y ago
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).
CyberRage 5y ago
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 5y ago
  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?
  - ludamad 5y ago
    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 5y ago
    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 5y ago
      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 5y ago
        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 5y ago
        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 <ö>.
dheera 5y ago
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 5y ago
> 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 5y ago
  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 5y ago
  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 5y ago
  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 https://news.ycombinator.com/item?id=7207851
omegalulw 5y ago
What's wrong with seeding with time so long as you do it with nanoseconds?
- simias 5y ago
  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.
- kadoban 5y ago
  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.

by simias 5y ago

sega_sai 5y ago

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

CyberRage 5y ago

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 5y ago
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?
- ludamad 5y ago
  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 5y ago
  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 5y ago
    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 5y ago
      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 5y ago
        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 <ö>.

dheera 5y ago

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 5y ago

> 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 5y ago
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 5y ago
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 5y ago
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 https://news.ycombinator.com/item?id=7207851

omegalulw 5y ago

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

simias 5y ago
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.
kadoban 5y ago
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.