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
