[Melbourne-pm] Data::Token

[Scott Penrose]

Thanks Tim. This is what I have been trying to point out and you wrote  
it very well.

The MD5 collisions are not relevant to Tokens. however...

That being said however using SHA1 makes it a bigger space, and using  
Crypt::Random or similar improves the hard to emulate - so improves  
the level of risk.

Then as you pointed out, protecting against attempts is the only  
solution.

Scott

On 31/05/2008, at 3:11 PM, Tim Hogard wrote:

> 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
>>
>
> _______________________________________________
> Melbourne-pm mailing list
> Melbourne-pm at pm.org
> http://mail.pm.org/mailman/listinfo/melbourne-pm