James Landis wrote:
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.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.
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