James Landis wrote:
More notes on Amit's remediation algorithm:
Putting all of the identifying information into the token weakens the
defense because the attacker can mount known plaintext attacks against
it.
Not precisely. First, the classic definition of "known plaintext
attacks" is that an attacker can observe both the plaintext and the
ciphertext, In our case, the attacker does see ciphertext, but he/she
does not exactly see the plaintext. Obviously the IP is known, and the
server time is known up to some granularity, but if (say) you use the
microsecond clock, then an attacker will have a hard time guessing the
*exact* plaintext.
I don't think known-plaintext attack should worry you if you use an
industrial strength encryption, but if you feel like hardening the
algorithm against this attack, you can always throw in a random number,
or a secret string as part of the plaintext, and discard it upon decryption.
Putting things in perspective, even if the attacker breaks the
encryption algorithm, they still have to know the IP address of the
target. However, a sufficiently clever attacker will simply create a
phishing scam which harvests IPs and creates custom URLs for each
victim. The algorithm will also be weakened against individually
targeted attacks because like you said, it does not protect users
which appear to come from the same IP to the Web server.
Even if the attacker knows the exact IP address of the victim, I don't
see how this helps much. A good encryption algorithm will withstand a
known plaintext attack. And since the attacker cannot fake TCP traffic
coming from the victim's IP (unless the attacker and victim go out to
the Internet from the same IP, or unless the attacker uses IP spoofing
techniques not suitable for our kind of attacks), I don't see how the
attacker can acquire a valid token for the attack.
Amit's solution is a tradeoff with maintaining state for the "unique
tokens" described by RSnake. Unique tokes or nonces are a more secure
solution but using them incurs the additional overhead of tracking the
nonces. Amit's algorithm has no tracking overhead.
Why are they secure? Please consider the attack scheme I described in
http://www.webappsec.org/lists/websecurity/archive/2007-01/msg00065.html
-Amit
