Bug#987952: apg: security concerns in apg
On Tue, May 04, 2021 at 03:17:10AM +0200, Christoph Anton Mitterer wrote: > On Mon, 2021-05-03 at 11:49 +0200, Marc Haber wrote: > > apg is dead upstream. We can either pull the package (forcing people > > back to pwgen, which probably has comparable issues) or document the > > issues away. > > I wouldn't pull the package - it's probably still much better to use > these passwords than anything the user comes up himself. The ideal password generator would be a merge/crossing of apg and pwgen. I must admit that I have mostly migrated over to pwgen in the last decade, pwgen gets developed slowly, apg is dead. > And anyone doing real security will probably know that pronounceable > passwords will have less entropy unless it's something like diceware. Diceware is even less entropy per character, but it's supposed to be more easily rememberable. For me, I have grown into passwords; I find it considerably easier to memorize something like ath;aeGie0Thah4i (pwgen -y 16) than LappedAnguishedReconcilePatrolRematchStrategic (diceware). But I have a strange brain anyway. > > Would you want to provide wording for a README.Debian or an addition > > to > > the package description? > > > I would have rather written a patch that adds the information to the > manpages and gives a message to stderr when using -a 0. I agree with the manpage, the stderr message would have to obey -q. > Maybe even mentioning something like diceware to be more secure when it > goes about memorable passwords. > > Would that be okay for you? I have generated https://salsa.debian.org/debian/apg and will initialize it with the existing code within the hour. Feel free to submit a merge request if you want to help. > But even then... do you perhaps happen to have any connections to some > better security expert (maybe in the Debian security team)? > I'd would like to know whether may point (2) with the capital-letter- > must-include modes is a real thing... and whether we should warn about > that, too. I am not sure whether this might be going too far. I think everybody knows that using a password generator means less entropy than /dev/random at a price of being memorable in different degrees. A password is not a cryptographically secure key. I am afraid that I don't have any close ties to the security team. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#987952: apg: security concerns in apg
On Mon, 2021-05-03 at 11:49 +0200, Marc Haber wrote: > apg is dead upstream. We can either pull the package (forcing people > back to pwgen, which probably has comparable issues) or document the > issues away. I wouldn't pull the package - it's probably still much better to use these passwords than anything the user comes up himself. And anyone doing real security will probably know that pronounceable passwords will have less entropy unless it's something like diceware. > Would you want to provide wording for a README.Debian or an addition > to > the package description? > I would have rather written a patch that adds the information to the manpages and gives a message to stderr when using -a 0. Maybe even mentioning something like diceware to be more secure when it goes about memorable passwords. Would that be okay for you? But even then... do you perhaps happen to have any connections to some better security expert (maybe in the Debian security team)? I'd would like to know whether may point (2) with the capital-letter- must-include modes is a real thing... and whether we should warn about that, too. Only few people would actually read README.Debian. > For bullseye, "pull package" is the only viable solution now. I'd say keep it... the
Bug#987952: apg: security concerns in apg
Hi, apg is dead upstream. We can either pull the package (forcing people back to pwgen, which probably has comparable issues) or document the issues away. Would you want to provide wording for a README.Debian or an addition to the package description? For bullseye, "pull package" is the only viable solution now. Greetings Marc
Bug#987952: apg: security concerns in apg
Oh and one follow-up on (2): The -M modes with capital letters, i.e. "must use symbol class", also sound like actually reducing the entropy and - if that's really the case - one should perhaps warn about this. My idea is kinda: Imagine you create a password of 4 symbols. If the attacker knows, that all 4 categories (SNCL) must have been included, it will already make his work much easier. Sure, 4 symbols is not enough for any reasonable password, but I guess the same principle would probably apply to larger ones? Cheers, Chris.
Bug#987952: apg: security concerns in apg
Package: apg
Version: 2.2.3.dfsg.1-5+b2
Severity: normal
Tags: security
Hey.
I was thinking about a number of security concernts, and since I'm no
expert, maybe someone else has an idea:
1) Attack on pronouncable passwords?
Via https://en.wikipedia.org/wiki/Random_password_generator#Stronger_methods
I've stumbled over:
Ganesan, Ravi; Davies, Chris (1994). "A New Attack on Random Pronounceable
Password Generators"
http://csrc.nist.gov/publications/history/nissc/1994-17th-NCSC-proceedings-vol-1.pdf
and
http://www.andrew.cmu.edu/user/nicolasc/publications/Shay-SOUPS12.pdf
The former seems to be an attack on what I guess apg is dowing when -a 0?
So maybe, if that is real, one should warn against using -a 0?
2) Are symbolls well distributed?
The following is really absolutely NOT solid, and probably just stupid
perception of mine
For many years now I've used:
APG_PARM="-c /dev/urandom -a 1 -M SNCL -m 32 -x 32"
and I kinda always had the impression that special symbols are way
over-represented, e.g.
6^20:#;$0dZw7%AWM{@rVX']TK2q3(kX
IHxb*Yse?^@Kx[kZhxJp;4nOPCRxfhe(
ty%'a}U{+A)@>r|4;_#$yP^9[ZVXLTN<
5Fz_0.&_rK2+[3vBC0IRODQD5B]M#T9u
m#_dRg@x@)\mgbbz57,.||(!g5D`R={d
++4v%Ozl3Ae[e
