Bug 985364 - Passwords with simple number patterns are accepted as secure
Passwords with simple number patterns are accepted as secure
Status: NEW
Product: Fedora
Classification: Fedora
Component: libpwquality (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2013-07-17 07:02 EDT by Hubert Kario
Modified: 2015-05-29 05:14 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Hubert Kario 2013-07-17 07:02:16 EDT
Description of problem:
Dictionary based words with simple addition are accepted as secure.
If I pick a dictionary based word and append simple numeric pattern to it, the password is accepted and is given high security rating.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
echo abnegating1111 | pwscore
echo abnegating1234 | pwscore
echo abnegating7777 | pwscore
echo abnegating5678 | pwscore
echo abnegating11111111 | pwscore

Actual results:
[root@localhost ~]# echo abnegating1111 | pwscore
[root@localhost ~]# echo abnegating1234 | pwscore
[root@localhost ~]# echo abnegating7777 | pwscore
[root@localhost ~]# echo abnegating5678 | pwscore
[root@localhost ~]# echo abnegating11111111 | pwscore

Expected results:
Password quality check failed:
 The password fails the dictionary check - it is too simplistic/systematic


Password quality check failed:
 The password fails the dictionary check - it is based on a dictionary word

Additional info:
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.

The rules used:
 * pick a digit, repeat it
 * pick a digit, increment by one every next added one

Assuming 10 bits of guessing entropy for base word we get:
 abnegating1111 - 12 bits - should fail
 abnegating1234 - 12 bits - should fail
 abnegating7777 - 15 bits - Level 1, should not get high score
 abnegating5678 - 15 bits - Level 1, should not get high score
 abnegating11111111 - 13 bits - should fail
Comment 1 Tomas Mraz 2013-07-17 10:46:42 EDT
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.
Comment 2 Hubert Kario 2013-07-17 11:55:28 EDT
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.
Comment 3 Tomas Mraz 2013-07-17 14:18:25 EDT
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.
Comment 4 Hubert Kario 2013-07-18 06:44:12 EDT
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.
Comment 5 Tomas Mraz 2013-07-18 07:16:37 EDT
I was not precise enough above - I really reject that "we shouldn't add any entropy for selecting a rule".
Comment 6 Hubert Kario 2013-07-18 07:58:12 EDT
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.
Comment 7 Fedora End Of Life 2013-09-16 10:35:05 EDT
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:
Comment 8 Fedora End Of Life 2015-05-29 05:11:21 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.