Hacker News Reader

Comment by simias | Hacker News Reader

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.

View on HN

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

> 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

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.

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.

Reply on news.ycombinator.com