https://bugzilla.novell.com/show_bug.cgi?id=740135 https://bugzilla.novell.com/show_bug.cgi?id=740135#c0 Summary: LDAP slapppasswd can't make crypt/blowfish hash Classification: openSUSE Product: openSUSE 11.4 Version: Final Platform: i586 OS/Version: openSUSE 11.4 Status: NEW Severity: Normal Priority: P5 - None Component: Security AssignedTo: security-team@suse.de ReportedBy: jimc@math.ucla.edu QAContact: qa@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.14 (KHTML, like Gecko) Chrome/18.0.975.0 Safari/535.14 SUSE/18.0.975.0 slappasswd cannot create a password hash using any of the crypt/blowfish variants (2a, 2x, 2y). If a different algo is used, such as crypt/SHA-256 (algo 5), slappasswd can create the hash. (None of the passwords involved have 8bit characters.) Reproducible: Always Steps to Reproduce: 1. echo The_Password | slappasswd -T /dev/stdin -h '{CRYPT}' -c '$2y$10' Actual Results: Password generation failed for scheme {CRYPT}: Expected Results: {CRYPT}$1$yq$mJMUURIAarGHks8tSrymB1 (Shown for -c '$1$%.2s' (MD5), also works for -c '$5$%.8s' (SHA-256), -c '$6$%.8s' (SHA-512). Bogus algo codes such as 2z yield DES, specifically {CRYPT}$2h4NbwoBCFtk for this password.) Workaround: Edit /etc/default/passwd saying CRYPT=sha256 and send all the users a phishing message telling them to change their passwords. What I would like the developers to do: Go over the way LDAP uses the recently patched Blowfish algo and find the defect in how slappasswd is calling it. Also update the comments in /etc/default/passwd saying that sha256 and sha512 are recognized. Another windmill to tilt at: fix the -c option of chpasswd to accept sha256 and sha512. Shouldn't the alphabetic algo codes be in glibc's crypt()? The issues discovered in bug 713727 dated 2011-08-23 may be relevant. PS: I have a non-reproduceable failure where a pre-existing password hash with algo 2a (buggy Blowfish) could not be used for authentication. Specifically: ldapsearch -x -D uid=testacct2,ou=People,dc=cft,dc=ca,dc=us -W \ -ZZ -LLL '(uid=jimc)' gecos Outcome: "ldap_bind: Invalid credentials (49)" I changed its password hash to SHA-256 and the search result was delivered. But another account using algo 2a can authenticate. There are too many variables here to positively declare that a bug was found, but a quick look at the LDAP authentication code may be worthwhile. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.