Re: Good random number source in oracle

Looks good. I'm not a mathematician, so no guarantees!

If memory serves a random function produces a fixed set of numbers, the series being dependant on your seed. According to the Oracle documentation the seed is a BINARY_INTEGER, which is 2^31. At our 100 tests / second you need approximately 250 days to compute all possiblities.

What you've got is a function which is a whole order of magnitude more complex than the previous one. If you change your password every month, you'd be fairly safe.

"Jim Kennedy" <kennedy-family_at_home.com> wrote in message news:WLzF6.57211$xN4.4107799_at_news1.sttls1.wa.home.com...
> Why not keep the last random number around and use it as a seed for the
> next one? Or generate a oid and use a hash to get a number from that
 (some
> reasonably large prime) and use that as the seed for the random number?
> Jim
>
> "Ian Ledzion" <ian.ledzion_at_lgxbow.com> wrote in message
> news:9c605c$604$1_at_rex.ip-plus.net...
> > I quote "you can use the low end of the systdate squared and then
 modified
> > further". By low end I assumed that you mean taking the last set of
 digits.
> >
> > However, let's look at what happens if you take the part of sysdate
 after
> > the
> > decimal:
> >
> > 1) Assume you are taking SYSDATE to the millisecond, and are testing 100
> > possibilities / second.
> >
> > 2) It would it would take you 10 days to check all the available
> > possibilities. If start with the most likely times to change your
 password,
> > you can get a match faster.
> >
> > 3) Because you are testing a linear set of values, you can break the
 work
> > down over several machines, each investigating a subset of
 possibilities.
> > And because you are testing a fixed algorithm, you can store the
 possible
> > results in a table, and have them available for analysis later. At 1000
> > possiblities per second the total is 86.4M lines in the table, which is
> > easily within the Oracle range.
> >
> > Of course this assumes that someone really wants to get into your system
 and
> > is willing to commit the resources to crack your passwords in the first
> > place.
> >
> > PS Check out www.random.org for a discussion on random number
 generators.
> >
> > "Steve Long" <steven.long_at_erols.com> wrote in message
> > news:9c4fo5$8s7$1_at_bob.news.rcn.net...
> > > why are you assuming truncation? try reading the post in its entirety
 and
> > > without reading into it.
> > >
> > > "Ian Ledzion" <ian.ledzion_at_lgxbow.com> wrote in message
> > > news:9c3ppp$fp5$1_at_rex.ip-plus.net...
> > > > Using milliseconds would mean that a cracker just has to run through
 1000
> > > > possible permutations. Squaring the number would still mean 1000
> > > > permutations. In my view true randomness cannot exist withing a
 computer
 as
> > > > the systems are rule-based.
> > > >
> > > > A thought: try downloading files from SETI_at_home and sequences out of
 that,
> > > > as cosmic background noise *is* random, unless you've had the
 misfortune
 to
> > > > land on an ETI signal...
> > > >
> > > > "Steve Long" <steven.long_at_erols.com> wrote in message
> > > > news:9c1pv3$2au$1_at_bob.news.rcn.net...
> > > > > if you are using sysdate, recall that sysdate gets down to
> > > > > milliseconds...what is the likelyhood that anyone would know the
 precise
> > > > > value of time wrt milliseconds when the function actually received
 a
 value
> > > > > from the system clock? you can use the low end of the systdate
 squared
 and
> > > > > then modified further...etc etc
> > > > >
> > > > > "Peter J. Holzer" <hjp_at_enkur.wsr.ac.at> wrote in message
> > > > > news:slrn9e8iid.g2j.hjp_at_enkur.wsr.ac.at...
> > > > > > I have a stored procedure which generates random passwords.
 Currently
> > > > > > dbms_random.initialize is called with a value computed from
 sysdate.
> > > > > > Of course this isn't very random, so if somebody knows the
 algorithm
 and
> > > > > > the (approximate) time when a password was created, he can
 easily
> > > > > > compute the password. So I am looking for values which can be
 used
 as
> > > > > > "real" random number sources, I.e. values which change often and
 cannot
> > > > > > be guessed with sufficient accuracy from the outside. Things
 like
 number
> > > > > > of sessions, bytes read or written since last startup, etc.
> > > > > >
> > > > > > Any suggestions? (Apart from using dbms_pipe to call a script
 which
> > > > > > reads /dev/random - I am aware of that possibility).
> > > > > >
> > > > > > Also I am interested in the internal workings of the dbms_random
 package
> > > > > > (what kind of RNG it uses, etc.) Any pointers would be
 appreciated.
> > > > > >
> > > > > > hp
> > > > > >
> > > > > > --
> > > > > > _ | Peter J. Holzer | It's nice to fix problems by
 accident.
> > > > > > |_|_) | Sysadmin WSR / LUGA | -- Theo de Raadt
> > > > > > | | | hjp_at_wsr.ac.at | <deraadt_at_CVS.OPENBSD.ORG>
> > > > > > __/ | http://www.hjp.at/ | on bugtraq 2001-03-19
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
>
>
Received on Wed Apr 25 2001 - 08:33:28 CDT