I need a great Password Generator program. I looked at a few of them, but none of them seemed to be what I wanted. So I have decided to write my own. (That's the cool thing about being a programmer....I always get what I want in software )
Do you have any password generators that you like? Or do you have any thoughts on what you'd like to see in a password generator? I'm looking for ideas... No promises that I will implement anything. But you never know....I might. Or if I find a really great password generator, I might just go with that.
I plan on implementing this as a ksh script and I will be sure it runs on pdksh as well. So if have either ksh or pdksh you will be able to run the script.
ease of use, and following unix shell scripting guidlines.
by that i mean, takes input, gives output. so it can be used in other scripts.
i feel like me saying that serves no purpose however, because from looking at your recursive ftp shell script, i have no doubt of the quality of your work.
when you write this, i know right away what i am going to use it for.
i run an mp3 server, it streams mp3s through apache using perl. when i give my friends who ask for it user names and passwords, i usually end up making up a password for them.
what i will do now is, i will put a request for membership on my site. that way when one of my friends wants a un and pw they can do it them selves.
ill have it take their name and email, and desired username. blah blah blah, itll send me an email and wait for confirmation. after thats done itll use htpasswd, and your password generator to add them to my password list.
No, your comments are useful. Especially since I moving away from that type of interface. I wrote a simple password generator and it worked good enough with ksh. But with pdksh, it broke pretty bad. The symptom was that I could predict what character it would pick under certain conditions. I traced the problem to pdksh's internal linear congruential random number generator.
This sent me down the path of making an ultra secure password generator. And another potential problem is that command line arguments are visible to an adversary. So I've been moving away from command line arguments toward a completely interactive solution. Also I've been working on a very good random number generator. The current version gathers entropy from the user. By examining the SECONDS variable, I know how long the user took to enter the command. That number, together with the length of the command, is used to very strongly vary the output of the random number generator. Simply tapping the return key a few times will tremendously "stir the pot".
Perhaps I've been obsessing with security too much. I could add in a method of non-interactive use. This would sacrifice the cryptographic strength of the RNG. But a password generator can function well without a cryptographic strength RNG.
naw i think its a very good idea to use strong encryption, even at non mission critical sites.
like my setup, no ones trying to break into my network, other than the occasional port scan by script kiddies....but its nice to know they will have a tough time getting in if my ip just happens to interest them.
about command line arguments, a few scripts that ive written, ive implemented an interavtive mode, and a non interactive mode. do you think it would be practical for you to include something like that in your script?
Yes I will certainly not abandon interactive mode. Non-interactive mode will be in addition to interactive mode. In addition to gathering entropy from the user, I like to present the user with many passwords. Then the user can pick one that seems easy to remember or whatever.
And cryptographic strength in a random number generator does not mean that any encryption is happening. Take a look at my primary random number generator:
The X's are random numbers. This generator will pass any random number test you throw at it. But suppose you knew the first three numbers:
26999973
46000027
81269972
You could have a database of the first three numbers for every possible seed. You could look up these three numbers. Now you know that the seed was 27. And so you can predict every other random number that this generator will output. Thus this random number generator is said to be cryptographically weak. A cryptographically strong RNG is unpredictable.
Just for the heck of it, I wanted a cryptographically strong RNG. So what I do is call the main RNG 500 times and load the results into an array. Then when a command is entered, one of 60 auxiliary RNG's is selected based loosely on the SECONDS variable. This RNG generates a number between 0 and 499. That element of the array is returned and the master RNG is called again to replace it. There's a lot more to it...this is the reader's digest version. Suffice it to say that if you give me the first n random numbers that it outputs, I cannot predict n+1. And it's not just that I don't have enough computers. Infinite computing resources still would not do it. I would also need to know what commands you are entering and the value of the system clock each time that you press return. In addition the automatic stuff that happens, there are user commands to restart the RNG's, scramble the arrays, etc.
In a command line driven version, I will have to select one auxiliary RNG and go with that. No it won't be as secure. The output will be just as good. The danger would come from an evil Perderabo on the system while the password generator is running. He *might* be able to to acquire enough information to guess the generated password.
You laugh, but I've actually spent the better part of the past few weeks attempting to generate a file from which no information can be extracted!
I'm working on a random number generator for use with a password generator. So far it passes every test I can find except for test number 10 of the Diehard test suite. Diehard has a well deserved reputation as the toughest suite of tests for random number generators.
Perderabo -
try Blum Blum Shub PNRG. With correctly chosen large primes, it will meet almost any cryptographic need. Choosing the primes is not trivial. And you need gmp or some other BIGNUM.
Jim it has to run fast in ksh. I am developing a decimal arithemtic based multipy with carry. As far as I know, this is new ground. If I was coding in C, I would use the mersenne twister in a minute. I have toyed with trying to code it in ksh, but it's tough and I wouldn't trust my implementation until I understand how it works. Maybe next year. Meanwhile I want to get the MWC working. It is almost as fast as linear congruential generator. It really should be able to rid the world of lcg's. They persist only because they are fast and easily coded. Diehard is the first test that it hasn't passed. Diehard needs about 80,000,000 bits of random data for a single test run. This takes about 10 hours to generate, so progress is slow. I'm pretty sure the problem is arising when I convert the raw random number to an output modulus. But it will take a week or so to be sure.
I'll say it again: it has to run fast in ksh. And no, prngd cannot pass diehard. The output from /dev/random and /dev/urandom also flunks diehard for sunos and linux. Passing diehard is tough.
A sample run:
>>}###@>---- CvccvE-n
Template EEEEEEEE has 2,992,179,271,065,856 possibilities
Template CvccvE-n has 2,389,338,000 possibilities
Vephu}:6 VICTOR echo papa hotel uniform right-brace colon six
Sawtu]!7 SIERRA alpha whiskey tango uniform right-bracket exclamation seven
Yuywud-0 YANKEE uniform yankee whiskey uniform delta hyphen zero
MuwsaQ:4 MIKE uniform whiskey sierra alpha QUEBEC colon four
Yaqka%.7 YANKEE alpha quebec kilo alpha percent period seven
>>}###@>----
Each of those 2,389,338,000 possibilities must be absolutely equiprobable. And the selections chosen must be completely unpredictable. Achieving both goals simultaneously is not a piece of cake. And yes, RNGs are notoriously non-portable. I want to do all of this in a self-contained portable shell script.
)
