Re: One-line password generator
On Sat 26 Aug 2017 at 21:14:35 -0500, Mario Castelán Castro wrote:
> On 26/08/17 13:25, Brian wrote:
> > How does this
> >
> > echo 'secretpassword' | sha256sum - | base64 | cut -c -30 | head -1
> >
> > compare with your recommendation?
>
> I do not see the point in this post-processing.
>
> It seems that you have a very wrong impression of what makes a password
> generation scheme be a good password generation scheme.
I'd be prepared to accept lacking :). But that's inevitable when dealing
with the innards of an unfamiliar topic. I'm getting better, though.
> For any probability distribution fixed in advanced, the *expected* (in
> the sense used in probability theory) entropy of a password generated
> with my scheme is well defined and at least 132 bits (I wanted 128 bits,
> but using Base64 the choice is between 132 bits and 126 bits because 132
> is not a multiple of 6). In other words, if you take a probability
> distribution and keep if fixed while generating a big amount of
> passwords with my scheme, the average entropy under that probability
> distribution will be at least (within sampling error) 132 bits.
>
> This property is achieved *because* there is a source of randomness
> (that we can assume, has uniform distribution and thus maximal entropy
> per byte) in my generation scheme, not because of Base64. Base64 is
> there just to turn the random bytes into a *short* human-readable
> string. One could turn the random bytes instead into a list of words (as
> long as the mapping is one-to-one) and the same property about expected
> entropy would hold, but then the password would be *much* longer.
>
> Length is the *only* reason to use Base64 here instead of using the
> random bytes to choose words at random.
>
> By contrast, your “scheme” has no systematic source of randomness. It
> requires that one has already decided for a “randompassword”, and then
> post-process it. If the attacker knows the post-processing, guessing
> this password is at least as easy than guessing the input to the
> post-processing step (plus computing the hash and encoding, but this is
> negligible). Moreover, your post-processing stage loses information, as
> another user has already noted. If the attacker knows your
> post-processing method, he can speed the search by avoid trying the
> passwords that could not be possibly generated with your method because
> of this loss of information.
>
> For example, your method will never generate a string of '0000...'
> because the input to Base64 are hex digits in ASCII, which never have
> the byte value 0 (0 is unprintable).
>
> If the attacker does not know the post-processing stage, then maybe he
> will eventually begin to guess that your password is an human-generated
> password ran through a post-processing stage. Then very possibly your
> post-processing adds security (because the attacker has to guess the
> post-processing method too), but how much? *It is not well defined*. We
> already talked about non-well-defined probabilities, so I will not
> repeat that fragment.
Thank you for the detailed explanation. I had already come to some of
the conclusions in your account but it is good to have them firmly and
succinctly laid out.
--
Brian.
Reply to: