|
|
Posted by ast3r3x on 05/24/07 10:44
I guess I don't really understand then. I was under the impression
that it was the symmetric key because of section 2.3 in the article.
------------QUOTE------------
Fu's cookie protocol is vulnerable to replay attacks, which could be
launched in the following two steps. The first step is to steal a
cookie that a server issued to another client. An attacker may have
several ways to steal a cookie from someone else. For example, if a
client stores a cookie in his hard disk, an attacker may steal it
using Tro jans, worms, or viruses. An attacker may steal a cookie by
launching a Denning-Sacco Attack [3]. In such an attack, an attacker
first collects a large number of messages that are encrypted by the
same SSL session key, and then obtains the SSL session key using
various methods. In the second step of a replay attack, the attacker
initiates an SSL connection with the server and replays a stolen
cookie that has not yet expired. Consequently, the server incorrectly
authenticates the attacker as the spoofed client, and allows the
attacker to access the spoofed client's account.
To counter replay attacks, we propose to add the SSL session key into
the keyed hash message authentication code of a cookie, i.e., to use
HMAC(username|expiration name|data|session key, sk) as the keyed-hash
message authentication code of each cookie. Therefore, a cookie
becomes session specific. Even if an attacker steals a cookie, he
cannot successfully replay it since the session key is known only to a
legitimate client and the server that creates the cookie.
------------QUOTE------------
What I don't understand is how using the PHPSESSID would make it
anymore secure. You could still replay the cookies if you had physical
access to them, which I thought was what using the session key was
trying to prevent.
Navigation:
[Reply to this message]
|