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!

  • $\begingroup$ I just fixed a typo and some of the grammar issues. $\:$ Should "much interactions" $\hspace{1.74 in}$ be replaced with "many iterations"? $\;\;\;\;$ $\endgroup$
    – user991
    Mar 8, 2014 at 0:04
  • 1
    $\begingroup$ Many of your questions belong (and have been answered in) Security.SE. As a starter I'll point you to this brilliant answer by Thomas Pornin (which should be read untill memorized). The only thing I'm having an issue with is letting the users generate their own salts; you can use a user-contributed value combined (XORed maybe?) with your own random salt though. Don't use constants in it because there is no point in doing so. $\endgroup$
    – rath
    Mar 8, 2014 at 0:18

1 Answer 1


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}$)


  • || means to concatenate two strings
  • PBKDF2(str, length) means generate a hash of length 32 bytes from the string str
  • $\begingroup$ Thanks for your answer. PBKDF2-SHA512 means PBKDF2 using HMAC using SHA512 and not SHA512(PBKFD2(...)). $\endgroup$
    – user12399
    Mar 8, 2014 at 9:22
  • $\begingroup$ I can't generate any random salt/string, I can only drive it from the user's email and password. Read my EDIT. $\endgroup$
    – user12399
    Mar 8, 2014 at 9:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.