I'm building a tool which generates passwords by hashing a service name with a master key. PBKDF2 was primarily chosen due to availability in the Web Crypto API.

What would be a secure value for the output bit size? Base64 requires 180 bits to produce 30 character-long passwords, but is that tolerable from a cryptographic viewpoint?

  • $\begingroup$ Calculating password entropy? $\endgroup$ – kelalaka Dec 19 '18 at 17:27
  • 1
    $\begingroup$ Deterministic password generators have been done before. They have significant inherent flaws. $\endgroup$ – Future Security Dec 19 '18 at 17:51
  • $\begingroup$ 30 x 6 = 180 not 160 $\endgroup$ – dave_thompson_085 Dec 20 '18 at 3:19
  • $\begingroup$ I don't see why the flaws of deterministic password generators are subject to this question, neither can I understand the down votes. $\endgroup$ – R3turnz Dec 22 '18 at 8:25

It seems you are using a password based key derivation function (PBKDF2) to derive a password from information (the service name) and a key. That's kind of backwards, but given that there are often no Key Based Key Derivation Functions(KBKDFs) such as HKDF available, I'd say that it is acceptable practice. You might however use a single iteration, assuming that the master key has a suitable security strength of - for instance - 128 bits. Furthermore, you may also use a salt and store it next to the service name.

As Future Security has already indicated, deterministic password generators have significant drawbacks. For instance, it may be impossible to change the password for a service without changing the service name. Additional information still needs to be stored. Instead it is commonly much better to use a password manager that encrypts the database, e.g. using the master key.

That out of the way, let's return to the question. If the master key has less security than the generated password then the master key determines the strength of the entire scheme. If you generate a 160 bit value using PBKDF2 and you encode it using base 64 then the resulting password will simply have a security strength of 160 bits, given that the master key has a security strength of at least 160 bits. The way that binary values are encoded does not influence the strength at all.

Generally there is little reason to go over 128 bits of security for passwords; generating too large a value may lead to some (badly programmed) systems to reject the passwords. Beware that many systems require a specific form of password, and any password storage / derivation scheme should therefore be able to generate specific forms of passwords to protect the user against such bad practices.

| improve this answer | |
  • $\begingroup$ Thank you for the comprehensive answer! Did I understand you correctly? You recommend a bit length of 128 bits and only one iteration? As far as I understand, the count of iterations directly corresponds to the computing power required to brute-force the password. $\endgroup$ – R3turnz Dec 22 '18 at 8:32
  • 1
    $\begingroup$ You were saying that you are generating a password from a key. The reason why the iterations (the work factor) exists is to make it harder to find a key generated from a password. As long as the key is strong enough, 128 bits and upwards, no iterations are required. $\endgroup$ – Maarten Bodewes Dec 22 '18 at 13:59

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.