Re: One-line password generator

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

i wrote:
> > Quite hard
> > to guess would be if you replace sha256sum by an encryption program with
> > a key which you successfully keep secret.

Brian wrote:
> Increasing difficulty in this way looks good to me. Thanks. I would most
> certainly hope I could keep the key secret.

Now you would have a human memorizable password in your mind and a strong
encryption key which you hopefully can keep secret on a storage device.
(The key is not strong if you can memorize it in your wetware.)

The password known to the remote service would be generated by the script
which combines the secrets from your brain and the storage device to one
that is supposed to be very hard to crack.

You would best avoid to store this remote password permanently on your
computer. I.e. let the machine forget it as early as possible. Just in case
you get unfriendly visitors.

If your encryption key gets stolen, then your brain stored password will
still impose some obstacle, which could give you some time to react.
If you notice the breach, that is, and if your password is already quite
hard to guess.

Each password should have its own encryption key, so that one stolen and
cracked password does not weaken the encryption of other passwords.


If your password is not that strong, then you are probably better off with
Mario Castelán Castro's approach modified by use of /dev/random instead of
/dev/urandom.
  https://lists.debian.org/debian-user/2017/08/msg01260.html

  head -c 16 /dev/random | base64 | head -c 22

Reading 16 bytes of good random yields up to 128 bit of secret information.
Making it printable by base64 does not change the information content.
Cutting off the last two characters of the base 64 result does not reduce
the secret, because any run of

  head -c 16 some_file | base64

yields "==" at these positions. It's a consequence of base64 converting
groups of 3 bytes to groups of 4 bytes. See
  https://en.wikipedia.org/wiki/Base64#Output_padding

This password would have to be stored entirely on a storage device because
it is not human memorizable.


> > If you stay with sha512sum: [Duh ... that should have been 256]
> > ...
> > It would be better to convert sha512sum output from hex to binary before
> > applying base64 to make it printable.

> Ok, I think I've got the idea here. xxd looks a useful utility for the
> conversion.

I had no success with looking for such a thing.

But be aware that the combination of a human memorizable password and
an easy to guess hashing algorithm is much weaker than the two methods
mentioned above.
There is few chance that your brain can hide a secret from a bunch of
high end processors, if they have a final goal to which they can compare
the results of their tries.

That final goal would be the stolen list of usernames and password hashes
and the stolen info how the hashes get generated by the service from your
remote password.

-------------------------------------------------------------------------

This all is theory. In practice, you can fall victim to small loopholes
in the way you use or store the highly armored passwords.

For real security concerns, consider to look for a password management
system from people who have experience with real attacks.


Have a nice day :)

Thomas