1
$\begingroup$

Suppose I have a 'begin' password that I can remember.

I calculate it's SHA-512 hash, transform it to base-64 and check if it has a least 1 lowercase, 1 number, 1 capital, and 1 sign.

If this is not the case I repeat this procedure (but now use the previous hash as input) until I have a hash that fills these requirements.

I will now use this final hash as the 'final' real password.

Will every possible combination of bits be (approximately) equally likely? (If I ignore the first lowercase, number, capital and sign in the password and only look at the other chars)

In short: Will every possible 'final' password be equally likely?

$\endgroup$
4
$\begingroup$

If you skip the padding and final non-padding characters then yes, each character should be equally likely. The output of SHA-256 is indistinguishable from random if you cannot guess the input. This also goes for iterations of the hash calculations over itself.

The final characters are not over just SHA-256 but are padded with zero characters. This is necessary since 256 is not a multiple of 6, and each character in the base 64 alphabet is encoding 6 bits. So the final 256 % 6 = 4 bits need to be encoded by adding two 0 bits (and possibly one = sign for the padding).

Of course, this doesn't matter much since you'd still have all the entropy of the original password encoded into the base 64 representation, if you don't shorten the 43 or 44 characters of the base 64 hash of course; many password entry fields will not accept that many characters. Actually, you would be as secure if you use the hash without special characters. But that's often not accepted either.


Unfortunately, an attacker only has to deal with one additional hash calculation in your scheme. No salt or iteration count is added as would be in a good password hash algorithm. So while your assumption may be correct, the method of deriving a password hash - which this basically is - isn't.

Furthermore, your scheme may be vulnerable against somebody deliberately having your trying a password that will not generate passwords without symbols, as there is only a 1/64 chance of generating either one.

If you decide to shorten the hash or base 64 then you should not perform additional hashes over this shortened notation as somebody might be able to let you enter a cycle using the attack above. This chance is about zero if you keep hashing the full hash output of the previous generation.

| improve this answer | |
$\endgroup$
  • $\begingroup$ I indeed forgot about salt, thanks. But i don't really see the advantage of counting the times that i have to calculate the hash. Or does "iteration count" mean something different in cryptography ? To simplify the question a bit i didn't mention that the charchecks would be in the first X chars and the shortening would only happen after the last calculation. $\endgroup$ – Garo Nov 28 '19 at 21:47
  • 1
    $\begingroup$ Generally we use an iteration count to make sure that the attacker has to perform more calculations to strengthen the password. If that's required in your protocol depends on how the result is used / stored. In that case it is a preset number of iterations (after which you could proceed with your own protocol). Reading into password hashing / PBKDF's might be a good idea. $\endgroup$ – Maarten Bodewes Nov 29 '19 at 0:41
  • $\begingroup$ @Garo Roughly speaking, if I repeat a hash a bunch of times, I can increase the cost of deriving the key from the password. If I increase the cost from 30ns to 30,000ns (30us) by doing the hash more than once, the price paid by the correct user is in the noise for the rest of the process of logging in. However, for the attacker, who is using a more streamlined process, that price is literally a factor of 1000 increase in cost of cracking the password. You just have to find the sweet spot which costs a lot for the attacker but is an acceptable cost for the authorized user. $\endgroup$ – Cort Ammon Nov 29 '19 at 19:44
8
$\begingroup$

In short: Will every possible 'final' password be equally likely?

Yes, we expect that they equally likely. Cryptographic hash functions expected to have a well-distributed output. If you find any bias, you can convert this into an attack. Even there is a tiny bias then that can be used to attack for the hash function.

You seem like you are going to use the SHA-512 hash function as a password generator. Your scheme's weak point will be your master password. One can still write a password cracker for your construction. And Cryptographic hash functions are not designed to be slow, they are designed to be fast. That is why we use iteration on Key Derivation Functions. A better solution using PBKDF2 or Argon2, and use their output. You can use the iteration number as the next try if not occur. So first look at, 100000 then 100001, etc.

| improve this answer | |
$\endgroup$
  • $\begingroup$ This is aprox. the plan, the full version: 1) hash of master will be calculated 2) truncated a bit (lowers entropy, but attacker will find more strings looking like passwords) 3) name of site for which user want a password is appended 4) procedure in the question is used, but requirements are changed to make sure that the required chars are somewhere in the beginning, because 5) it will be truncated to make sure that the password is short enough that no site will complain. I have never heard about KD-functions, but if it offers extra security, i'll look it up. Thanks ! $\endgroup$ – Garo Nov 28 '19 at 21:29
  • 2
    $\begingroup$ I think you have to rethink the presumption that the attacker will find more strings in (2) that matches the hash. That's only the case if the security left after truncating is smaller then the entropy that you start with (and even then, it doesn't make a difference which password is found in case no salt is used). $\endgroup$ – Maarten Bodewes Nov 29 '19 at 0:45

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.