Full_Name: Ferenc W�gner Version: 2.4.31 OS: Debian GNU/Linux squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.101.52.7) I'm trying to store the hypothetical password "{SSHA}" in cleartext, but slappasswd refuses to help: $ /usr/sbin/slappasswd -s {SSHA} -h {CLEARTEXT} Password verification failed. On #openldap hbf suggested that I file an ITS ("work" in the following means allowing binding): hbf: Looks like {CLEARTEXT} itself is broken. I think "userPassword: {CLEARTEXT}secret" should work, and so that slappasswd -h {CLEARTEXT} -s secret can output {CLEARTEXT}secret and userPassword: {CLEARTEXT}{SSHA} would be valid. As I agree with him, here it is.
On May 31, 2013, at 2:38 AM, wferi@niif.hu wrote: > Full_Name: Ferenc Wágner > Version: 2.4.31 > OS: Debian GNU/Linux squeeze > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.101.52.7) > > > I'm trying to store the hypothetical password "{SSHA}" in cleartext, but > slappasswd refuses to help: > > $ /usr/sbin/slappasswd -s {SSHA} -h {CLEARTEXT} > Password verification failed. > > On #openldap hbf suggested that I file an ITS ("work" in the following means > allowing binding): > > hbf: Looks like {CLEARTEXT} itself is broken. I think "userPassword: > {CLEARTEXT}secret" should work, and so that slappasswd -h {CLEARTEXT} -s secret > can output {CLEARTEXT}secret and userPassword: {CLEARTEXT}{SSHA} would be > valid. > > As I agree with him, here it is. > Not a bug... Clear text passwords appear in userPassword without any RFC 2307 scheme, as in userPassword: secret not: userPassword: {CLEARTEXT}secret A cleartext password of {SSHA} is disallowed for what should be obvious reasons. -- Kurt
On 2013-06-03 20:46, Kurt@OpenLDAP.org wrote: > Not a bug... > > Clear text passwords appear in userPassword without any RFC 2307 > scheme, as in > > userPassword: secret > > not: > > userPassword: {CLEARTEXT}secret That's backwards. userPassword values without a {scheme} prefix are cleartext passwords. Values with a {scheme} prefix use that scheme. This does not imply that a scheme can't be used which simply represents the passwords as-is, nor that slapd or slap tools have any business stripping away such a {scheme} prefix. In particular not when that's the only way to represent cleartext passwords starting with "{letters}". Though possibly this would mean slapd needs a tweak to how it represents non-prefixed passwords internally, if it currently uses "{cleartext}" to tell itself that. I have not looked yet. -- Hallvard
I wrote: > This does not imply that a scheme can't be used which simply > represents the passwords as-is, nor that slapd or slap tools have > any business stripping away such a {scheme} prefix. In particular > not when that's the only way to represent cleartext passwords > starting with "{letters}". ...OTOH perhaps it's too late to change {cleartext} now if it has an established useful meaning. Could introduce a new scheme called {plaintext} or {raw} instead for this purpose. -- Hallvard
On Jun 3, 2013, at 1:08 PM, Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no> wrote: > ...OTOH perhaps it's too late to change {cleartext} now if > it has an established useful meaning. Could introduce a new > scheme called {plaintext} or {raw} instead for this purpose. {CLEARTEXT} isn't an RFC 2307 hash scheme... it's a string used in configuration and command line cases to indicate that no RFC 2307 hash scheme is used, that is, the password is cleartext. In the code, IIRC, it's referred to as pseudo-scheme for this reason. The restrictions on clear text passwords that look like RFC 2307 hashed password exist because of the conflict between standard LDAPv3 behavior and RFC 2307 behavior. Adding some RFC 2307 plain-text hash scheme doesn't remove the conflict between standard LDAPv3 behavior RFC 2307 hashed passwords, so IMO the restriction should remain, at least by default. If such an option were introduced, the documentation should make clear that disabling the check can be problematic if ever stored hash passwords are to restored (on Bind) to LDAPv3 compliant LDAPv3 passwords over a period of time. -- Kurt