MD5-CRYPT/CRAM-MD5 vs SHA512-CRYPT/PLAIN
Hello,
I am wondering which variant is more secure for user authentication and password scheme. Basically I am looking at both variants:
- MD5-CRYPT password scheme storage with CRAM-MD5 auth mechanism
- SHA512-CRYPT password scheme storage with PLAIN auth mechanism
In my opinion the option 2) should be safer although it is using PLAIN auth mechanism. Of course I would always use STARTTLS and not allow unencrypted connection.
What is your opinion?
Best, ML
On 12/5/2014 3:24 AM, ML mail wrote:
Hello,
I am wondering which variant is more secure for user authentication and password scheme. Basically I am looking at both variants:
- MD5-CRYPT password scheme storage with CRAM-MD5 auth mechanism
- SHA512-CRYPT password scheme storage with PLAIN auth mechanism
In my opinion the option 2) should be safer although it is using PLAIN auth mechanism. Of course I would always use STARTTLS and not allow unencrypted connection.
What is your opinion?
Option 2 without hesitation.
MD5-CRYPT:
- is extremely weak
- was phased out as the default password hash long ago
- needs to die out
CRAM-MD5:
- is either redundant or insufficient
- is not universally supported
- limits your authentication backend options
On 12/5/14, ML mail mlnospam@yahoo.com wrote:
Hello,
I am wondering which variant is more secure for user authentication and password scheme. Basically I am looking at both variants:
- MD5-CRYPT password scheme storage with CRAM-MD5 auth mechanism
- SHA512-CRYPT password scheme storage with PLAIN auth mechanism
In my opinion the option 2) should be safer although it is using PLAIN auth mechanism. Of course I would always use STARTTLS and not allow unencrypted connection.
Thats not exactly a true statement, if you offer STARTTLS you are optional on encryption, if you mean not allow unencrypted connections then you are forcing TLS, not STARTTLS since the latter is designed to accept unencrypted and then _try_ upgrade to encryption if possible, if not, stay unencrypted.
What is your opinion?
Number 2 as the other poster said without hesitation and for reasons he said
On 12/06/2014 02:35 AM, Nick Edwards wrote:
On 12/5/14, ML mail mlnospam@yahoo.com wrote:
Hello,
I am wondering which variant is more secure for user authentication and password scheme. Basically I am looking at both variants:
- MD5-CRYPT password scheme storage with CRAM-MD5 auth mechanism
- SHA512-CRYPT password scheme storage with PLAIN auth mechanism
In my opinion the option 2) should be safer although it is using PLAIN auth mechanism. Of course I would always use STARTTLS and not allow unencrypted connection.
Thats not exactly a true statement, if you offer STARTTLS you are optional on encryption, if you mean not allow unencrypted connections then you are forcing TLS, not STARTTLS since the latter is designed to accept unencrypted and then _try_ upgrade to encryption if possible, if not, stay unencrypted.
If you add disable_plaintext_auth=yes ssl=required settings, then dovecot will drop authentication without STARTTLS. But damage will be done, client will send unencrypted (or in this scenario MD5 or SHA512 hash) login/password. http://wiki2.dovecot.org/SSL
What is your opinion?
Number 2 as the other poster said without hesitation and for reasons he said +1
-- Jan Wideł Senior System Administrator e-mail: jan.widel@networkers.pl mobile: +48 797 004 946 www: http://www.networkers.pl GPG: http://networkers.pl/GPG/2E7359CD.asc
Am 06.12.2014 um 06:56 schrieb Jan Wideł:
If you add disable_plaintext_auth=yes ssl=required settings, then dovecot will drop authentication without STARTTLS. But damage will be done, client will send unencrypted (or in this scenario MD5 or SHA512 hash) login/password
no, damage will *not* be done
STARTTLS happens in context of connect and *log before* any authentication is tried the handshake between client/server fails
Am 6. Dezember 2014 13:10:58 MEZ, schrieb Reindl Harald h.reindl@thelounge.net:
Am 06.12.2014 um 06:56 schrieb Jan Wideł:
If you add disable_plaintext_auth=yes ssl=required settings, then dovecot will drop authentication without STARTTLS. But damage will be done, client will send unencrypted (or in this scenario MD5 or SHA512 hash) login/password
no, damage will *not* be done
STARTTLS happens in context of connect and *log before* any authentication is tried the handshake between client/server fails
If the client is misconfigured to not strictly require STARTTLS, but to allow plaintext authentication too, and some man in the middle strips the STARTTLS capability from the server capability message, then the client will probably send its password login attempt in plaintext, without even trying to establish a STARTTLS session, because the server seemed to be incapable of STARTTLS.
So you might need to teach your users to enforce STARTTLS in their email client in order to mitigate MITM attacks.
Regards Daniel
Am 06.12.2014 um 14:40 schrieb Daniel Parthey:
Am 6. Dezember 2014 13:10:58 MEZ, schrieb Reindl Harald h.reindl@thelounge.net:
Am 06.12.2014 um 06:56 schrieb Jan Wideł:
If you add disable_plaintext_auth=yes ssl=required settings, then dovecot will drop authentication without STARTTLS. But damage will be done, client will send unencrypted (or in this scenario MD5 or SHA512 hash) login/password
no, damage will *not* be done
STARTTLS happens in context of connect and *log before* any authentication is tried the handshake between client/server fails
If the client is misconfigured to not strictly require STARTTLS, but to allow plaintext authentication too, and some man in the middle strips the STARTTLS capability from the server capability message, then the client will probably send its password login attempt in plaintext, without even trying to establish a STARTTLS session, because the server seemed to be incapable of STARTTLS.
So you might need to teach your users to enforce STARTTLS in their email client in order to mitigate MITM attacks
that's so far true but:
if you require STARTTLS try to setup the account without TLS fails while "not strictly require STARTTLS" is a issue of the past where Thunderbird offered "TLS if available"
so that MITM needs to happen in the timeframe where the user configures the account the first time not chose STARTTLS
after the account was configured that MITM is no longer possible
MITM which strips STARTTLS is more an issue in case of opportunistic TLS between MTA's
frankly i still don't understand the stupidity of deprecate 465 in favor of STARTTLS instead use 465/993/995 in context of mail-clients which would "MITM strip away STARTTLS" not make possible at all
from a straight technical point of view the only *real* use-case for STARTTLS ist MTA-to-MTA on Port 25 which don't send credentials at all
W dniu 2014-12-06 13:10, Reindl Harald napisał(a):
Am 06.12.2014 um 06:56 schrieb Jan Wideł:
If you add disable_plaintext_auth=yes ssl=required settings, then dovecot will drop authentication without STARTTLS. But damage will be done, client will send unencrypted (or in this scenario MD5 or SHA512 hash) login/password
no, damage will *not* be done
STARTTLS happens in context of connect and *log before* any authentication is tried the handshake between client/server fails
Yes, of course you are right. I meant that client is misconfigured by forced not to use TLS.
-- Jan Wideł Senior System Administrator e-mail: jan.widel@networkers.pl mobile: +48 797 004 946 www: http://www.networkers.pl GPG: http://networkers.pl/GPG/2E7359CD.asc
participants (6)
-
Daniel Parthey
-
Darren Pilgrim
-
Jan Wideł
-
ML mail
-
Nick Edwards
-
Reindl Harald