What is the right way to implement Keyed Password Hashing?

acthota
  • What is the right way to implement Keyed Password Hashing? acthota

    As mentioned in this wonderful link, the way to get a PBKDF2 Hash of a user given password given

    1. a password (of course),
    2. a salt (generated Cryptographically Secure Random Number Generator.
    3. iteration count (chosen high enough to be secure while balancing your application's usability tolerance)
    4. Hash size (length of the hash to be computed)

    /** * Computes the PBKDF2 hash of a password. * * @param password the password to hash. * @param salt the salt * @param iterations the iteration count (slowness factor) * @param bytes the length of the hash to compute in bytes * @return the PBDKF2 hash of the password */ private static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int bytes) throws NoSuchAlgorithmException, InvalidKeySpecException { PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, bytes * 8); SecretKeyFactory skf = SecretKeyFactory.getInstance(PBKDF2_ALGORITHM); return skf.generateSecret(spec).getEncoded(); } Now my question is :

    How should the Keyed hashing for the password be implemented ?

    Based on my reading, this is my line of thinking. Please validate.

    • Keep the salt argument to the method pbkdf2 (in the code snippet above) secret (obtain it from a highly secure HSM as opposed to storing it in the database alongside the password hash when needed).

    • Since the salt is meant to be random (to protect them from the rainbow tables / dictionary attacks), the salt provided to the pbkdf2 should be a concatenation of the key and a random bytes generated from a CSPRNG.

      [salt] = [secret key] + [random bytes from a CSPRNG]

    Finally, I will dare to ask a silly question (will dare to ask since high iteration count is posing a serious usability issue since we need to authenticate for 90% of the use cases in our application)

    Can we reduce the iteration count OR do without it since we have added an additional layer of security through the Keyed hashing ?

    P.S: I am aware of the value that slow hashing algorithms add by reducing the possibility of passwords getting compromised through brute force attacks. Just want the experts to comment on the security value addition through Keyed Hashing VS having a Slow Hashing algorithm with non-secret salt.

Tags
passwords hash hmac pbkdf2
Related questions and answers
  • I was going through (https://crackstation.net/hashing-security.htm) about doing password hashing / storage the right way. I understood most of it but i still have some questions and doubts which are unclear. I store the password hash (generated with the password and a random salt) along with the salt on the server. How is this linked to a particular user exactly ? So, if my database gets... how is the secret key tracked ? And again we have the same scenario as above if the database is compromised . how does password sending from client to server work exactly. I understand the server

  • of prepending the constant PBKDF2_ITERATIONS to createHash(char[] password) method? Is my understanding of the whole process correct? Here is the link to my source code - which value should I save as hash...Context: I am using this tutorial and trying to understand and implement salted password hashing using Java. After spending some time on this topic, I figured out that the basic idea is to: Convert the password string to a character array. Generate a random salt using SecureRandom(or similar). Hash the password character array with a standard cryptographic hash function. Convert the salt

  • it to the smart card. The question is what is the best way to authenticate the token. Here is what I came up with: We create a unique symmetric key (K) and store it securely in the server and the smart...I need your advice on the security of this design. I have a scenario whereby a server application and a smart card application need to share a value e.g. 52, which has been encoded in a long... by deleting it from the S file (prevents replay attacks) It creates a message by concatenating the amount and the nonce i.e. m = v || n It creates an enciphered text (e1) i.e. e1 = H(K,m) where H = "HMAC-SHA-1

  • (password + salt); byte[] hash = sha512.ComputeHash(hashInput); return Convert.ToBase64String(hash); } public string GenerateSimpleSalt(int Size = 64) { var alphaSet...We are currently using HMACSHA512 in .net, with a 128Char (64byte) validation key The salt is 64 char randomly generated string. We allocated 2048 length on the database for the hashed base64 string... Rfc2898DeriveBytes(password, salt,<Use a number around 50K>); // approx 300msecs on workstation byte[] hash = deriver2898.GetBytes(20); // return

  • I'm afraid I'll have tomatoes thrown at me for asking this old question, but here goes. After reading that cooking up your own password hash out of existing hashing functions is dangerous over... to re-hash standardly hashed passwords into these wacky hashes as they see fit and weaken the hash? I don't buy it. Second argument: Kerckoffs's principle: A cryptosystem should be secure even... can see) advantages to using a "wacky" hash over a normal hash: Sure, your system should be secure if the attacker has the source code, but it's a very likely possibility that your attacker wont have

  • multi-byte sequences. So any characters in this range would appear in UTF-8 as a ? (i.e. an invalid character) due to not seeing any "leading byte". I think this solves my question for the other.... I feel like I can rest assured that only usability is affected, but not security in these specific cases. ...Short Question: Question: Could any security vulnerabilities arise if a server runs htmlentities as UTF-8 but the client views the results as ISO-8859-1? Assumption: No vulnerabilities exist when

  • , etc. See also Should a closed source website keep a secret key in its source?. Storing the secret in an HSM is impractical, since we cannot attach one to a virtual cloud server. See also Storage... the fundamental question, as noted in one of the comments: how would you protect the keystore password on the cloud? We are designing a SAAS web application in the AWS public cloud, which will have many end... requires an API secret key to access. This has essentially the same problem noted in the question above, with the keyserver API secret key being directly comparable to the keystore password: how

  • I've been reading about it. This article helped me a lot. But the more I read the more complicated it seems. For example: Is it better to use bcrypt, or PBKDF2, sha2 or something else for the salt? How do I add HMAC encryption passwords? Suppose I have to store passwords (all information, hashes, salt .... ) in a single file. I plan to do it this way: Obtain password from the end user. Create a salt. Create hash = SHA256(salt + password) and store salt together with hash in the file. But I am not sure how to improve it. I do not understand how to use HMAC Well the question is: What

  • I'm making an auth service so I've been looking for some good Java/Groovy implementations of password + salt hashing. I've found this article on crackstation along with a code example and decided...). One thing however kind of struck me. The result string is "[iterations]:[salt as hex]:[hash as hex]". Why are iterations added to the result? Wouldn't that be insecure? Wouldn't that be akin to giving away a piece of the key? Or am I just too paranoid. I have removed it, but I'm wondering why is it there? What is the purpose of showing that? In case the default number of iterations changes

Data information