1
$\begingroup$

Scenario:

  1. User gives password.
  2. A "password key" is derived from the password (e.g. by PBKDF2). A random salt is applied.
  3. The password key is hashed with a HMAC algorithm (e.g. HMAC-SHA256), with itself as the key.
  4. The salt and HMAC result are stored in database, for verification of the password (for further user logins).
  5. The password key is used to encrypt other data.

Question: Is it safe to apply step 3 in terms of: can the password key be (easily) determined because it is known that it is the message to be HMACed?

$\endgroup$
  • 2
    $\begingroup$ What problem are you trying to solve here? Chances are it is a standard problem that has readily available solutions for which you don't really need to try to invent something new. That said, I don't see any issues with step 3. $\endgroup$ – mikeazo Mar 3 '16 at 16:15
  • $\begingroup$ @mikeazo Could you elaborate on your opinion, if you please, possibly as an answer (so I could accept it)? $\endgroup$ – nix Mar 4 '16 at 8:29
  • 1
    $\begingroup$ I can do that if you can better clarify what problem you are trying to solve. $\endgroup$ – mikeazo Mar 4 '16 at 12:51
  • 1
    $\begingroup$ @mikeazo I'll try... I'm designing a system with user logins and encrypted user data, with a personal key for each user, which I (as the system admin) need not know. This key should be the password key, derived from the password as described above. Now for login I need to check the given password, before trying to decrypt user data. This is where the HMAC comes in (step 3). Now because the password key shall be used to encrypt data, it must not be determinable from the HMAC result (that's the question), because otherwise it would be possible to bypass the password guessing (or bruteforcing). $\endgroup$ – nix Mar 9 '16 at 15:35
0
$\begingroup$

Question: Is it safe to apply step 3 in terms of: can the password key be (easily) determined because it is known that it is the message to be hashed?

Yes, this should be fine, although you might as well use a constant as the message input when calculating the HMAC. Theoretically some implementation could be more lax with regard to side channel attacks about the message than the key, though I doubt that is an issue in practice.

Knowing the self-HMAC of the key will allow an attacker to easily verify their guessed passwords, but PBKDF2 will slow them down and anyway the speedup is not significant, compared to attempting to decrypt the data with the derived key.

(There are better alternatives to PBKDF2, like scrypt, argon2, bcrypt.)

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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