Set-Cookie中的TM/LM數值的定義
以下是Set-Cookie中參數TM及LM解釋，引用自Cookie Dethroning.::DEMYSTIFIED(http://www.infosecwriters.com/text_resources/pdf/CookieCorePartA.pdf)這份文章中的說明：
Here is an example of a Google cookie:
GPREF=ID=26b2149fe108b391:TM=1109736400:LM=1109736400:S=pbbDWyL8tVmJrIL
c
You can see that after "GPREF=", there are name-value pairs ID, TM, LM,
and S (separated by colons). In this case, our ID is 26b2149fe108b391.
This is a (hopefully) unique ID, and it is most likely generated
randomly. Google probably doesn't worry about "collisions" (two users
getting the same ID) because this is a 16-digit hexadecimal number, and
there are 16^16 = 18446744073709551616 = 18.44674 x 10^18 possible IDs
that could be assigned. Even if everyone on the planet used Google, the
chance of collision would be very low. Google's cookie has an
expiration date of January 17, 2038. Essentially, unless you purposely
clear your cookies, format your hard drive, etc. this means it will be
with you for a very long time.
The TM value is a timestamp of the moment (to the second) that Google
generated your cookie. Here it is 1109736400, measured in seconds since
January 1, 1970, or March 1, 2005 at 10:06:40 PM (CST).
LM seems unimportant because it is a timestamp of when the user last
changed their preferences. Many other name-value pairs can appear, but
the only others that I have seen represent more preferences. Having the
unique ID means they are most definitely storing *something* on the
server side, but don't worry it's probably only analyzed in aggregate
unless you are one of Sergey's ex-girlfriends :-p.
Now, S is the most interesting value in the cookie. Some have
hypothesized that it is a checksum of some sort. It could be a hash,
for instance. In my experience, the signature only varies with
different ID and/or TM values. Thus, Google is assured that THEY
generated the cookie at a given time by doing a simple calculation of
the hash. But relying on a pure hash would be security through
obscurity, i.e. Google would basically be relying on the secrecy of the
hash function. Instead, I think that Google probably uses a digital
signature algorithm of some kind to generate it. So, maybe S stands for
signature. It appears that the signature is 16 characters long, casesensitive,
and alpha-numeric only, giving (10+26+26)^16 possibilities
or roughly the equivalent of a 93-bit hash (not incredibly strong by
today's standards, but definitely a good chunk of hash). I tried my
luck at guessing a hash function and mapping parts to base 62 numbers,
but I just don't think that they are stupid enough to do it that way.
Sucks for me, because I'm no Bruce Schneier when it comes to
cryptography. My instinct is that an attack against the signature would
be futile.
Here is an example of a Google cookie:
GPREF=ID=26b2149fe108b391:TM=1109736400:LM=1109736400:S=pbbDWyL8tVmJrIL
c
You can see that after "GPREF=", there are name-value pairs ID, TM, LM,
and S (separated by colons). In this case, our ID is 26b2149fe108b391.
This is a (hopefully) unique ID, and it is most likely generated
randomly. Google probably doesn't worry about "collisions" (two users
getting the same ID) because this is a 16-digit hexadecimal number, and
there are 16^16 = 18446744073709551616 = 18.44674 x 10^18 possible IDs
that could be assigned. Even if everyone on the planet used Google, the
chance of collision would be very low. Google's cookie has an
expiration date of January 17, 2038. Essentially, unless you purposely
clear your cookies, format your hard drive, etc. this means it will be
with you for a very long time.
The TM value is a timestamp of the moment (to the second) that Google
generated your cookie. Here it is 1109736400, measured in seconds since
January 1, 1970, or March 1, 2005 at 10:06:40 PM (CST).
LM seems unimportant because it is a timestamp of when the user last
changed their preferences. Many other name-value pairs can appear, but
the only others that I have seen represent more preferences. Having the
unique ID means they are most definitely storing *something* on the
server side, but don't worry it's probably only analyzed in aggregate
unless you are one of Sergey's ex-girlfriends :-p.
Now, S is the most interesting value in the cookie. Some have
hypothesized that it is a checksum of some sort. It could be a hash,
for instance. In my experience, the signature only varies with
different ID and/or TM values. Thus, Google is assured that THEY
generated the cookie at a given time by doing a simple calculation of
the hash. But relying on a pure hash would be security through
obscurity, i.e. Google would basically be relying on the secrecy of the
hash function. Instead, I think that Google probably uses a digital
signature algorithm of some kind to generate it. So, maybe S stands for
signature. It appears that the signature is 16 characters long, casesensitive,
and alpha-numeric only, giving (10+26+26)^16 possibilities
or roughly the equivalent of a 93-bit hash (not incredibly strong by
today's standards, but definitely a good chunk of hash). I tried my
luck at guessing a hash function and mapping parts to base 62 numbers,
but I just don't think that they are stupid enough to do it that way.
Sucks for me, because I'm no Bruce Schneier when it comes to
cryptography. My instinct is that an attack against the signature would
be futile.
Comments