Philip Guenther wrote:
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:
- 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!)
- does the openldap 'slapd' auxprop support lookup of those alternate data types as other attributes? If so, what/where's the schema for them?
The slapd auxprop simply looks up whatever attribute names SASL passed in. If there's no schema definition for these attributes, naturally those lookups will fail but the failure is ignored, the auxprop just returns as much as it knows about.