Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: droby10 (droby10onebox.com)
Date: Sun Mar 10 2002 - 09:49:52 CST
after watching this thread for a while, i thought i'd drop my change
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
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
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
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.
-- droby10onebox.com - email