[Melbourne-pm] Data::Token

Scott Penrose scottp at dd.com.au
Thu May 29 03:50:34 PDT 2008


> At that stage they can mint new tokens and abuse your services at  
> will.

You are no longer talking about tokens. Tokens are unpredictable  
numbers used for things like authentication and session tracking. They  
must be stored. What you are talking about is encrypting cookies, or  
encoding other data into the data back. What we want here is just an  
id that if someone tries say 100,000 attempts they would fail.

As for your entropy comments you are repeating what I said. Which is  
that the MD5/SHA1 is just a way of hiding the secret.

Again, look at every implementation on the net from CGI::Session to  
PHP - they pretty much all use

md5_hex(time, rand(time));

Now I agree, that is predictable, so we fix the randomness and a more  
unique key. But using SHA1 instead of MD5 does not provide any greater  
security for tokens - except that they are just longer.  But I think I  
will use it anyway just to make it a little safer.

> Hrm.  Even with token recording that means they could potentially  
> abuse
> your service by speculatively generating tokens and then submitting
> input in the hope that a genuine matching token will be generated.

Sorry to ask this Danial, but have you read any of my previous  
replies. This has all been discussed and pointed out. Any token scheme  
in the world suffers from the above. Sure you can keep making the  
space bigger and harder to hit, but in the end you really must push  
back on failed lookups. The easiest way to do this is as old as  
password entry, and that is just to add more and more delay. Remember  
there is no data in this token - it is just a pointer to the local data.

> Security is relative: it would be much easier for me to predict the
> Apache::Session session ID value than your Data::Token value.

Yeah and Apache::Session (also same as Apache::AuthCookie) is used for  
Authentication.

> It is almost certainly easier to find some other security hole,  
> though,
> than to brute force that.  Social engineering, paying pennies per spam
> to humans in inexpensive locations, and other technical threats are  
> much
> more profitable than hacking cryptography today.

Sounds like you are arguing in circles :-)

>
>> Some people raise in threads that you should use SHA1 and in each  
>> case
>> it is said not to be required.
>
> Well, I just read checked the code for Apache::AuthCookie to make sure
> it is insecure, and it is vulnerable to exactly the risk here:

Yeah it seems just about everything is using at best a process ID +  
time + rand(time) - take the MD5 - not great.

> It authenticates the values in the cookie with a secret, where the
> secret is absolutely vulnerable to the generation of collisions.

Yeah. So what we are discussing here is great. We are making a better  
token generator, then we will encourage Apache::AuthCookie,  
CGI::Session and Apache::Session to use it.

>> 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.
>>
>> My gut is now telling me (2). If it is not then almost every single
>> site on the internet is now vulnerable.
>
> The answer is kind of 3: it is really a problem, with a caveat, and we
> are absolutely not the first people to solve it.[3]

:-)

What I really need to do now is capture this discussion into my docs  
so future people can understand the reason. I might need some help,  
especially from you Daniel and Paul because I didn't attend those  
lectures :-) so I may miss something important.

ITMT I think it is worth adding SHA1 and better Random secret  
generators as discussed. That means the ID is 160 characters though,  
but I still think that is reasonable.

Thanks

Scott



More information about the Melbourne-pm mailing list