When encrypting the user password to store it in my database using AES-CBC, do I need to use a Key, an IV and a Salt? Whatever I need to use, how would they be used exactly?
The IV is used to initialize the first 16 byte matrix of the AES-CBC encryption scheme. It is XORed with the first 16 byte of the message. This means that, if the IV is constant, the same message will always output the same ciphertext. On the other hand, if the IV is different on each encryption run of the same message, because of the XORing of the IV with the first block, the ciphertext will always be different, since the result of the XOR will be different. IV is an inherent part of AES-CBC, and you will always have to use an IV, the choice is whether this IV is constant or not.
The Salt is a random message that you prepend to the real message so that on every encoding of the real message, you are actually encoding a different looking message (salt + real message) which will result in a different ciphertext. This is normally used for hashing algorithms, in order to get a different hash on each run of hashing of the same message.
You do not need to use a salt with AES-CBC, because the IV is already having the effect that the salt is designed to have. But if you want to use a salt, you can, and here is what would happen. Say you had a 16 byte salt, it would be prepended to your message, so you would have (salt + message) as the input to be encrypted by AES-CBC. Being 16 byte, your salt would fit in the first block of AES-CBC, it would XORed with the IV and as a result you would have (salt XOR iv). This result of (salt XOR iv) would then be used as the IV for the second block, which in this case, would be the 16 first byte of the real message.
Therefore, in the case of AES-CBC, using a salt only has the effect of an extra processing on top of your IV. If your IV is constant, the salt will XOR with it, resulting in a new IV to the second block that is different for each run of the encryption, even though the IV is constant.
So in conclusion, you are better of just using a random IV and not using a salt at all. Or use a constant IV and have a random salt (but watch out for this, go see #2 below for details). Both of these will have the same effect, which is to generate a different ciphertext on each encryption run of the same message.
1) The random IV I am passing to AES will have the effect that no two "mypass" gives the same ciphertext. Doesn't this make the salting redundant, because the point of the salt is to prevent two ciphertext of the "mypass" to be identical?
Yes it does. The IV and the salt effectively have the same effect, and help protect against the same attacks. Do note that, for the salt to have the same effect, proper thought in it's implementation must be considered, see #2 below for more details.
2) Inversely, could it be that the IV is redundant, and I could just pass in the zero IV or a constant IV since I am salting my passwords?
Not so fast. A lot of things must be put together properly for this to be true. Depending on the mode of AES, it might not always be true that the salting will result in the desired behaviour. Your salt length and the way you concatenate it with your message must also be right, appending could lead to problems for long passwords for example. Therefore, it is better to use the AES as it was thought of, that is, use a random IV and no salt.
3) Say the IV and the salt are not redundant, because somehow I read without really understanding that the IV is XORed but not the salt, making both useful. Is it enough for me to properly salt to simply prepend "mypass" with the salt?
The IV is XORed with the first block of AES in mode CBC to be encrypted. If you use a salt, the salt will be XORed with the IV in the first block, and this (IV xor Salt) will effectively become the IV of the second, which given a 16 byte salt, would be your actual message to be encrypted.
4) Am I somehow supposed to use the salt to derive the key that I will use for encrypting "mypass" with AES? Or am I doing it right by simply using a hardcoded key?
You shouldn't ever derive the key from the salt. The salt is not secret, and therefore, if you were to do that, the key would be easily found from the non secret salt. I was getting this confused with password based encryption, where you use a key derivation function to derive the key from a secret password.
5) What am I supposed to store in my database? Should the salt, the iv and the ciphertext all be stored in individual columns, or should they be somehow combined together, if so, is simple concatenation enough, or they must be combined with a special function?
From what I understood, this doesn't matter, as long as you know how to retrieve them. You can either use different column, or combine them together in one somehow.
6) Am I completely wrong and if so, what should I do instead?
Basically, I am using AES-CBC as a hashing function. Where normally the 256 bit key of AES means it is very hard to brute force, this bypasses that because here you can brute force the combination of the message, since the message is a password, chances are it's a lot shorter than 256 bits to brute force.
The other issue is that, being a symmetric algorithms, if a hacker compromises the server, and gets the key, he does not even need to brute force, dictionary attack, rainbow table, or anything else, he can just decrypt all passwords.
