[pass] Provide symbol set as command line argument

[Lenz Weber]

...or just use urandom, which is non-blocking, does not "waste
randomness" and is totally acceptable for this use case.
I recommend watching this talk:
https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy


Essentially, it boils down to this: the feature request was about
providing specific character sets for specific passwords.
Base64 may sometimes be sufficient and sometimes just not satisfy
restrictions imposed by the website -  it definitely is not the answer
for the feature request.
Generating it by wrangling /dev/(u)random might or might not be the best
approach.

But before all that, there are other questions:
* should pass offer these options? (my opinion: yes, as this is
necessary for some sites)
* If yes, how should it do so?
    * Should it be a command switch,
    * should it be passed as a CHARSET environment varianble (my
preference)?

THEN we can look at a way to get those passwords - and keep in mind: it
should not introduce new dependencies and it should run not only on
linux, but on OSX, BSD and a nix-y windows environment.

On 11/11/2016 11:33 AM, Brian Candler wrote:
> On 11/11/2016 10:05, Henrik Christian Grove wrote:
>>> tr -dc 'A-Za-z0-9!"#$%&'\''()*+,-./:;<=>?@[\]^_`{|}~' </dev/random |
>>> >head -c 32 && echo
>>> >
>> You're absolutely right, I totally missed that first head which is
>> totally unneccessary.
>
> Note that if you pipe /dev/random directly into tr like this, you are
> likely to consume 4KB or more of random data, which will unnecessarily
> deplete your entropy pool, and indeed may block waiting for more
> entropy. It's a highly wasteful approach, as entropy is a valuable
> resource, and this in turn may impact on the performance of other
> cryptographic operations taking place on the machine.
>
> If you are using 'pass' then I suspect you are making passwords to
> copy-paste rather than remember and type. Therefore the benefits of
> having a larger character set are minimal, when you could just have
> longer passwords to achieve the desired level of entropy.
>
> Consider that the base64 set has 64 symbols, and hence 6 bits of
> entropy per character. The set in that 'tr' line has 95 symbols, so
> has 6.57 bits of entropy per character.
>
> So to get a password with 96 bits of entropy, you need a 16-character
> base64 password, or a 15-character password from that extended set. I
> don't consider the benefit of saving one character to be worthwhile,
> especially considering the difficulty of locating some of those
> characters on different keyboards, or the fact that many sites may
> reject some of those characters (different sites having their own
> policies as to which characters are acceptable)
>
> A good-quality 96-bit password can be generated consuming the minimum
> amount of system entropy like this (*):
>
> head -c 12 /dev/random | base64
>
> However if you really *do* want to use shorter passwords with more
> symbols, then I think it would be better to use a dedicated external
> program to generate passwords. The shell is *not* a good
> general-purpose programming language.
>
> I think 'pass' should have a simple default, and a configuration
> setting to choose an external password generator.
>
> Regards,
>
> Brian.
>
>
> (*) Some sites insist that your password *must* include at least one
> upper case, lower case and digit, and occasionally this formula will
> generate a password which doesn't meet those requirements - roughly 1
> time in 15.
>
> p(no digits) = ((64-10)/64)^16 = .0659812552
> p(no uppercase) = p(no lowercase) = ((64-26)/64)^16 = .0002385931
>
> However there are only two symbols in the base64 set, so if a site
> requires at least one symbol then you're quite likely to fail.
>
> p(no symbols) = ((64-2)/64)^16 = .6017103034
>
> I find that in practice, passwords generated like this are fine, and
> if very occasionally I have to generate another one, that's not a big
> deal - certainly less work than having to configure a program with the
> rules for a given site.
>
>
> On 11/11/2016 10:05, Henrik Christian Grove wrote:
>>> tr -dc 'A-Za-z0-9!"#$%&'\''()*+,-./:;<=>?@[\]^_`{|}~' </dev/random |
>>> > head -c 32 && echo
>>> >
>> You're absolutely right, I totally missed that first head which is
>> totally unneccessary.
>
> Note that if you pipe /dev/random directly into tr like this, you are
> likely to consume 4KB or more of random data, which will unnecessarily
> deplete your entropy pool, and indeed may block waiting for more
> entropy. It's a highly wasteful approach, as entropy is a valuable
> resource, and this in turn may impact on the performance of other
> cryptographic operations taking place on the machine.
>
> If you are using 'pass' then I suspect you are making passwords to
> copy-paste rather than remember and type. Therefore the benefits of
> having a larger character set are minimal, when you could just have
> longer passwords to achieve the desired level of entropy.
>
> Consider that the base64 set has 64 symbols, and hence 6 bits of
> entropy per character. The set in that 'tr' line has 95 symbols, so
> has 6.57 bits of entropy per character.
>
> So to get a password with 96 bits of entropy, you need a 16-character
> base64 password, or a 15-character password from that extended set. I
> don't consider the benefit of saving one character to be worthwhile,
> especially considering the difficulty of locating some of those
> characters on different keyboards, or the fact that many sites may
> reject some of those characters (different sites having their own
> policies as to which characters are acceptable)
>
> A good-quality 96-bit password can be generated consuming the minimum
> amount of system entropy like this (*):
>
> head -c 12 /dev/random | base64
>
> However if you really *do* want to use shorter passwords with more
> symbols, then I think it would be better to use a dedicated external
> program to generate passwords. The shell is *not* a good
> general-purpose programming language.
>
> I think 'pass' should have a simple default, and a configuration
> setting to choose an external password generator.
>
> Regards,
>
> Brian.
>
>
> (*) Some sites insist that your password *must* include at least one
> upper case, lower case and digit, and occasionally this formula will
> generate a password which doesn't meet those requirements - roughly 1
> time in 15.
>
> p(no digits) = ((64-10)/64)^16 = .0659812552
> p(no uppercase) = p(no lowercase) = ((64-26)/64)^16 = .0002385931
>
> However there are only two symbols in the base64 set, so if a site
> requires at least one symbol then you're quite likely to fail.
>
> p(no symbols) = ((64-2)/64)^16 = .6017103034
>
> I find that in practice, passwords generated like this are fine, and
> if very occasionally I have to generate another one, that's not a big
> deal - certainly less work than having to configure a program with the
> rules for a given site.
>
>
> _______________________________________________
> Password-Store mailing list
> Password-Store at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/password-store

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20161111/49c2dddc/attachment-0001.html>