;;; ============================================================================ ;;; FILENAME: gen_password.ahk ;;; ============================================================================ ;;; Generates a pseudo-random password and copies it to clipboard. ;;; ============================================================================ ;;; ;;; AUTHOR: Scott Greenberg ;;; COMPANY: SEG Technology ;;; VERSION: 1.0.0, 09/28/2005 - 09/28/2005 ;;; WEBSITE: http://gogogadgetscott.info/ ;;; Copyright 2005. SEG Technology. All rights reserved. ;;; ;;; ============================================================================ ;;; HISTORY: ;;; ============================================================================ ;;; DISCLAIMER: ;;; Permission to use, copy, modify, and distribute this software ;;; for any purpose and without fee is hereby granted, provided ;;; that the above copyright notice appears in all copies and that ;;; both that copyright notice and this permission notice appear in ;;; all supporting documentation. ;;; ;;; THIS SOFTWARE IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED ;;; WARRANTY. ALL IMPLIED WARRANTIES OF FITNESS FOR ANY PARTICULAR ;;; PURPOSE AND OF MERCHANTABILITY ARE HEREBY DISCLAIMED. ;;; ============================================================================ ;;; Directives, required by this script (do not change) #SingleInstance force length = 9 password := gen_password(length) clipboard = %password% gen_password(length = 8) { possible = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890 StringLen, max, possible if length > %max% { MsgBox, Length must be smaller then number of possible characters. Exit, 40 } Loop { Random, rand, 1, max StringMid, char, possible, rand, 1 IfNotInString, password, %char% { password = %password%%char% if StrLen(password) >= length break } } return password }
password generator
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.I don't know how much entropy the random number initialization (seeding) uses. If it is based on the tick count...
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.
dynamic unpredictable values
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?
length = 8 Msgbox, 64, Password Generator by Titan, % "Password with alpha-numerical characters:`t" password(length) "`nPassword with aplha characters:`t`t" password(length, 1) "`nPassword with numerical characters:`t`t" password(length, 2) "`nPassword with any chracters:`t`t`t" password(length, 3) password(l=5, chars=0) { cAlpha = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ cNum = 1234567890 cAlphaNum = %cAlpha%%cNum% cMixed = %cAlpha%%cNum%.%A_Space%!"£$`%^&*()_-=+{}[]`;:``@'#~<>,./?\|¬¦ If chars in 0,alphanum StringSplit, list, cAlphaNum else If chars in 1,alpha StringSplit, list, cAlpha else If chars in 2,num StringSplit, list, cNum else If chars in 3,mixed StringSplit, list, cMixed Loop, % l { Random, rnd, 1, % list0 i := list%rnd% pass = %pass%%i% } Return, % pass }
autohotkey.com/net Site Manager
Contact me by email (polyethene at autohotkey.net) or message tidbit
(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...(Titan's version is more general, but it has the same limited randomness as the original.)
autohotkey.com/net Site Manager
Contact me by email (polyethene at autohotkey.net) or message tidbit
The difficulty is in estimating the entropy
Is "estimating" referring to prediction or assessment of quality thereafter? There are numerous tests to objectively measure the quantity of entropy.
they don't change very fast. Mouse movements and keystroke timing cannot be used either, because there is no user input for long times.
Is the issue with the sample time (practicality of the method) or is there a fundamental problem with using any single source?
output is the noise of the image sensor electronics.
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.I don't know of any sensible way to make it more random...
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.There are numerous tests to objectively measure the quantity of entropy.
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.Is the issue with the sample time (practicality of the method) or is there a fundamental problem with using any single source?
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.Is the noise solely a measurement of the thermodynamics of the system?
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.Are there other aspects of the system which contribute to the quality of such an entropy source?
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.Could you use the PC microphone as a similar quality source of entropy?
You have left me with something to think about -- always good.
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.
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.