3 ms·

Encryption is some funny stuff. I worked on a team that implemented SSO between an ASP.NET app and a PHP app. We used AES with a shared key and IV. That was it.

Encryption is some funny stuff. I worked on a team that implemented SSO between an ASP.NET app and a PHP app. We used AES with a shared key and IV. That was it. We just shoved the encrypted user token and timestamp into a domain cookie. But I guess we should have also signed the encrypted value to know that we generated it? What's the process to break this scheme? 1) Know what type of value is being encrypted: email, username, tokenid 2) Gather several pairs of usernames/encrypted usernames 3) Use some brute force method to uncover the key and IV 4) generated fake cookies since you know the key/IV

tptacek 15y ago
It's trivial to figure out what encryption scheme† is being used for a cookie or HTTP parameter as long as any portion of the plaintext being encrypted is influenced by something an attacker can control directly or indirectly. If you're not authenticating your ciphertext, you might as well not encrypt it; attackers can rewrite the plaintext, if not outright decrypt it (the adaptive chosen plaintext attacks on AES block modes all rely on messages not being authenticated). I'd enjoy talking more about the methods to break this stuff but am concerned that HN will read that comment as "well then we just need to stop those attacks and then we're safe". I have roughly 5 years of experience on HN to back that concern up. :) † (At least, with enough specificity to attack it.)
- euroclydon 15y ago
  Thanks. I Googled Adaptive Chosen Plaintext Attacks, and it seems to me that the statement, "attackers can rewrite the plaintext" needs to be qualified with, "given liberal access to the encrypting mechanism", which I guess means free access to create new accounts in an SSO situation (or access to some other web-method that used the same encryption).
  - tptacek 15y ago
    "Chosen plaintext" means that the cipher can't tell if what it has decrypted was what the original authentic encryptor encrypted. "Adaptive" means that the attacker gets repeated attempts to break the same piece of ciphertext. The canonical example of an adaptive chosen plaintext attack is the AES CBC padding oracle, but there are multiple others.

tptacek 15y ago

It's trivial to figure out what encryption scheme† is being used for a cookie or HTTP parameter as long as any portion of the plaintext being encrypted is influenced by something an attacker can control directly or indirectly. If you're not authenticating your ciphertext, you might as well not encrypt it; attackers can rewrite the plaintext, if not outright decrypt it (the adaptive chosen plaintext attacks on AES block modes all rely on messages not being authenticated). I'd enjoy talking more about the methods to break this stuff but am concerned that HN will read that comment as "well then we just need to stop those attacks and then we're safe". I have roughly 5 years of experience on HN to back that concern up. :) † (At least, with enough specificity to attack it.)

euroclydon 15y ago
Thanks. I Googled Adaptive Chosen Plaintext Attacks, and it seems to me that the statement, "attackers can rewrite the plaintext" needs to be qualified with, "given liberal access to the encrypting mechanism", which I guess means free access to create new accounts in an SSO situation (or access to some other web-method that used the same encryption).
- tptacek 15y ago
  "Chosen plaintext" means that the cipher can't tell if what it has decrypted was what the original authentic encryptor encrypted. "Adaptive" means that the attacker gets repeated attempts to break the same piece of ciphertext. The canonical example of an adaptive chosen plaintext attack is the AES CBC padding oracle, but there are multiple others.