Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Suppose I would like to use a very long string as a password. As an example we can just say this string is 100 characters in length.

However, suppose the application for which I would like to use this password only supports password lengths of 64 characters. Without going in detail, assume that simply truncating the desired password at 64 characters would significantly increase its predictability.

Would it be secure if I used as my password a hash of this password, for the sole purpose of reducing its length?

For example, if I chose to use a base64-encoded SHA-256 hash of the password, I believe that I am looking at a search space of about 2.96 * 1079 (64 possible characters * length of 44). I choose to use base64 instead of the hex representation because the hex representation consists of a smaller search space (16 possible characters * length of 64 = 1.16 * 1077).

(EDIT: As Thomas Pornin pointed out in his answer, the search space will always be 2256 regardless of what encoding is used.)

For my purposes, this search space size is sufficient. However, does the fact that I am using a base64 encoding of a SHA-256 hash introduce any predictability o the password? In other words, if an attacker knows that my password is a base64-encoded SHA-256 hash of an input string (but he knows nothing about the input string), would he some how be able to reduce that initial search space of 2.96 * 1079?

share|improve this question
If your SHA encoder isn't adding extra data to the output (for example, a password-oriented hasher would add a salt and stretching information), then there should be no problem. Thomas Pornin's answer explains the rest much better than I ever could. – Dave Mar 21 '13 at 1:40
up vote 7 down vote accepted

The "search space" has size 2256. It is not enlarged or reduced depending on whether you use hexadecimal or Base64. When you encode a 256-bit string (aka 32 bytes) in Base64, you indeed get 44 characters, but not all combinations of 44 characters (taken in an alphabet of 64) are possible. The 44th character will always be an '=' sign, and there are only 16 possible characters for the 43rd position.

Now, 2256 is huge and far (very far) beyond that which is searchable with existing or foreseeable technology. That's also beyond good science-fiction. That's even beyond bad science-fiction.

Hashing a password with a cryptographically strong hash function (and SHA-256 is indeed strong) is a valid way of "shortening" a password; indeed the PBKDF2 function (a key derivation function, often used for password hashing) begins by such a step(*). The apparent "reduction" of the space is not an issue because a space of size more than about 280 is not susceptible to exhaustive search.

Of course, this raises the question of how you will compute the hash... a password is called "password" because it is meant to be remembered by a human mind and typed by human fingers. Will you remember a hash output ?

(*) PBKDF2 is normally used with HMAC, the password being the HMAC key. In HMAC, if the key is larger than the "block size" of the internal hash function, then it is first hashed, and the resulting hash value is used as key.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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