after watching this thread for a while, i thought i'd drop my change
in.

i don't have near the understanding as most on the specifics of the topic,
so hopefully i can get an ack/nack/rst on what i've gathered and compiled
so far.

i see the idealistic goal is to produce a unique value which can neither
be patterned, expected, nor _created_.

the issue is that no matter what we plug in-it's still a process (which
can be defined by all of those characteristics above that we're attempting
to avoid).

using this limitation we are required to plug-in a protected value (which
implies that the system in which that protected value is stored is secure).

another limitation comes in the form of usable and realistic address
space for creating and retrieving these unique values.

i've written a proof-of-concept class for what i think addresses most
of these concerns...i'm posting it for review. please realize that it's
proof-of-concept and that some features/expectations may not be met -
additionally i've not reviewed most of the owasp standards so i doubt
it will by any means, conform "as-is". and to question myself even further,
i've yet to do the statistical math on it...as i'm currently suffering
from brain-fry. if anyone else would like to, please feel free to do
so.

the url for the class can be located at http://droby10.addr.com/UID.java.

i'd be really appreciative of any analysis on possible attack processes
against such a token-generator assuming that all of the recommended usages
are in place. ( ie. random x0, proper token-gen parameter usage, etc.
)

thanks -

-- 
droby10onebox.com - email

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]