Bug 985364

I am sorry but this is not the way how to measure the guessing entropy. You always have to add some bits of entropy for the rule choice. You need to create a ruleset - perhaps sorted somehow so the most probable rules are first and the least probable last and from the size of the ruleset and/or position of the rule in the ruleset add bits of entropy per the rule choice.

First: if we assume that the user chooses a rule from a specific set of rules we will end up with an empty string password that has, for example, 10 bits of guessing entropy. Because user did chose rules "no base word" and "don't modify base word" from a set of 32 "common" rules.

Second: we don't know which rules the user knows of. The rules he used might have been the only ones he knows about (or though up). Same goes for the attacker, he might use a very simple password generator that uses only 2 or 3 rules to modify the passwords (again, we don't have a way to know which ones). If they match, the guessing entropy is equal to the provided numbers. Or in other words, the amounts are "worst case scenario".

Adding more entropy for choosing a specific rule, just because it's uncommonly used *now*, will make it to be commonly used in future and end with a false sense of security. Because users *will* find out which simple to remember passwords are let through by the system.

So, in the end, the act of choosing a rule contributes very little entropy. Because we want the users to use passphrases, you can assume the 0 entropy added as penalizing the users for choosing any rules that modify the base word at all.

Analogy: Using secure or secret encryption algorithm doesn't make the encrypted data secure, using a truly random key with a good algorithm makes for a good encryption. Making the algorithm public shouldn't affect the security of encrypted data.



Also in Comment #0 should be:
Patterns starting from 1 are not random(it's the digit picked by over 80% of users), and the only addition to guessing entropy is their length.

I'm sorry but I disagree with you. Once you start giving rules "which you know/which cracklib or whatever pw quality checking knows" 0 entropy, you just make users invent new rules which in another iteration can be then penalized etc. etc. This does not bring us anywhere.

abnegating itself does not have 10bits of entropy - is it a word from 1000 words dictionary? etc. etc.

Where did I say that applying a rule should not add any entropy?

In Comment #2 I said we shouldn't add any entropy for *selecting a rule*.

If the rule is "pick a digit at random and append to word", its estimated entropy will be 3 bits, always. Even if that's the only rule all users used.

In comment #2 I'm writing only about rule selection, please re-read it with that in mind.

I was not precise enough above - I really reject that "we shouldn't add any entropy for selecting a rule".

But you didn't say why you don't agree with my arguments.

How will adding only one bit of entropy for very simple rules ("postfix 1") and only 15 bits of entropy for very complex rules ("add 3 random special characters") make the users came up with new bad rules? And using (e.g.) 4 bits and 20 bits will not (and won't result in insecure system)?

How is penalizing the most obvious and simple rules by assigning them only 1 bit of entropy going to lower the security of the system?

We are talking about Level 1 and Level 2 systems, they are unlikely to be under targeted attack. Removing the low hanging fruit is the goal.

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

We are not going to pursue this RFE at this point. If anyone wishes to work on this I'd suggest creating pull request on libpwquality upstream.

https://github.com/libpwquality/libpwquality