OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/7612
Full headers

From: wferi@niif.hu
Subject: {CLEARTEXT} password scheme broken
Compose comment
Download message
State:
0 replies:
4 followups: 1 2 3 4

Major security issue: yes  no

Notes:

Notification:


Date: Fri, 31 May 2013 09:38:59 +0000
From: wferi@niif.hu
To: openldap-its@OpenLDAP.org
Subject: {CLEARTEXT} password scheme broken
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.

Followup 1

Download message
Subject: Re: (ITS#7612) {CLEARTEXT} password scheme broken
From: Kurt Zeilenga <Kurt@OpenLDAP.org>
Date: Mon, 3 Jun 2013 11:46:09 -0700
Cc: openldap-its@OpenLDAP.org
To: wferi@niif.hu
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
 




Followup 2

Download message
Date: Mon, 03 Jun 2013 22:02:36 +0200
From: Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>
To: <Kurt@openldap.org>
Cc: <openldap-its@openldap.org>
Subject: Re: (ITS#7612) {CLEARTEXT} password scheme broken
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



Followup 3

Download message
Date: Mon, 03 Jun 2013 22:08:29 +0200
From: Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>
To: <Kurt@openldap.org>
Cc: <openldap-its@openldap.org>
Subject: Re: (ITS#7612) {CLEARTEXT} password scheme broken
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



Followup 4

Download message
Subject: Re: (ITS#7612) {CLEARTEXT} password scheme broken
From: Kurt Zeilenga <Kurt@OpenLDAP.org>
Date: Mon, 3 Jun 2013 13:27:16 -0700
Cc: <openldap-its@openldap.org>
To: Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>
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 


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org