|Summary:||Dictionary check error message is misleading|
|Product:||[Fedora] Fedora||Reporter:||Rahul Sundaram <sundaram>|
|Component:||cracklib||Assignee:||Nalin Dahyabhai <nalin>|
|Status:||CLOSED INSUFFICIENT_DATA||QA Contact:||Brian Brock <bbrock>|
|Version:||rawhide||CC:||akonstam, smohan, triage|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-05-07 00:10:44 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Rahul Sundaram 2005-05-21 13:45:40 UTC
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 19:54:53 UTC
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 20:12:26 UTC
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 20:19:44 UTC
adding original reporter to CC list for comments
Comment 4 akonstam 2005-09-17 21:04:52 UTC
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 16:10:39 UTC
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-07 00:10:43 UTC
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