AutoHotkey Community

Nice! Why don't you allow character repetition? They increase the number of possible passwords of a given length and makes the script simpler.

I don't know how much entropy the random number initialization (seeding) uses. If it is based on the tick count, someone might just need a few million tries to reproduce your password, assuming you did not let your PC run over the weekend. In this case some additional randomness can be gained using a few least significant bits of the Performance Counter: discard this many random numbers generated, or add/mask the Performance Counter to the generated random number.

It's actually seeded from the low-order 32-bits of the 64-bit value described as "the number of 100-nanosecond intervals since January 1, 1601". If my calculations are correct, this results in a seed that traverses the full 32-bit range every 7.2 minutes. If true, this would be a much better seed than tick-count assuming that no one knows the exact time of day that you started the script.

For security applications this seeding might not be sufficient (nor was it designed for this kind of uses).

1. If the password (or nonce) is sent to an external site, an attacker could have a pretty accurate estimate of the time the password was generated, so the search space for the seed is small.

2. "The number of 100-nanosecond intervals" might not be very accurate. If it uses the Performance Counter, its resolution could be less than 100 ns, like in my laptop it is 280 ns. Some PC's don't even have this counter, and they have to resort scaling their normal timer of 10..15 ms resolution (100,000 times worse).

3. Even if everything is working perfectly, there are only 2**32 ~ 4*10**9 different seeds, so there are only this many different first passwords from a call of the password generator. It is a lot, but much less than the possible passwords of 9 characters, each from 62 choices of letters and digits (62**9 ~ 1.4*10**16). In a matter of weeks someone could try all the possible seeds.

In any case, my suggestion of tweaking the random numbers with the Performance Counter does not help. We can take some static PC specific information (like username, the serial number of the disk), and some dynamic unpredictable values, like a lot of time difference values between the user's keystrokes and create a random number of these. If it is in the range of a million, discarding this many random numbers increases the entropy of the first password by 20 bits. But it is better to collect at least 64 physically random bits like this, and hash or encrypt it. If you need more than one secure (pseudo) random number, you could encrypt the result again and again. It is much slower than the built in random number generator, but we don't need this key generator very often.

Could you use a metric such as processor utilization (on an active, dynamic system) as a source of entropy? After filtering values within a delta over a time range (likely a large sample), the result is a sequence of values which are certainly unpredictable. But are they random? To a lesser extent, could they be considered cryptographically secure?

What are your thoughts on this?

This is almost the same password generator but can produce different kinds of passwords. It's also very random.

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

People do use entropy sources, like processor load, available memory, used size or access time of the swap file, network packet arrival time (ping), cache fingerprint, etc. The difficulty is in estimating the entropy. In a server environment most of these values are pretty predictable, so they contribute to the overall randomness only a couple of bits each, and they don't change very fast. Mouse movements and keystroke timing cannot be used either, because there is no user input for long times. However, a $10 device, a webcam can provide thousands of random bits every second: if it is put in a dark box the output is the noise of the image sensor electronics.

(Titan's version is more general, but it has the same limited randomness as the original.)

Just out of curiosity, how is my version less random? I mean, it's only as random as AutoHotkey gets right? I don't know of any sensible way to make it more random...

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

Is "estimating" referring to prediction or assessment of quality thereafter? There are numerous tests to objectively measure the quantity of entropy.



Is the issue with the sample time (practicality of the method) or is there a fundamental problem with using any single source?



Is the noise solely a measurement of the thermodynamics of the system? Are there other aspects of the system which contribute to the quality of such an entropy source? Could you use the PC microphone as a similar quality source of entropy?

I tried to suggest ways to improve randomness: mix in other sources than the built in timer.

In the contrary: it is impossible to measure the entropy (of an infinite process) from any finite subsequence. Just think about: if you see a hundred 0's does it mean that the entropy is 0, that is, a totally non-random process? Of course not, the next bit can be anything. In fact, in any sufficiently long truly random sequence you will find hundred 0's with large probability.

Entropy is usually estimated. It means first creating a model of the process and then test the validity of this model with statistical means (that is, with high confidence). The entropy is derived from the properties of the model.

It is very hard to adequately model a computer system, because its usage can vary (user activity, running application, nearby computers, network load, sent/received emails, messages...). If we write an entropy collection program, we ought to know how much is predictable from its input. We need a worst case (off-line) estimate and an on-line estimate, which constantly monitors the sources of uncertainty, and updates parameters.

At low entropy sources we have to collect data longer. There is no fundamental problem with a single source of randomness, but only practical ones: it is a single point of failure / attack. Estimating its entropy wrong could have catastrophic consequences, but at several independent sources it is less likely that the overall entropy estimate is way off.

The noise in an electronic (sensor) circuit is partly thermal (Johnson) noise, but the are all kind of other effects, semiconductor noises, too: shot noise, avalanche noise, flicker noise, etc. In fact, the thermal noise is of the smallest peak amplitude of these, but has nice normal distribution. Other type of noise pulses show different, less well understood distribution. This is why Intel took the effort, when designing their random number generator in processor chipsets, to filter out most of the other noise sources.

Unfortunately, yes. Any strong electromagnetic radiation (like power supply, electron ray deflection signal in monitors, etc.), heat, vibration, particle radiation, etc. influences the behavior of sensitive electronics. The dark box webcam is best positioned far from these disturbances. Usually, these are periodic signals, and if they are not strong enough to mask the real noise, we can filter them out. However, if an adversary can get close to this random number generator, we get into troubles: a strong radiation modulated by pseudorandom numbers influences our circuit in such a way, which cannot be easily distinguished from true randomness.

Certainly, but I have not tried it myself. The webcam works well, because it has no real data to process, but a PC microphone is not so easy to be positioned in a quiet place. Otherwise it receives normal environment sounds, which look more random than they actually are. Still, I assume the microphone could provide a few hundred random bits a second.

Laszlo, thank you for your comprehensive response.

You have left me with something to think about -- always good.

I posted a script for that here

historically, the main danger with password generating scripts (and the reason they are strongly deprecated in the system administration world) is that if they can, administrators will tend to generate "batches" of passwords at once. Generally it takes a script a fraction of a second to generate hundreds of passwords.

For example, at the beginning of term, a system administrator might run a script to generate 1,000 new passwords for all the new students, which it will happily do on a fast machine in about 1/10th of a second.

A password generating script that uses time as a random seed can then be exploited by a malicious student, if he knows the algorithm used.

He can establish the algorithm even without viewing the source, if he has access to and can run the script itself: it's not trivial but can be done.

Once he knows the algorithm, he can establish what random seed would create his own password (the simplest way being to try them all). Then all he needs to do is generate a bunch of passwords from around that time, to have access to the logins of all his colleagues.

He doesn't even need to run ALL the random seeds within that second: if he knows roughly how long it takes to run the script, he can just generate clusters of passwords around multiples of that time.

This weakness is why modern operating systems allow accounts to be set to prompt for a password the first time people log in. On the face of it, this appears fatally insecure: ANYONE can get into the account of ANYONE else so long as the victim has never logged in.

But in fact, you're minimising the danger: there are no guessable password algorithms involved (other than user stupidity which is a whole 'nother topic), and accounts are only vulnerable when there's no useful information in them as they've never been used. And once they're tampered with, it's clearly evident, because the legitimate user can't log in.

_________________
Yet another hotkeyer.

I see alot of talk about the randomness of these type of generators. What about using a random number from a source such as www.random.org?

Of course, the computer that is running the script would have to be on the internet to grab the seed, but I see this as being a good solution to the seed issue.

To avoid the problem stated about running a batch to create many different passwords, the script could be set up to get a new seed from the random number server for each password, thus removing the possibility of finding the seed.

I am going to play with this script and see if I can adapt it to use a random number server as the source.

There are two different issues: randomness (entropy) and secrecy. If you grab a random number from a public source, your adversary will know it, within a small error. The public random number sites are useful for simulation, testing, but unsuitable for security related applications, like password or key generation.