[Melbourne-pm] Data::Token

Tim Hogard thogard at abnormal.com
Fri May 30 22:11:43 PDT 2008


I think the real problem is everyone is missing the point of tokens.

They are a risk mitigation device which means the question
becomes "what is the risk?"

I don't care if your using sha-1, sha-2, md5, md4 md1, crypt or crc
as none of them change the security of the token, they only change
the level of risk.

Key aspects of token are:
1) they must appear random (as in test 100,000 of them for randomness)
2) they must not be guessable (this bit is hard)
3) there must be a process in place to lock out users who attempt
to offer bad tokens.

Number 3 is the key.  If I can give out tokens that use a crc-16
as a hash, then I can offer one of 65,536 random numbers a as hash
to your system and will have a 0.00152541338703% chance of getting
in, if my other are ok.  If your system lets me send and average
of 32,000 hashs and then lets me in, you have a major problem.

Another issue you need to be concerned with is looking at the
one to many relationship the other way around.  Assume your token
ends up being a 4 digit pin line number.  It would take an
average of 5,000 guesses to get your pin number but if I was
guessing 0001 today and 0002 at for many uses at once, that
may change the game.  Think about hijacking a grocery stoes
pin pad system and just trying 0001 for everyone the first day
and 0002 the next and so on...  If they get 5,000 customers,
how many vaild pins will you have by the end of the month?

Now consider that problem in the DDOS coordinated many to many
attack... each of a million host is offering 3 bad tokens to your
system.  What are the odds then?  The solution is the user needs
to hand you a token and other id with every transaction.

Even if your hitting bank high value accounts, what is the cost
risk if a valid token is hit?  Once you figure in costs of insurance,
odds of reversing transactions and time wasted, it doesn't justify
the level of hashes typicaly used from an actuarial point of view
and the only reason its so secure is that big number crypto is
cheap.

If your token system doesn't have good odds of keeping people out
if its hash just mirrors the input data, you need to find a better
way.

-tim

> 
> Jacinta Richardson <jarich at perltraining.com.au> writes:
> > Scott Penrose wrote:
> >
> >> So the question is:
> >> 
> >> 1) Am I missing the threads on the net
> >> 2) Are we jumping to the wrong conclusion because we are mixing  
> >> document signature faking with unpredictability
> >> 3) Is this really a problem and we are the first to really solve it.
> >
> > I think it's 3 in so far that many of these modules were written
> > before 17th August 2004 (which is when Xiaoyun Wang,Dengguo Feng,
> > Xuejia Lai, and Hongbo Yu announced collisions for the full MD5 space
> > (Their analytical attack was reported to take only one hour on an IBM
> > p690 cluster.)).  Prior to this, the general assumption seemed to be
> > that engineering a collision would be really hard, and finding a
> > collision by accident would be next to impossible.
> >
> > Since not everyone keeps up with cryptography news, people continue to
> > use md5 despite its issues.  This is not necessarily because it's a
> > good idea.  It may even be as simple as when people think of hashing
> > algorithms the first one that comes to mind is md5.
> >
> > I expect that for the purposes of generating tokens, particularly with
> > the use of a salt, that these issues aren't really a problem.
> > However, if you do so you are choosing to provide a less secure token
> > than you could otherwise.  I think in general, using md5 for anything
> > to do with security or with anything which might even be vaguely
> > connected with the idea of security, is looking like a bad idea.
> 
> Mmmm.  I am still trying to work out how to respond to the documentation
> Scott wrote, but my general feeling is that these tokens *are* used in a
> security sensitive context, and that token forgery is a genuine risk.
> 
> As I said previously, though, it probably isn't a significant risk
> compared to other threats to your deployment: breaking an MD5 session
> token hash isn't (yet) an economically viable way for most attackers to
> abuse available services.
> 
> On that basis the continued use of (compromised) MD5 or (soon to be
> compromised) SHA1 for the tokens is probably not sufficiently worrying
> to have to rush into changing them... yet.
> 
> 
> Like Jacinta, I also expect that Data::Token will be used in security
> related areas -- Apache::AuthCookie, for example -- even if the
> documentation *explicitly* states that it isn't suitable.
> 
> On that basis planning for MD5 and SHA1 cracking being economically
> viable[1] on day, and having the module cope, is probably a good move.
> 
> Regards,
>         Daniel
> 
> Footnotes: 
> [1]  If breaking CAPTCHA images is economically viable then stealing
>      sessions by brute-force (or worse) attacks on the token identifying
>      them is going to happen one of these days.  One resource the
>      attackers have in spades is CPU time.
> 
> _______________________________________________
> Melbourne-pm mailing list
> Melbourne-pm at pm.org
> http://mail.pm.org/mailman/listinfo/melbourne-pm
> 



More information about the Melbourne-pm mailing list