[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: SASL DIGEST-MD5 works but PLAIN/LOGIN fails

On Sun, 9 Feb 2014, Dieter KlÃnter wrote:
> Am Sat, 08 Feb 2014 23:18:22 +0100
> schrieb Michael StrÃder <michael@stroeder.com>:
> 
> > Dieter KlÃnter wrote:
> > > Am Sat, 08 Feb 2014 11:45:52 +0100
> > > schrieb Michael StrÃder <michael@stroeder.com>:
> [...]
> > 
> > Yes, got that working in the meantime. But unfortunately this only
> > works with clear-text userPassword values. That's definitely not what
> > I want.
> 
> Than you have to rely on an external password store, i.e. kerberos.
> But that all is security by obscurity if you don't harden the network
> and services. 

At least at one time, cyrus-sasl supported the ability to request from the 
auxprop mechanism alternate types of data that would be sufficient for 
doing the server-side of the SASL exchange.  For example, with CRAM-MD5 it 
could store the HMAC-MD5 context keyed with the user password (c.f. 
RFC2195), which is sufficient for calculating the expected digest.  The 
cyrus-sasl code would request both that form and the cleartext and then 
use whichever it got.

Of course, for both cram-md5 and digest-md5, the "prehash form" was 
sufficent to authenticate using those as the client, so the security gain 
was negligible: yeah, you didn't have the 'real' cleartext form, but you 
could still login as the user.  Add on the complexity of keeping that data 
up to date and the benefit of this seems complexity seems hard to justify.

I believe that that property of the server authenticator being sufficent 
to authenticate as the client is *not* true of some newer mechs: iirc, SRP 
uses some form of zero-knowledge proof such that the server doesn't need 
to store a password-equivalent.  That might also be the case with the 
SCRAM-* family.


Still, there are at least two problems with that as a solution:
1) can you really require the SASL clients in your setup to use SRP?
   (if it's that easy to require new mechanisms, I would expect more
   use of Kerberos!)
2) does the openldap 'slapd' auxprop support lookup of those alternate 
   data types as other attributes?  If so, what/where's the schema for 
   them?


Philip Guenther