To answer your question about the the salt and the PBKDF2: salt ensures that the hash of my password is different from someone else's, even if we use the same password (or I use the same password on another site). Thus, if someone has the hashes, and wants to attack the system, then need to attack each password independently (they can't just run a password dictionary through the PKDF2 (or SHA256 in this case - very bad choice)) and then compare the results against all of the password hashes. They have to start with the salt (different for each user), and then run each password guess through the algorithm. Much slower. Much better.

Which brings us to PBKDF2 instead of SHA256: SHA256 is designed to be fast. That's bad when hashing passwords, because it makes offline dictionary-based attacks faster. Password Derivation functions are designed to be slow. That makes logging on very slightly slower, but makes offline attacks much, much slower.

However, doing the encryption in Javascript is a fatal problem: At any time, they can update (or be forced to update) the javascript to send the server my password when I use it, and the only way I can protect myself from this is to audit the code, EVERY TIME I USE IT.

Why do you consider unsalted SHA-256 a bad choice here? If neither the password nor its hash are stored and the hash is merely used as a key for the CBC, I don't see how anyone could construct rainbow tables for that. Care to explain?

The point is that any salt, even a hard coded salt, would mean that an attacker would need to regenerate the rainbow tables using the known salt.

How are you going to guess the password given just the salt, not even the hash? Hell, even with the hash itself it's nowhere near easy.