Improve the pinentry password quality indication
Open, NormalPublic


The password quality percentage field in the pinentry-gtk-2 will for example
rate a password of 10 consecutive similar characters (e.g. "aaaaaaaaaa") as a
100% quality password. This is obviously misleading. I am not aware whether the
other pinentry programs (other than pinentry-gtk-2) are affected except for
pinentry-curses which doesn't have a "quality percentage" field.

neal added a subscriber: neal.Sep 17 2015, 1:58 PM

All of the pinentry's use the same metric, which is very naive. From

/* Estimate the quality of the passphrase PW and return a value in the

range 0..100.  */

static int
estimate_passphrase_quality (const char *pw)

  int goodlength = opt.min_passphrase_len + opt.min_passphrase_len/3;
  int length;
  const char *s;

  if (goodlength < 1)
    return 0;

  for (length = 0, s = pw; *s; s++)
    if (!spacep (s))
      length ++;

  if (length > goodlength)
    return 100;
  return ((length*10) / goodlength)*10;


neal lowered the priority of this task from Unbreak Now! to Low.Sep 17 2015, 1:59 PM
neal added a project: gnupg.
neal removed a project: pinentry.
werner added a subscriber: werner.Sep 17 2015, 3:50 PM

Was requested this way by a customer. Note that additional constraints can be
enabled too. I change this to a feature request.

werner raised the priority of this task from Low to Normal.Sep 17 2015, 3:50 PM
werner renamed this task from pinentry-gtk-2 password quality is misleading to Improve the pinentry password quality indication.
werner added a project: Feature Request.
werner removed a project: Bug Report.
dkg added a subscriber: dkg.Jun 26 2017, 7:07 PM

fwiw, i also find this password quality indicator rather dubious.

If people want good, memorable passwords, it would make more sense to offer to generate a memorable password for the user, rather than to try to guess at the strength using any non-data-driven approach.

GnuPG is a trusted name in security software, and shouldn't squander that trust by making claims about password strength that aren't backed up with evidence.

If we still want to include a password strength meter, then we could just delegate that decision-making process to a project dedicated to that task (like, unless the GnuPG project has a clear rationale for (or investment in) a specific password strength metric.

wltjr added a subscriber: wltjr.Jun 26 2017, 8:46 PM

I agree with @dkg, and something should be done to address this one way or another. It is pretty misleading.

I implemented a possible fix in D442. The GnuPG Agent may call an external program (specified with the new --passphrase-checker option) to evaluate the passphrase's quality. This would allow to implement all kinds of metrics for passphrase strength, and to select one simply by choosing the right passphrase-checker.

Obviously this is merely a draft/PoC, but I am willing to give it more thoughts if there is interest in this approach.

werner edited projects, added gnupg (gpg23); removed gnupg.Aug 7 2017, 9:55 AM

So… Is there any interest in the approach I drafted in D442?

If we’d rather perform the password strength evaluation in the agent process itself instead of delegating to an external tool, then in addition to libpwquality already mentioned by @dkg I would like to point to either zxcvbn-c or zxcvbn-cpp as possible implementations (the later is written in C++ as the name suggests, but has a C interface). See this blog post for the rationale behind thse two libraries.

Using an external process as an option is fine. However adding more dependencies to gnupg should be avoided.

I think it would be better to disable the quality bar by default and only enable it if --check-passphrase-pattern or the proposed option is used.