Bug 1004132
Summary: | [RFE] [usability] password generator | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Steve Tyler <stephent98> |
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | anaconda-maint-list, dshea, g.kaviyarasu, hkario, jonathan, mkolman, sbueno, stephent98, vanmeeuwen+fedora |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-01-27 16:41:08 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Steve Tyler
2013-09-04 03:03:28 UTC
[Comment copied from Bug 1003169, Comment 20] Hubert Kario 2013-09-03 10:46:53 UTC Generating a secure passphrase (40+ bits of entropy) for the user if the provided password fails the check would also increase the usability (of course a warning "don't use it if somebody could have seen your screen" should also be presented). See diceware[1] and http://xkcd.com/936/ 1: http://world.std.com/~reinhold/diceware.html A password generator is probably not something anaconda should actually implement. Since a password generator would also be useful in a desktop environment, it would be better for anaconda to reuse an existing one. Hubert: Are you aware of any password generators that would be suitable for use by anaconda? Partial requirements are: 1. Has a Python interface, since anaconda is implemented mainly in Python. 2. Can be configured with a graphical or a text user interface, so it can be used by the installer in both graphical and text installer modes. 3. The user can configure password properties, such as whether it is a word or a phrase, can be pronounced, uses non-alphanumeric characters, etc. Two good Fedora password generators are: 1. pwgen-2.06-9.fc19.x86_64 (command-line) 2. gnome-password-generator-1.6-9.fc19.noarch (GUI) (NB: Installing this pulls in 13 packages, including libgnome and libgnomeui.) Neither integrates password-strength testing, however. See also: Bug 550351 - RFE - Anaconda needs the ability to specify password controls Steve: no, unfortunately I don't know of any python based password generators. There is quite good password generator that's part of passwdqc: pwqgen. Making one shouldn't be too hard though, for passphrase generator the hardest part is getting hold of list of short, distinct, relatively common words, rest is trivial. Creating one that is as feature complete as the one in OSX would be a bit more complex though. If we could use the diceware lists (including translations) then creating it shouldn't take more than a day for experienced python coder. The OSX one also supports manual input, so the password needs to be pushed through quality checker in any case. OK, thanks. pwqgen generates very readable passphrases:[1] $ pwqgen Chalky=Indeed+Laugh It has some odd limitations, though:[2] $ pwqgen random=81 spicy+keel6talk&belly3Angle $ pwqgen random=82 pwqgen: Error parsing parameter "random=82": Invalid parameter value And pwqcheck won't simply report the estimated password strength:[3] $ pwqcheck Chalky=Indeed+Laugh [ctrl-d] pwqcheck: Error reading standard input. [1] Tested with: passwdqc-1.2.2-5.fc19.x86_64 [2] random=N (default: random=47) The size of randomly-generated passphrase in bits (26 to 81). [3] For each passphrase to check, pwqcheck reads up to 3 lines from standard input: first line is a new passphrase, second line is an old passphrase, and third line is either an existing account name or a passwd entry. One problem with password generation in the installer could be a lack of entropy for the random number generator, unless there is a hardware random number generator:[1] $ man pwqgen ... Strength of the generated passphrase depends on the amount of randomness read from /dev/urandom. ... [1] An Intel hardware based digital random number technology could mitigate recent RSA security flaw Submitted by Robert Chesebro... on Wed, 02/22/2012 - 11:14 http://software.intel.com/en-us/blogs/2012/02/22/an-intel-hardware-based-digital-random-number-technology-could-mitigate-recent-rsa-security-flaw The passwdqc package includes the pam_passwdqc.so library. That's almost as good as a Python module, because a Python wrapper can be written. AFAICT, there is no need for an external word list. strace shows pwqgen opening pam_passwdqc.so and /dev/urandom, but no word file. Also, the "strings" command shows pam_passwdqc.so has an embedded word list. The 81-bit entropy limit does not seem like a practical limit. The installer could display a slider with a range from 26 to 81 bits for the desired strength. $ rpm -qlv passwdqc | sed 's/root root /.../' -rw-r--r-- 1 ... 99 Mar 13 2010 /etc/passwdqc.conf -rwxr-xr-x 1 ... 15344 Feb 16 2013 /lib64/security/pam_passwdqc.so -rwxr-xr-x 1 ... 11480 Feb 16 2013 /usr/bin/pwqcheck -rwxr-xr-x 1 ... 11368 Feb 16 2013 /usr/bin/pwqgen drwxr-xr-x 2 ... 0 Feb 16 2013 /usr/share/doc/passwdqc-1.2.2 -rw-r--r-- 1 ... 6442 Mar 13 2010 /usr/share/doc/passwdqc-1.2.2/README -rw-r--r-- 1 ... 3069 Mar 14 2010 /usr/share/man/man1/pwqcheck.1.gz -rw-r--r-- 1 ... 1362 Mar 13 2010 /usr/share/man/man1/pwqgen.1.gz -rw-r--r-- 1 ... 3741 Mar 13 2010 /usr/share/man/man5/passwdqc.conf.5.gz -rw-r--r-- 1 ... 1820 Mar 12 2010 /usr/share/man/man8/pam_passwdqc.8.gz This appears to be the relevant function: $ grep passwdqc_random /usr/include/passwdqc.h extern char *passwdqc_random(const passwdqc_params_qc_t *params); $ rpm -ql passwdqc-devel /usr/include/passwdqc.h /usr/lib64/libpasswdqc.so The passwdqc word list is in wordset_4k.c, and it has 4096 words. /* * 4096 English words for generation of easy to memorize random passphrases. * This list comes from a passphrase generator mentioned on sci.crypt, and I * believe is in the public domain. * * I've replaced two 7-character words to save space. */ #include "passwdqc.h" char _passwdqc_wordset_4k[0x1000][6] = { "Adam", "Afghan", "Alaska", ... "zinc", "zombie", "zone" }; Source is from here: http://distro.ibiblio.org/openwall/Owl/2.0-stable/native.tar.gz (In reply to Steve Tyler from comment #5) > And pwqcheck won't simply report the estimated password strength:[3] that's true, the return from it is either "OK" or error describing why the password is weak > $ pwqcheck > Chalky=Indeed+Laugh > [ctrl-d] > pwqcheck: Error reading standard input. Try with "-1" option: $ pwqcheck -1 Chalky=Indeed+Laugh OK (In reply to Steve Tyler from comment #6) > One problem with password generation in the installer could be a lack of > entropy for the random number generator, unless there is a hardware random > number generator: while it's true that average PC is entropy-starved right after boot, the amount of entropy we need and the quality of entropy from /dev/urandom makes using it over human generated passwords a much, much better solution. Patching it to use /dev/random in FIPS mode shouldn't be too hard. (the installer should watch out for blocking reads and show a progress bar with "collecting entropy" then!) (In reply to Steve Tyler from comment #7) > AFAICT, there is no need for an external word list. strace shows pwqgen > opening pam_passwdqc.so and /dev/urandom, but no word file. Also, the > "strings" command shows pam_passwdqc.so has an embedded word list. It should be localizable (as in available in different languages). For now it allows generation of passwords using only English words. > The 81-bit entropy limit does not seem like a practical limit. The installer > could display a slider with a range from 26 to 81 bits for the desired > strength. I'd argue that increasing it to 128 bits would be a good idea for future proofing. What's the rationale for closing? Since this feature would involve a significant redesign of three different password screens, this is the kind of thing that would be better discussed on the anaconda-devel mailing list. We try to avoid design by bugzilla. |