Re: auxprop pwcheck with sasl ldapdb and openldap backend not working

On 2021-11-6 23:54, Howard Chu via SASL wrote:
> PFiver via SASL wrote:
>> Got it.... thank you!
>>
>> I was finally able to get cyrus-imapd to talk to the ldap as well, by removing the "-hashed" suffix.
>>
>> I am wondering, what to do now. For one thing, hashed LDAP passwords seem to be supported in saslauthd:
>> https://github.com/cyrusimap/cyrus-sasl/blob/master/saslauthd/lak.c#L128
>>
>> I am not willing to story pain passwords in the ldap (and use "auxprop" with "ldapdb" as is), but I am tempted to attempt to port that part over to the
>> sasl-ldapdb module.
>>
>> The first option would certainly be easier. But the second more fun, maybe. :-)
>>
>> But what are - hypothetically -  the chances of getting that code - assuming it would be a few dozen lines in, say plugins/ldapdb.ch and maybe re-using parts
>> from lak.c - accepted in cyrus-sasl?
>>
>> Would some of the original developers and/or current maintainers  of the code in question be willing to assist in helping to collect all the information
>> required and drafting a design for a solution?
>>
>> - plugins/ldapdb.ch -> e.g. Howard Chu, Ken Murchison ?
>> - saslauthd/lak.c -> e.g. Igor Brezac, Rob Siemborski ?
> I am a current maintainer. My attention has been on other projects, had no idea the auxprop API had
> evolved to support hashed passwords. Sure, we can probably add that in. Though TBH, my purpose in
> writing ldapdb in the first place was to eliminate simple-password based login mechanisms. IMO it is
> more of a liability to have them traversing the wire than to have them stored inside OpenLDAP. Which
> is why I was only interested in supporting mechs like DIGEST-MD5 (and presumably now SCRAM).
>
> Be sure you understand what your threat model and actual threat environment is. When you support
> server-side hashed passwords that necessarily means your client is sending plaintext passwords to
> be validated by the server. IMO this is the worse risk. With the current ldapdb support, clients
> only send randomly generated nonces to the server, so the password itself never traverses the network.
>
> In general one can expect that clients are connecting over random untrusted networks, making
> transmitted passwords more of an easy target. And we assume that the sysadmin is competent enough to
> secure communication between the SASL service and the LDAP service.
>
Hello Howard. Thanks a ton for your inputs! I strongly agree that 
understanding the threat model is central here.

And I believe that in my case the better option would be to store 
securely hashed passwords on the server and send plain text over an 
encrypted protocol. Although this might not be a fully objective opinion 
and the advantage seems not to be huge.

Background: Almost a decade ago now, I have taken my time and set up a 
private dns, web, mail, *dav, (... rss aggregator, ... you name it) 
server. It is an assemblage of hand-selected products that work for me. 
And it is hosted in a kvm (so I believe) VM that I am renting by the 
month from hetzner.de for a small price (~ 7 euro / 4gb ram / 50gm 
disk). This has been and still is just a futile attempt to thwart the 
data hunger of the big 5 by not giving them mine. The data on that 
server is of course not really highly secure. But it is at least not as 
easily accessible to e.g. thousands of people at google as it would be 
on gmail.

To make a long story short, now the time has come to upgrade the OS and 
applications. Unfortunately, Apple's old "calendarserver" is dead, but 
fortunately, cyrus seems to be still kiking, and sporting the best *dav 
support there is -- according to Wikipedia 
https://en.wikipedia.org/wiki/Comparison_of_CalDAV_and_CardDAV_implementations#Server_implementations 
, no other implementation ticks as may boxes!

But let's get back to work. Some points to consider regarding the 
server/wire password "representations" - hashed/plain vs. plain/hashed:

1. I simply don't allow plain-text protocol connections to the server. 
So the client needs to do (START)TLS. And thus the connection to the 
server will be secure. --- I.e. I do expect clients to connect from 
wherever, but always over TLS.

2. Although many people seem to dream about it (I can't find the links 
right now - there is some scientific term for it as well), I do _not_ 
believe that it is even theoretically possible to do anything useful 
with encrypted data on an untrusted system. Thus the disk on the server 
can not be encrypted. And thus I trust the server hosting company to a 
certain extent. But at the same time I would really not want to have to 
trust the server hosting company _and_ myself _that much, i.e. in being 
able and having the resources, to set up a "really" secure system and 
protect it against all sorts of attacks *). Thus in the end I guess it 
would not be a very big effort to break into the server and gain root. 
And if the trust I put in the server hosting company is breached, they 
could also simply just do whatever with my data. To mitigate these 
threats (and to protect against hardware failure etc.), I am keeping 
off-site incremental backups of the server data. Now if it is corrupted 
- provided that I realize it quickly - I can simply restore a recent 
backup and be good. *) The attacks I have seen and fended off **) so 
far, are probably 100% automated, brute-force password guessing and 
application of known exploits. **) The one attack that managed to do 
some limited harm, was an automated attack on unmaintained Drupal 
installation. It installed a spam bot but was confined to the "apache" 
UID and I could simply delete the "virus" scripts when I found out.

3. Of course I do keep the TLS certificate's private keys on the server 
in plain text as well. But this is a different story, I believe.

4. Of course if an attacker breaks in, he can just wait and sniff the 
passwords the next time they are sent to the server. But I can somehow 
still maintain that nice feeling, that I might somehow find out fast 
enough and then "shut down" my clients as well as the server. As long as 
I just don't "tell" the password to the server when it is compromised, 
the attacker will not learn this central piece of information.

5. Central, of course, just because the password is re-used for other 
services. :-) And in fact at this point, it really dawns on me, that 
maybe I could just as well go the other route, as I have personally 
completely stopped doing this by now.

6. But then one threat still remains and that is the other accounts of 
the other users of the system, that they have potentially protected with 
the same passwords that they are using for my server. And in _any case, 
giving _immediate access to the complete list of plaintext passwords to 
an attacker, somehow certainly "sounds" much worse to me than if he has 
to wait in hiding and sniff those passwords from the incoming 
connections or bring some really big engines and start brute-forcing the 
hashes.


------------------------------------------
Cyrus: SASL
Permalink: https://cyrus.topicbox.com/groups/sasl/T2c60ca246b64197b-Mea20313247630dde5ed6a75c
Delivery options: https://cyrus.topicbox.com/groups/sasl/subscription