Thank you for reacting quickly! begin quotation from Theodore Ts'o (in <20140112234500.ga15...@thunk.org>): > On Sun, Jan 12, 2014 at 09:27:14PM +0100, Arne Wichmann wrote: > > This grave problem is now open for more than two months. Is there any plan > > to resolve this? > > First, the CVE about having the unavailability of /dev/random fail > hard -- sure, that should be a separate bug since that's a fix that I > think is reasonable at this point. We can now guarantee that > /dev/random exists everywhere. (And by that same token, if an > attacker can cause /dev/random not to be present, they probably have > root, so you're probably toast anyway. So I don't think it's going to > really improve things to remove the drand() fallback, but I don't have > strong feelings about that.)
So you might clone a new bug for this...
> Secondly, I'll note that one of the CVE's were rejected as not a
> vulnerability. (In general it would have been better to have opened
> seperate bugs for each CVE.)
Different maintainers have different preferences here - I will note that
you want seperate bugs (as we do for a number of other packages).
> Finally, whether you think the other two CVE's justify this to be
> serious, let alone "grave" bug really depends on what you think the
> goals of pwgen are. To quote from the manual page:
This is your decision - we try to use a fitting severity for every problem,
but sometimes the cases are not so clear.
> The pwgen program generates passwords which are designed to be easily
> memorized by humans, while being as secure as possible. Human-memo???
> rable passwords are never going to be as secure as completely com???
> pletely random passwords. In particular, passwords generated by pwgen
> without the -s option should not be used in places where the password
> could be attacked via an off-line brute-force attack. On the other
> hand, completely randomly generated passwords have a tendency to be
> written down, and are subject to being compromised in that fashion.
>
> So we could change the defaults to be "pwgen -csy 20", in which case
> you would get passwords like tihs:
>
> L}U@lc_~i^>n|ro!4uI- 1`;yXlYVMW%?E9)3A&7G **}6BoBu=!~3)y?3v]Or
> >=>:PC;H?E7*+6$c&-QH URGgjUNG[\dSw\>p7F-] _AXZ~(HYd8Q#%b>!]'u:
> ~)0<I-{)}_Ya*Q2nlWN; ^#t~1/'sf@*xz9GOhBuv e_[-_Fe{CD#]DY8&@M^a
>
> I'm not sure that would be an improvement, as simply no one would use
> them.
>
> OK, how about this? (Generated using pwgen -s).
>
> vQ6uwkMk lSswO2MB tA8dYPpl KU1pQ2Xh 2XfxRyrC Za2xKx7h psPwHZ0c dOsC0JBX
> JY3udA9c t6LzoiUq M0jR3AoS GOHkNE7G TeThsZz1 6cVi4ayY Poe4hPj7 o2a7OpPC
> Xh24cRLO 1chQyseV 6c2k0O3B OkdgRxy4 K6Vc4JY2 ylO3IE9B gVvNxw6B 7wjcOXwF
>
> Again, this will make the professional paranoids happy (although
> perhaps not as happy as ">=>:PC;H?E7*+6$c&-QH"), but its not clear that
> real users would be any less likely to write "ylO3IE9B" on a sticky
> note which is pasted to their monitor, or just in a "passwords" file
> in their home directory.
I do not have a really good idea on how to handle this. Some ideas come to
mind, mostly inspired by [1]:
- Improve the algorithm to be less biased. Though I see that would not be
easy.
- Warn about the bias
- Use -s as default
[2] suggests, that there is a patch out there, but I have not yet looked at
it.
> So ultimately, a lot of this is about an argument over defaults, and I
> think the higher level problem is that no matter what password policy
> you use, passwords are doomed as a technology. Anything which is
> secure against a brute force attack is impossible for a user to use,
> unless they share passwords across multiple sites so they only have to
> remember one password such as "ylO3IE9B" --- at which point they get
> toast once some web site screws up in some way and gets penetrated by
> bad guys.
I see the point, but that does not make the problem go away, and in many
cases you do not have so much of a choice, so the program does still have
its points.
CVE-2013-4440 has an easy fix, isn't it?
[1] http://www.openwall.com/lists/oss-security/2012/01/19/24
[2] http://marc.info/?l=oss-security&m=138015793928431&w=2
cu
AW
--
[...] If you don't want to be restricted, don't agree to it. If you are
coerced, comply as much as you must to protect yourself, just don't support
it. Noone can free you but yourself. (crag, on Debian Planet)
Arne Wichmann (a...@linux.de)
signature.asc
Description: Digital signature
