I'm working on an embedded systems project for school in which we need to store a password (or key, whatever). The idea is that this design should eventually be reducible to bare-metal hardware and manufactured on an extremely large scale. For that reason, every bit counts in terms of cost.

This system should also be highly secure. There will be password lockouts, retry delays, etc., but the size of the password (or key, there's no reason to expect that the key needs to be entered by a human) is of critical importance, as the project starts with single-factor authentication (MFA added later).


I simply want to allow the end user enough space (bits) to create a secure password. For instance: it costs me 6 cents for every additional 8 bits of a password. I decide to only spend the 6 cents and the user is allowed a 1 character password, which they can choose - bad news. By the same token I would like to avoid buying 800 bits for $6 if a 400-bit password for $3 would have sufficed. Are there official guidelines or SOP on password size and resistance to brute-force attacks?


2 Answers 2


Remember that entropy is an attribute of a password, but it is not the password itself. You need a consistent way of transforming a password into that amount of entropy. Normally, this is done through a hash function, such as SHA256. (For a less secure system than bits on a chip, where the bits may be exposed through hacking such as a database on a web server, it's common to use a special purpose password hashing function, such as PBKDF2.)

SHA256, by definition, produces 256 bits of output. Obviously, you don't want to store 256 bits if you only need to store the entropy of a secure password. What you can do is estimate the capability of a credible attacker, and truncate the output to that.

To implement this, run the password through the hash algorithm, and save only the first n bits of the output. The properties of a modern hash algorithm include the property that a single bit of change in the input will produce a statistically random distribution of bits in the output. That means if I guess the password is AAAAAA, then guess AAAAAB, the outputs are completely unrelated. All you have to do when the user enters their password is run it through the hash, and compare the first n bits to the stored bits. Collisions are precisely as unlikely as the number of bits you store.

Some people believe that 80 bits is enough to survive millennia of brute force attacks given current and near-future technology; this assumes no viable weakening attack is found on the algorithm. Other people believe that 128 bits is large enough to withstand any brute force attack. The banking industry trusts 3DES for credit card and PIN data, and that has 112 bits of entropy. I'd decide the budget based on what others in the industry are doing.

  • Am I to understand that you think of entropy as an attribute of an encrypted password? I believe that a legitimate encryption algorithm would produce encrypted passwords that all have the same entropy. I believe the OP is asking about the entropy of the password itself without encryption. Apr 9, 2016 at 3:48
  • @BrentKirkpatrick, always assume the attacker can run his guesses through the encryption mechanism. Encryption doesn't matter. Think of entropy as the 'guessability', the amount of brute force work you'd have to do to exhaust the password space. Consider an intelligent guesser; they will try dictionary words first. A password of 12345 has very little entropy, regardless of whether you encrypt it or not. Apr 9, 2016 at 4:11
  • Then why do you mention entropy in relation to the encrypted password? Apr 9, 2016 at 4:18
  • @BrentKirkpatrick, because the challenge is to store the fewest bits needed, in this case those "containing the entropy"; but a password still has to be validated in the future. By hashing the entire password, all the "randomness" is repeatably moved into the size of the digest. Also note that I did not mention an encrypted password, but a hash digest of a password. An encrypted password would depend on a non-standard implementation of a block cipher to gather bits from a password longer than the block size. Apr 11, 2016 at 13:13

People use rules-of-thumb and an understanding of passwords to answer this question. Password entropy calculations require understanding the random process used to generate the passwords.


The suggestion these days is to have an 8-10 character password with a mixture of upper case, lower case, and numbers. The characters should be randomly chosen and not include words or the first letters of a phrase. If you are really concerned about security, you might have a 20 character password. If the password contains words, it is vulnerable to a dictionary hack, since words occur with very different probabilities than randomly chosen characters. Even the first letters of a the words in a phrase occur in more predictable patterns than truly random passwords.

Understanding Passwords

Brute-forcing a password requires repeatedly trying the character combinations. Since the question uses the term entropy, I assume this is a familiar concept. An k character password would require 62^k attempts to find an unknown password (where there 56 characters are upper case, lower case, and numbers). Ideally, the password would be a randomly choose password from the total 62^k possible passwords where all the characters appear with equal chance. However, many password generators generate predictable passwords. Please do not use words, the first letters of the words in a phrase, or common variations on predictable themes.

Password Entropy

Entropy refers the the unpredictability of a password. In order compute entropy, one must know the password and the distribution by which the characters in the password are generated. The entropy is a straight-forward calculation once that is known. I suggest that you use a password generator that generates characters uniformly at random (i.e. with equal probability) from the set of characters (the 62 characters that include the upper and lower case alphabet and the numbers). This will get you the best entropy.

If on the other hand, you wish to generate your passwords with a distribution that favors the lower-case letter 'a' over all other characters, then your entropy will be drastically lower than if the password is generated with equal probability. This means that passwords consisting only of words have very low entropy and are very predictable.

You might consider instituting a password selection policy that requires passwords to look like they are generated randomly. This will help your password entropy and save you bits in your embedded system.

  • Great info! I was aware of the 8-10 character rule-of-thumb, but was looking for any official guidelines or such that may exist, as I can't guarantee I could actually institute a password selection policy, I'd be relying on the customer to do that. Apr 9, 2016 at 0:52
  • If the customer is careless, they could use a password consisting a single character that has very low entropy. There is very little that you can do about this, except suggest that they be careful. Apr 9, 2016 at 0:57
  • The customer is of course free to be as stupid as they would like (and they often are). I'm asking how large should a password be, as in this instance large passwords are very costly but also very good. If I don't find any official info, I may just double your rule-of-thumb and go with it. Apr 9, 2016 at 1:03
  • Every additional character you add to your password will roughly double the difficulty of cracking it with a brute-force attack. Apr 9, 2016 at 1:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .