Right usage of PBKDF2 and login system questions I'm developing the login part of my application and I was asking myself how to do it right. My application stores some users' data server-side that must be inaccessible from us, so all the content must be encrypted using AES-256 with a password derived from the user's login password and this key would never leave the user's device.
What I thought to implement is PBKDF2-SHA512 and use the first 32 bytes of output as the AES key of the user and the last 32 bytes as the hash to login.

My questions are:
How many interactions should I use given that my software will have to work on iPhone and Smartphones in general? (Note that I will force the user to use a password that is 8-char minimum in length, that has at least one uppercase char and a number)
What should I use as salt? I was thinking of using the username (that actually is the user's email address) combined with some string that uniquely identifies my application but... What's the best way to do so?
Is it useful to do it using a combination of crypto algorithm? For example making a little hash function based on AES so an attacker who has the ability to make custom hardware will have to implement more than one algorithm.
How should I save the login hash (the last 32 bytes of PBKDF2-SHA512) in the server's database? I think a simple salted hash (without stretching) would be enough given that the original password is already stretched client-side. If yes, should I use SHA-256 or SHA-512?

EDIT:
PBKDF2-SHA512 means PBKDF2 using HMAC using SHA512 (so it doesn't mean SHA512(PBKDF2).

I can't "generate" any random salt. All that I can do is to "derive" it from the login information. I thought something like HMAC-SHA512(email || password, str) where email || password is the string to be hashed and str is a string that uniquely identifies my application being used as HMAC Key. What do you thing about that? Is there a better way to to it?

Thank you!
You should not SHA512(PBKDF2(password)). Your AES encryption key and the password hash are correlated (which may be a vector of attack in the future). A better solution is:


Generate a secure random string $r_1$ of like 64 characters
Generate another secure random string $r_2$ of like 64 characters
Derive the AES key by PBKDF2($r_1$ || password, 32)
Get a password hash from login by PBKDF2($r_2$ || password, 128)


Due to the two distince random strings used as salts both, the AES key and the password hash are much harder to correlate. You can, if you want to make the derivation of the AES key/password hash harder, use multiple rounds:


Round 0: $x_0$ = password
Round 1: $x_1$ = PBKDF2(r1 || $x_0$)
Round 2: $x_2$ = PBKDF2(r1 || $x_1$) = PBKDF2(r1 || PBKDF2(r1 || password))
...
Round n: x = PBKDF2(r1 || $x_{n-1}$)


PS:


|| means to concatenate two strings
PBKDF2(str, length) means generate a hash of length 32 bytes from the string str