I wrote a small shell function to generate random passwords. Such a password may look like the below.


I started to wonder if this is actually secure enough. Are there potentially better alternatives?

  • @SteffenUllrich deleted previous comment. OP, it looks like you have a string of 64 characters there, where each character can have one of 62 combinations (26 uc chars, 26 lc chars, and 10 digits). That's 5.16*10^114 possible combinations (62^64=5.16*10^114). That's 381 bits of entropy (log2(5.164974e+114)=381). I think you're good.
    – mti2935
    Commented Sep 6, 2021 at 13:35
  • 1
    @mti2935 that should be an answer and in the sample, it only looks like the letters go from a-fA-F ("hex") so your calculation is off is the sample shows the entire set of letters.
    – schroeder
    Commented Sep 6, 2021 at 14:12
  • Thanks @schroeder I wasn't sure whether to go by the sample that OP posted in the comment above or in the question. Either way, FWIW, I thought it was kind of short for an answer.
    – mti2935
    Commented Sep 6, 2021 at 15:57
  • @mti2935 with a quick line about why 381 bits of entropy "is good", I think it would be fine. Complete answers do not need to be War and Peace.
    – schroeder
    Commented Sep 6, 2021 at 16:00
  • I'm getting log₂(22⁶⁴) = 285 bits of entropy, where 22 = 10 via [0-9] + 6 via [a-f] + 6 via [A-F]. With actual hexadecimal, it's still log₂(16⁶⁴) = 256, which is also extremely secure.
    – Adam Katz
    Commented Sep 7, 2021 at 16:02

1 Answer 1


Your example D2fdAbE5e... is not hexadecimal because it uses mixed case, and it is not a full alphanumaric alphabet either.

Other than that, hexadecimal provides 4 bits of entropy (randomness) by character, so a 64 character long hexadecimal string can store 64*4=256 bits of entropy, which is more than enough (128 is enough). However, please note that this is an upper bound, the actual randomness (unpredictability) of the generated password depends on the source of randomness used. It is of utmost importance to use a CSPRNG (cryptographically secure pseudo-random number generator) to generate them. For example, the C function rand() is not secure, because it can generate at most 2^32 different passwords (which is not enough), whatever the length of the passwords. Using /dev/urandom would be safe (for example, the command head -c 16</dev/urandom|base64|head -c 22 generates passwords of 128 bits of entropy encoded in 22 characters).

An alternative to what you suggest is to use a password manager to generate passwords. They usually provide an estimation of the strength of the passwords they can generate.

  • As a side note: 128 bits is a minimum if no hardening of the password is used. When they are properly stored, for example using Argon2id, it can be safe to generate shorter passwords (how much shorter depends on the specific parameters used by the PBKDF). They can be even shorter if the threat model suppose that password hashes cannot be leaked and bruteforce protections are in place.
    – A. Hersean
    Commented Sep 6, 2021 at 15:32

You must log in to answer this question.

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