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.)
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.)
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:
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.
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.
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
