Re: One-line password generator
On Sun 27 Aug 2017 at 17:08:16 +0200, Thomas Schmitt wrote:
> 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.
Nothing significant to argue with here.
> 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.
/dev/random versus /dev/urandom appears to be one of those Holy Wars
topics. I'll stay as a bystander.
> 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
Ah! That's the origin of the 3/4 I've seen in entropy calculations.
> This password would have to be stored entirely on a storage device because
> it is not human memorizable.
Yep.
> > > If you stay with sha512sum: [Duh ... that should have been 256]
Thanks for the correction.
> > > ...
> > > 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.
It is in stretch, buster and sid.
> 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.
I am trying to avoid password management schemes (wallets etc). Also, I
am still firm in my view that passwords for online logins can be very
safe and memorable. It is the leaking of databases and offline cracking
which has my attention now (but I am not losing any sleep over it).
To some extent, I'm with David Wright
https://lists.debian.org/debian-user/2017/08/msg01417.html
I do not have to run faster than the bear, just faster than anyone else.
--
Brian.
Reply to: