Understanding padding oracles - is an attack plausible in my scenario?

Question

I have a scheme that, long story short, uses AES in CBC mode to encrypt third-party credentials for user accounts with a password-derived key. It's been mentioned that the use of CBC mode is a vulnerability because it is susceptible to "padding oracle attacks"; the cipher, after being initialized by the legitimate user with the proper key/IV, can be used by an attacker to execute a chosen-ciphertext attack to recover the plaintext without ever discovering the key.

The question is, do I actually have to worry about this type of attack given the way my system uses the cipher, specifically the fact that the cipher instance is only in existence for some seconds before its internal state is erased and it goes out of scope?

Perhaps more background is necessary. The basic scheme is that the user enters their username and password. The password is "stretched" by hashing it with SHA-512, and then that digest is split in half; one side is BCrypted for password verification by the server, the other half is the AES key used to decrypt the user credentials retrieved from the server.

So, the AES cipher isn't being used to maintain an open secure channel with a remote party; it's created, initialized, does its job on one message, and is then cleaned, disposed and garbage collected. This takes less than a second. To my way of thinking, this would make a POA infeasible, because the attacker would need an open, initialized instance of the cipher to bounce his chosen ciphertexts off of, which would take far longer than the second or two that the cipher instance is doing its job. Further, the cipher instance isn't being exposed to anyone outside the computer; if an attacker's in the computer, he has the user's password plain and simple, but an attacker can't even make a network request of the client computer that would involve the cipher in any way.

There are much easier attacks on this scheme as implemented, perhaps the simplest being that the AES key is derived rather simply from a user-chosen password (and we know how much entropy those have).

So, should I worry about the vulnerability of CBC mode to padding oracle attacks in my specific circumstance, or am I reasonably safe from that particular vector and should concentrate on other areas of weakness?

Answer 1

If I understand your scenario correctly, padding oracle attacks are probably not a massive concern, but not for the reasons you seem to believe. Padding oracle attacks have nothing to do with maintained open channels, lack of garbage collection, or time the cipher is kept in memory.

A padding oracle attack requires two things: a ciphertext whose contents you wish to read, and a "padding oracle": more or less, a way to tell if a ciphertext that you've forged passed through the decryption algorithm successfully. If you never decrypting information directly received from users, then you are probably not significantly vulnerable. If users can supply ciphertexts to be decrypted, you are probably vulnerable. If an attacker can write to your database through something like SQL injection, you retrieve and decrypt ciphertexts from the database, and your service can be instructed to decrypt something stored in the database, you have bigger fish to fry, but you are probably also vulnerable to padding oracle attacks.

Long story short: if it is at all plausible that an attacker can feed you ciphertexts to decrypt, you should authenticate ciphertexts. Consider also if the contents of your ciphertexts should remain secure even in the face of other exploits. Since it's very hard to reason about what a motivated attacker might be able to do if given access to your system, you should absolutely default to using an AEAD mode unless you have a overwhelmingly compelling reason not to.

With that out of the way, you should highly reconsider how you handle passwords and encryption keys. SHA-512 by itself is not "key stretching", and the left half of SHA-512 plus bcrypt for digests, plus the right half for keys is tantamount to sprinkling cryptography around like magic pixie dust, expecting it to magick away security concerns.

For password digests, you should use BCrypt. SHA-512 plus BCrypt is probably not worse, per se, but it's unnecessary, and gains you nothing.

Your key derivation, however, is extraordinarily weak. SHA-512 is fast, and an attacker can trivially brute force his way through common passwords and use trial decryption to expose ciphertexts of users with weak passwords. You should use an actual key-stretching function such as PBKDF2. For each user, generate a cryptographically random 128-bit value. Compute the PBKDF2 of the user's password using this value as the salt, SHA-256 as the PRF parameter, an output length corresponding to the key length of your encryption algorithm (16 bytes for AES-128, 32 bytes for AES-256), and a number of iterations calibrated to take around 0.1s on your server hardware. Store the number of iterations and the salt. The output of this function should be used as your encryption key.

And, of course, don't overlook generating unique IVs for each encryption with a given key.