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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021-11-7 01:45, Patrick Pfeifer via SASL wrote:
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.

7. One advantage of the hashed-on-the-server approach is, that I do not need to change the passwords if the server data is "stolen". I also do not need to worry much about encrypting the backups. Or the server hosting company accidentally publishing the server image on the internet. There is simply not much value in it. This saves me a lot of worries.


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




[Index of Archives]     [Info Cyrus]     [Squirrel Mail]     [Linux Media]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux