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