Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Forget about a). With a minimum of 52-to-the-power-of-10 possibilities for the password, you'd be extremely unlikely (one in 10-to-the-17+ for a single number) to get a repeat on a random generation, and you'd need about 10-to-the-10+ passwords generated before you get to a one-in-a-million chance of a repeat.
Count your allowable characters. Generate 10 random numbers within that range. Use a table to access the stored characters, once for each character of the password.
Confirm whether the random number should be "seeded" or not. Your Audit/Security people will know, if no-one else.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
1. You need to understand "random" -- your point (a) completely contradicts the idea of randomness.
2. Computers do not generate mathematically random numbers -- what you get is a sequence of pseudorandom numbers. For IBM's Enterprise COBOL, from any given starting seed, you get over 2 billion values before they start repeating.
3. Read carefully the description of function RANDOM in the Enterprise COBOL Language Reference manual - it tells you several important things to know (such as the returned value is in the range of zero to one so you will have to scale it, and that you need to provide an initial seed value followed by no arguments; if you don't provide a seed the sequence will ALWAYS be the same).
4. How far back does the "requirement" for uniqueness go? If you are saying that there can never be a duplicate, then you might as well give up now as a pseudorandom sequence will repeat, sooner or later -- period. If not, you need to be clear about how many unique values are required before a duplicate could occur (a duplicate may not occur for a long time, but you still need to know how many unique values are required).
Oh, and terminology is critical in IT where similar terms may mean very different things. COBOL does not have "strings" as used in other languages -- that is, variables whose length varies at run time. COBOL allows, in very limited cases, variable length variables but unlike a Java string these variables are NOT required to be terminated with a \0 (or LOW-VALUE in COBOL terms).
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Robert Sample wrote:
... you get over 2 billion values before they start repeating. ...
Not necessarily. RANDOM returns a floating point value between 0 and 1. It is not stated in Enterprise COBOL for z/OS V4.2 Language Reference if the number is “normalized,” or “unnormalized,” or if it returns a 32 bit or 64 bit number. If it returns a 32 bit number, which seems most likely, it has a 1 bit sign, a 7 bit exponent, and a 24 bit value. Don't worry about this “normalized” or “unnormalized” business – that's just computer number geek talk, though the difference might affect scaling the number to the character set. What's important is 24 bits, which means 2^24 unique values. This is a large number, but it is much less than the 2 billion Mr. Sample innocently talked about.
The next issue is the character set. Lower case, upper case, numbers, and “national characters” is a fairly large set, but I think some characters should be excluded: 0 and 1 (the numbers), O (the upper case letter), o (the lower case character), I (the upper case character), and l (the lower case character) are my suggestions. It is all too easy to misread 0 and O, and l and 1. Heck, 55 years ago I learned to type on a typewriter where the typist was expected to use l, not 1!
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
Quote:
If it returns a 32 bit number, which seems most likely, it has a 1 bit sign, a 7 bit exponent, and a 24 bit value. Don't worry about this “normalized” or “unnormalized” business – that's just computer number geek talk, though the difference might affect scaling the number to the character set. What's important is 24 bits, which means 2^24 unique values. This is a large number, but it is much less than the 2 billion Mr. Sample innocently talked about.
From ther Enterprise COBOL Language Reference version 6.1 manual:
Quote:
argument-1
If argument-1is specified, it must be zero or a positive integer. However, only values in the range from zero up to and including 2,147,483,645 yield
a distinct sequence of pseudorandom numbers.
If a subsequent reference specifies argument-1, a new sequence of pseudorandom numbers is started.
You can use over 2 billion starting seeds -- hence you can have over 2 billion random values.
And the 31 bits all matter -- unless you consider 1.234567 times 10 to the 30th power to be the same value as 1.234567 times 10 to the minus 63rd power. Yes, the mantissa's 24 bits will be the same but the exponent's 7 bits will give you a different value for the number.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Unfortunately, I only have access to Enterprise COBOL for z/OS V4.2 Language Reference. The first sentence for RANDOM says,
Quote:
The RANDOM function returns a numeric value that is a pseudorandom number from a rectangular distribution.
It says nothing about how the 2^31 values in the integer sequence are mapped to the 2^24 values in the 32 bit floating point number. By definition, there will be repeats. If the 31 bits are not mapped properly, IBM's claim of a “rectanglar distribution” is pure horse s***. I can state with confidence that unless the floating point value is normalized the exponent will always be X'40'.
Since I don't do Cobol, I have no way to test anything, both to test claims about the distribution or to determine if the returned value is normalized.
Unfortunately, fine details about number theory are out of my league, so I better quit.
I don't want to disturb the high level talks but I like Mr. Woodger's idea.
I am also interested in knowing from TS that why the password is not allowed to be repeatable even after 1 million or billion values.
In general, if I can relate it to current web world, the user ids are unique and they are not allowed to have even a single duplicate. But I have never seen anywhere that there is any duplicate restriction on passwords.
Moreover, the system generated passwords have a limited lifespan and they are to be changed by the end user within certain period of time (say a month). So, a password which was generated a month ago should have been expired and we could reuse that value now.
In my views, it should not be an issue if the password is repeated (with a probability of 1 in a million or a billion).
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
The Enterprise COBOL RANDOM intrinsic function is an interesting function. It returns COMP-1 or COMP-2 (short floating point or long floating point) values. The long floating point values are NOT the same as the short floating point values; sometimes there is a difference of several digits in the last place of the short floating point value, compared to the same number of digits of the long floating point.
Using a seed value of zero and short floating point values (32-bit), the sequence generated a duplicate in the 18,823,902nd value in the sequence, running on a 5.1.1 compiler. To generate a full non-repeating sequence appears to require a 64-bit (long floating point) variable to hold the result. This duplicate took 13.2 seconds of CPU and 1.4 minutes elapsed time to find. Using 18823902 as the seed value, the first duplicate occurred at call 44,221,983 to RANDOM; this took 32 seconds of CPU time and 3.1 minutes elapsed.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
ARITH(EXTEND) generally affects precision of floating-point results from numeric intrinsic functions. I don't know if it affects RANDOM. Without EXTEND for other functions, there is only precision to 15 digits.
When researched online I could find that there's only Random generation for numeric formats.
so it just a matter of clubbing other characters and special characters, right? So what and where is the problem? btw what is the Database that you use at your site? any sql will help you to get what you want with far less complications.
Quote:
random password should be geneated everytime when the module is called and should be not be the same of any of previous calls.
Then you got to save the password for that user somewhere as encrypted, if you wanted to be 100% assured.
Quote:
I am also interested in knowing from TS that why the password is not allowed to be repeatable even after 1 million or billion values.
The expected answer from TS would be 'That's the requirement/told by my lead/Business wants that way'
