Bug 158391 - Dictionary check error message is misleading
Dictionary check error message is misleading
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: cracklib (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-21 09:45 EDT by Rahul Sundaram
Modified: 2013-03-13 01:42 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:10:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rahul Sundaram 2005-05-21 09:45:40 EDT
Description of problem:

The error message returned by cracklib when a password change fails is misleading


How reproducible:

everytime

Steps to Reproduce:

change a regular user's password to "kgf08p"

  
Actual results:

BAD PASSWORD: it is based on a dictionary word

Expected results:

The above password obviously not based on a dictionary word. The error message
should help the end user is determining why the password change fails to help
the person resolve it better. If it fails because its a short message, then that
should be provided as a clue instead


Additional info:

based on #158191
Comment 1 Nalin Dahyabhai 2005-09-13 15:54:53 EDT
The "based on a dictionary word" message is actually based on cracklib's
determination that the password which was supplied can be derived by starting
with a word which is in the dictionary, and performing a specific set of
transformations on it (for example: removing a character, adding a character,
replacing one character with another).

Ideally, we'd have some tool which, given a candidate password, listed the steps
which cracklib claims could be used to generate the dictionary password (the
cracklib dictionary stores the dictionary passwords, and the library performs
the inverse of the process I describe on the candidate password, then checks for
the result in its dictionary).

Do you have a specific text error you'd like to see instead of this one?
Comment 2 Rahul Sundaram 2005-09-13 16:12:26 EDT

In many scenarios the output from the password is used to educate the users on
what is not considered a good password. Since the password returns a error
messages on something that isnt obviously based on the dictionary it seems to be
misleading. It might be useful if could we have enhance cracklib to explicitly
list the transformation it makes and have passwd program list that on an option
to make it explicit why cracklib considers the words to be a dictionary based one. 

If thats too much work then providing a generic message might be more
acceptable. I dont have any bright ideas  beyond that.
 
Comment 3 Rahul Sundaram 2005-09-13 16:19:44 EDT

adding original reporter to CC list for comments
Comment 4 akonstam 2005-09-17 17:04:52 EDT
One would like to believe that the algorithm described in comment #1 is being
followed by cracklib. It is hard to believe that algorithm when applied to:
kgf08p could determine that it was based on a dictionary word. Support for the.
lagorithm  is found when one enters: p80fgk the system said that this is derived
from a dictionary word spelled backward.

I would be curious what dictionary word that would be . Maybe we should send
this question to Will Short the NY Times Crossword Puzzle editor and
puzzlemaster on NPR Sunday morning. Ok, the probloem is we want to teach
studnets to created secure passwds. If kgf08p is not secure I am at a loss to
advise them what passwd is secure. Maybr I should give it ot my Cracking program
to see if it can be cracked.
Comment 5 Bug Zapper 2008-04-03 12:10:39 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 6 Bug Zapper 2008-05-06 20:10:43 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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