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
