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?