scottp at dd.com.au
Sun Jun 1 03:08:55 PDT 2008
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
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
> 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
>> 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
>>> 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
>>> (Their analytical attack was reported to take only one hour on an
>>> 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
>>> 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
>>> than you could otherwise. I think in general, using md5 for
>>> 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
>> 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
>> 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 on day, and having the module cope, is probably a good
>>  If breaking CAPTCHA images is economically viable then stealing
>> sessions by brute-force (or worse) attacks on the token
>> 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
> Melbourne-pm mailing list
> Melbourne-pm at pm.org
More information about the Melbourne-pm