The passwords are not being stored in plain text in the db but they can
be visible in the logs. Disabling the logs won't help in my case as an
attacker can reenable logging if the system gets compromised and grab
all passwords from there. Dovecot docs describe it like this:
DO NOT use password directly. It can contain % which is interpreted as
variable expansion and can cause errors. Also, it might be visible in
debug logging. Suggested approaches are base64 encoding, hex encoding or
hashing the password. With hashing, you get the extra benefit that
password won’t be directly visible in logs.
So, how to perform this hashing? At which point it has to be done?
On 2022-10-08 11:05, Odhiambo Washington wrote:
On Fri, Oct 7, 2022 at 10:31 PM Serveria Support <users@sogo.nu>
wrote:
Hi,
Yes, you're totally right my friend! I was just desperate because I
needed help and the other thread was getting replies while mine
wasn't.
Sorry about that.
Anyway, you're my savior as I have double checked everything as you
have
suggested and indeed the encryption algo was different in dovecot
config. Dovecot had sha512-crypt while SOGO tried to use ssha512.
I'm
not sure how this is possible as I have checked everything billions
of
times and I was 100% sure the same algo is in both configs. I have
changed ssha512 to sha512-crypt in dovecot config and voila: I'm
able to
login into SOGO. Thanks again!
P.S. By any chance you know how to prevent plain text passwords from
appearing in the logs? It kinda makes all my efforts useless and
defeats
the whole encrypted storage concept...
If you are storing passwords in plaintext in your DB, that's one thing
you should think about.
As regards your question, just disable all debugging from
10-logging.conf (dovecot).
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)