Hashing a derived key is not a security issue because cryptographic hashes are one way. There are two ways people could attack the derived key.
- Guess a password, process it using PBKDF2, SHA-512 hash the result and see if it matches
- Guess a derived key (128 to 256 bits), SHA-512 hash it and see if it matches
The amount of work performed per guess with method 2 is much lower, but the probability of being successful within n guesses is only n / 2128. Since the total amount of work is n times the work-per-guess, method 1 is always less work in practice. (Method 2 is never practical because brute forcing 128-bit or larger keys isn't currently possible.)
I estimate that typical "good" user chosen passwords have 30-40 bit strength. So you can expect them to be guessed within 240 guesses instead of 2128. You would only "break even" if PBKDF2 were made to cost 288 times SHA-512. No user, legitimate or not, would be able to login if that were the case. It would just take too long.
(Not that "breaking even" matters in practice. Method 2 is already out of reach for real world adversaries so it's a strategy that no one is going to bother with. People's passwords are the weakest link in the chain. Not an algorithm as reliable as SHA-512.)
Another issue makes it possible to bypass the second level of PBKDF2 brute-force protection. Hashing the derived key and comparing it to the stored hash is not the only way for a hacker to determine if they have the correct derived key.
If they have access to ciphertext, then they instead could perform trial decryption to get a good idea of whether or not they have the correct key. It's not even required to decrypt all the ciphertext. A few bytes should suffice.
Alternatively, they could use the message authentication algorithm. (Encryption without authentication is a really bad idea. You do use an authenticated-encryption mode, right?)
Any place where key material is derived from a user's password provides a potential pathway a hacker can use to verify whether a guessed password is correct. Using any one of these avenues gets the person trying to crack a password the same answer. so they are going to use whatever option is easiest.
This is another weakest link in the chain situation. Whether you use PBKDF2/SHA-512 or PBKDF2/PBKDF2, expect that your level of brute-force protection is only as strong as the first layer of PBKDF2.
PBKDF2/SHA-512 can actually be made stronger than PBKDF2/PBKDF2. If you have only one second to budget to verifying a password, then it is preferable to put nearly 100% of that one second into the first PBKDF2.
Using SHA-512 for the second-level check lets you do this because its run time will be near-instantaneous compared to PBKDF2. (But again, a 128-bit key (or stronger) is not brute-force-able because the actual cost of SHA-512 is non-zero and 2128 SHA-512 evaluations adds up.)
If you instead let the first layer of PBKDF2 run for 0.5 seconds then ran the second layer for 0.5 seconds, then you'd really only have half the brute force protection of what you could otherwise afford.