Random Password Generation with 16 Numeric Digits
Hi All,
Folowing are my requirements
1. Generate 16 Digits long Randomize Numeric Passwords,
Please not that, I need to generate password in bulk i.e. Generate 1000 to 10000 pasword in single trigger
2. Store All Generated Password in Database
My Problem:
1. First of All How to Generate Random Numeric Password of desired length
2. How to make sure that all generated password are unique throught the system since Password is a Primary key in my respective database storage.
3. It is to lengthy to iterate password generation process for each password to make sure that the same password does not exist in the database.
PLEASE HELP....
You can use a linear congruential random number generator (the math is in Knuth) of maximal period as a perfect hashing function. Basically every 16 digit number leads to exactly one other 16 digit number and every 16 digit number shows up somewhere on the list. Thus a unique set of inputs (like 1,2,3,4,...)can be converted to a unique (and somewhat randomized) set of outputs.
This code will generate a unique 16 digit number for each unique positive value of foo that is supplied.
// for details on magic numbers see Knuth - Seminumerical Algorithms p.155
static BigInteger preA = new BigInteger("3781927463263421");
static BigInteger preC = new BigInteger("2113248654051873");
static BigInteger preM = new BigInteger("10000000000000000");
static String pass10(int foo){
if(foo<0)return "please supply positive argument to pass10";
String in = ""+foo;
BigInteger x = new BigInteger(in);
String res = x.multiply(preA).add(preC).mod(preM).toString();
while(res.length() < 16) res = "0"+res; // supply leading 0s to small numbers.
return res;
}
Note: The only important digits in preA are the last 3. Modify a few of the top ones so that your code does something different than the supplied code. Also, pass10(0) will always be the value preC regardless of what value you choose for preA and the value preC is now somewhat tainted as a password (since it has been published right here in this forum and will live forever in some google index) it would be best to avoid using 0 as an argument to pass10(). Just start your counting process somewhere other than 0.
> You can use a linear congruential random number
> generator (the math is in Knuth)
1) Are LC random number generators truly guaranteed to transform a unique sequence of input values into a unique sequence of output values? I would suspect not, given the use of "mod". I checked the page reference you gave, but it must be from a different edition; in the 2nd edition, that page is in the middle of his discussion of the properties of random sequences.
2) java.util.Random uses an LC random number generator. No need to reimplement.
3) To the OP: storing passwords in your database is generally considered a bad idea from a privacy perspective. Making them be the primary key is a bad idea from the perspective of logical modeling: the password is an attribute of the person, not the other way around.
Sorry bout the page number. Looks like my book is a first edition since it has no edition number, only a copyright of 1969 which is about when I bought it. At the end of chapter 3 in the first edition he summarizes the requirements to build a RNG of maximal period. That was the section I refered to.
You can NOT use the random number generator that comes with java for the OPs purpose. I haven't looked but but even if it is a Linear Congruential RNG it is almost for sure tailored to the 32 or 64 bit binary register size of a typical PC rather than to the 16 decimal digits that the OP was looking for.
What a maximum cycle LCG does is to cycle between all the possible values that could fit into a single numeric register on a computer. This is done deterministically and hence it hits every possible number exactly once even though by design the numbers hop around quite a lot.
This behavior of nailing each number exactly ones is NOT the behavior that you want from a random number generator it is only the behavior that you want going on down in the guts of a RNG. In random number applications you typically take the large bit value sitting in the register and peal off only a few bits (either by a multiplication or by a mod function) and those bits will certainly show repetition. So even though some integer register is taking on a unique set of values, when you reduce it mod 6 you do NOT see a cycle between 6 numbers instead you get a dice face that can easily repeat numbers getting say three twos in a row.
The actual purpose of the mod function that shows up in the calculation is to mimic the truncation that happens when you do your calculations in a fixed size computer register. Thus on a typical machine a random number generation is one multiply and one add no mod is performed.
What we are mimicing here is a maximum cycle linear congruential random number generator that is working on a decimal computer with 16 digit long arithmetic registers and that is how we get the uniqueness. If I had modeled any larger or smaller RNG and reduced down to 16 digits I would not get the uniqueness.
Generating uniqueness is not trivial (that is what took hundreds of pages of math in Knuth's book - well he did talk about some other things as well) However the actual requirements are easy to state and I will state them here extracting from his summary, BUT it is not trivial to show why these rather peculiar requirements are there.
LCRNG are based on the following formula
x = (A*x + C) mod M
where M is a power of 10 for a decimal computer
requirements for decimal registers that are 2N digits long
1) A mod 200 = 21; this means that A ends with 021,221,421,621 or 821
2) If the register is 2N digits long, the top N digits of A can not all be 0s and can not all be 9's. Best if first digit is neither 9 nor 0 and also best if the digits in A are somewhat random rather that some pattern like 333333333
3) the number C shoud be odd and not divisible by 5; this means last digit of C must be 1,3,7 or 9
4) it is best if C/M is approximately equal to 1/2 - sqrt(3)/6 which means that C should have 2N digits and start out 211324865...
Lastly, if you would like some evidence that this algorithm is correct (not proof, just evidence) do the following
reduce the lengths the static integers that I used from their 16 digit long forms to being only 4 digits long still following the rules above, so for example try A = 3421, C = 2113, M = 10000
Thus you are dealing with a register that can hold the values from 0 to 9999.
This is a small enough set that you can test the uniqueness.
create an array of ints 10000 units long, map the ints from 0 to 9999, set the value in the int arry to non zero for each result and barf if you ever go to set a value that was already set.
Do the same thing with 5 digits, say, A = 61421, C = 21133, M = 100000
observe no collisions in a test of mapping a hundred thousand numbers into a space of a hundred thousand.
Works just like magic.
I agree with the comment about keeping passwords in databases, generally a bad idea. Usually you only ever want to keep hashes of passwords in databases, but that doesn't change any of the math for this particular solution of spreading out a set of values.
Enjoy!
