[Melbourne-pm] Data::Token

[Daniel Pittman]

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.