[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 23 Oct 2013 01:50:13 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: RESEND: CVE Request: pwgen
On Fri, Oct 18, 2013 at 12:28:18PM +1100, Michael Samuel wrote:
> On 16 October 2013 16:59, Kurt Seifried <kseifried@...hat.com> wrote:
> > CVE-2013-4443 pwgen Secure mode has bias towards numbers and uppercase
> > letters
>
> Solar Designer picked up that this one should probably not have been assigned.
Michael is referring to discussion that we had off-list.
My current understanding, based on Michael's messages only, is that the
bias was only at character level, but not at full password level, given
the policy-reduced keyspace. I'll illustrate this by a trivial example:
Suppose we have a password generator configured to produce two character
long passwords consisting of lowercase and uppercase letters. It can
produce four kinds of passwords: LL, LU, UL, UU, where the L's and U's
denote lowercase and uppercase letters. These four kinds have equal
probability, and so do the individual L's and U's. Now let's add some
policy enforcement into the generator: have it require at least one
uppercase letter. Let's have it implement that by generating a new
password unless and until the generated password meets the policy, and
only then to print the password. This generator may now produce LU, UL,
and UU. It is easy to see that U is now more common than L, however
this is not a security issue on its own (arguably, the keyspace
reduction might be, but it is expected). If we look at the full
passwords within this reduced keyspace, then it is also easy to see that
all three of LU, UL, and UU are still equally likely. So there's no
password-level bias, and this is normally the only kind of bias that
would actually matter for security. Thus, no security issue (other than
the expected keyspace reduction).
The same applies to longer passwords and to additional character
classes, such as, if I understand its behavior correctly, to pwgen's
"secure" mode passwords.
Michael, is the above correct? If so, should Kurt reject CVE-2013-4443?
I think so.
To avoid the character-level bias while still requiring at least one
uppercase letter, we'd have to either introduce password-level bias
(would be a real security issue) or reduce the keyspace even further
(require at least one lowercase letter as well).
> The problem wasn't normal bias - it was that it was enforcing
> "password rules" requiring at-least one uppercase and number, but not
> lowercase (which was a normal bug). So the "fix" would technically
> make the keyspace smaller.
This was not necessarily a bug at all, although I agree that if we
require at least one uppercase letter and at least one digit, it does
seem natural to also require at least one lowercase letter. So
adjusting the behavior like you did makes sense.
> I added the -R / --no-rules flag to my branch which removes
> enforcement altogether,
This also makes sense.
> the full diff from 2.06 can be viewed here:
> https://github.com/therealmik/pwgen/compare/securityfixes
>
> Before using this flag, you should consider the minor negative effects
> on the keyspace vs. generating passwords which might be "accidentally"
> cracked while looking for simpler passwords. Either way, generating a
> longer password has a far better effect on security.
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
