Howdy,
I'm using dovecot and mysql users, and i'm creating the password with:
ENCRYPT('some-passwd',CONCAT('$6$', SUBSTRING(SHA(RAND()), -16)))
So far so good, everything's fine. Today saw that i didn't enabled CRAM-MD5, but if I do, and the (at least) IMAP client (roundcube/thunderbird/etc) issues CRAM-MD5 it doesn't authenticate. What am i doing wrong, or that can be done so that all types work (SASL PLAIN LOGIN + CRAM-MD5)?
Thanks in advanced,
On 18 Jun 2019, at 16:04, Jorge Bastos via dovecot dovecot@dovecot.org wrote:
I'm using dovecot and mysql users, and i'm creating the password with:
ENCRYPT('some-passwd',CONCAT('$6$', SUBSTRING(SHA(RAND()), -16)))
Why not just use the builtin tool in dovecot?
doveadm pw -s SHA256-CRYPT -p ‘password[goes]here!’
(or SHA512-CRYPT in your case, I guess).
So far so good, everything's fine. Today saw that i didn't enabled CRAM-MD5
Why would you?
, but if I do, and the (at least) IMAP client (roundcube/thunderbird/etc) issues CRAM-MD5 it doesn't authenticate. What am i doing wrong, or that can be done so that all types work (SASL PLAIN LOGIN + CRAM-MD5)?
What is the reason for wanting to enable CRAM-MD5? That was intended to use on unsecured connections; you should not be allowing authentication on unsecured connections in 2019.
Establish a secure submission on port 587 or smtps on 465 and do not use CRAM-MD5 at all.
-- "Part of the inhumanity of the computer is that, once it is competently programmed and working smoothly, it is completely honest." - Isaac Asimov
On Tue, 18 Jun 2019 16:41:06 -0600 "@lbutlr via dovecot" dovecot@dovecot.org wrote:
What is the reason for wanting to enable CRAM-MD5? That was intended to use on unsecured connections; you should not be allowing authentication on unsecured connections in 2019.
Establish a secure submission on port 587 or smtps on 465 and do not use CRAM-MD5 at all.
Possibly a backwards compatibility thing? (eg: legacy mail settings migrating to a new dovecot server). It get's difficult to argue the need for changing settings en-masse to a full customer base all at once ...
For a while iPhones wanted to default to CRAM-MD5 as well...
On 18 Jun 2019, at 16:56, Shaun Johnson via dovecot dovecot@dovecot.org wrote:
On Tue, 18 Jun 2019 16:41:06 -0600 "@lbutlr via dovecot" dovecot@dovecot.org wrote:
What is the reason for wanting to enable CRAM-MD5? That was intended to use on unsecured connections; you should not be allowing authentication on unsecured connections in 2019.
Establish a secure submission on port 587 or smtps on 465 and do not use CRAM-MD5 at all.
Possibly a backwards compatibility thing?
I don’t see how, it should never have been enabled on a secure connection, so there’s nothing to be compatible with.
For a while iPhones wanted to default to CRAM-MD5 as well…
Only for insecure connections as I recall.
I can’t think of any reason for using CRAM-MD5 with STARTTLS on submission or secured smtps. YMMV, but it offers absolutely no advantage to secure authentication.
-- All our loves are first loves
Am 19.06.2019 um 00:04 schrieb Jorge Bastos via dovecot:
Howdy,
I'm using dovecot and mysql users, and i'm creating the password with:
ENCRYPT('some-passwd',CONCAT('$6$', SUBSTRING(SHA(RAND()), -16)))
So far so good, everything's fine. Today saw that i didn't enabled CRAM-MD5, but if I do, and the (at least) IMAP client (roundcube/thunderbird/etc) issues CRAM-MD5 it doesn't authenticate. What am i doing wrong, or that can be done so that all types work (SASL PLAIN LOGIN + CRAM-MD5)?
Thanks in advanced,
For shared secret mechanisms like CRAM-MD5 to work the password must be stored in plaintext AFAIK. That's a good reason not to offer that.
Alexander
On 19.6.2019 7.48, Alexander Dalloz via dovecot wrote:
Am 19.06.2019 um 00:04 schrieb Jorge Bastos via dovecot:
Howdy,
I'm using dovecot and mysql users, and i'm creating the password with:
ENCRYPT('some-passwd',CONCAT('$6$', SUBSTRING(SHA(RAND()), -16)))
So far so good, everything's fine. Today saw that i didn't enabled CRAM-MD5, but if I do, and the (at least) IMAP client (roundcube/thunderbird/etc) issues CRAM-MD5 it doesn't authenticate. What am i doing wrong, or that can be done so that all types work (SASL PLAIN LOGIN + CRAM-MD5)?
Thanks in advanced,
For shared secret mechanisms like CRAM-MD5 to work the password must be stored in plaintext AFAIK. That's a good reason not to offer that.
Alexander
CRAM-MD5 can also be stored as stage 1 MD5 hashed blob. Only marginally better than plaintext. But as pointed out, CRAM-MD5, DIGEST-MD5 cannot work with crypted passwords. If you want to use "secure passwords", SCRAM-SHA1 is an option, but probably best is to disable other than 'PLAIN' and 'LOGIN' mech unless you know what you are doing.
Aki
Howdy,
Answering all, so cram-md5 is old, don't want then! I only noticed thunderbird as default using this, so, won't implement it!
Thanks for the clarify,
-----Original Message----- From: dovecot dovecot-bounces@dovecot.org On Behalf Of Aki Tuomi via dovecot Sent: 19 de junho de 2019 07:31 To: Alexander Dalloz ad+lists@uni-x.org; dovecot@dovecot.org Subject: Re: Help on CRAM-MD5
On 19.6.2019 7.48, Alexander Dalloz via dovecot wrote:
Am 19.06.2019 um 00:04 schrieb Jorge Bastos via dovecot:
Howdy,
I'm using dovecot and mysql users, and i'm creating the password with:
ENCRYPT('some-passwd',CONCAT('$6$', SUBSTRING(SHA(RAND()), -16)))
So far so good, everything's fine. Today saw that i didn't enabled CRAM-MD5, but if I do, and the (at least) IMAP client (roundcube/thunderbird/etc) issues CRAM-MD5 it doesn't authenticate. What am i doing wrong, or that can be done so that all types work (SASL PLAIN LOGIN + CRAM-MD5)?
Thanks in advanced,
For shared secret mechanisms like CRAM-MD5 to work the password must be stored in plaintext AFAIK. That's a good reason not to offer that.
Alexander
CRAM-MD5 can also be stored as stage 1 MD5 hashed blob. Only marginally better than plaintext. But as pointed out, CRAM-MD5, DIGEST-MD5 cannot work with crypted passwords. If you want to use "secure passwords", SCRAM-SHA1 is an option, but probably best is to disable other than 'PLAIN' and 'LOGIN' mech unless you know what you are doing.
Aki
Hello,
The world is not black or white. Yes CRAM-MD5 is old and his successor SCRAM-XXXXXX is not widely available/implemented which is sad. For your need, use TLS and forget about it. Thunderbird is conservative. If you don't configure TLS or TLS is not available, it try to use something that not expose the password. There is plenty of context where TLS is not possible/desirable. And without client certificate, mutual strong authentication is not available, but could be with TLS+SCRAM. There is plenty of room for SASL mech other than PLAIN/LOGIN. It just not fit your actual needs. Just be sure to not allow PLAIN/LOGIN in clear.
Emmanuel.
Le 19/06/2019 à 18:58, Jorge Bastos via dovecot a écrit :
Howdy,
Answering all, so cram-md5 is old, don't want then! I only noticed thunderbird as default using this, so, won't implement it!
Thanks for the clarify,
-----Original Message----- From: dovecot dovecot-bounces@dovecot.org On Behalf Of Aki Tuomi via dovecot Sent: 19 de junho de 2019 07:31 To: Alexander Dalloz ad+lists@uni-x.org; dovecot@dovecot.org Subject: Re: Help on CRAM-MD5
On 19.6.2019 7.48, Alexander Dalloz via dovecot wrote:
Am 19.06.2019 um 00:04 schrieb Jorge Bastos via dovecot:
Howdy,
I'm using dovecot and mysql users, and i'm creating the password with:
ENCRYPT('some-passwd',CONCAT('$6$', SUBSTRING(SHA(RAND()), -16)))
So far so good, everything's fine. Today saw that i didn't enabled CRAM-MD5, but if I do, and the (at least) IMAP client (roundcube/thunderbird/etc) issues CRAM-MD5 it doesn't authenticate. What am i doing wrong, or that can be done so that all types work (SASL PLAIN LOGIN + CRAM-MD5)?
Thanks in advanced,
For shared secret mechanisms like CRAM-MD5 to work the password must be stored in plaintext AFAIK. That's a good reason not to offer that.
Alexander
CRAM-MD5 can also be stored as stage 1 MD5 hashed blob. Only marginally better than plaintext. But as pointed out, CRAM-MD5, DIGEST-MD5 cannot work with crypted passwords. If you want to use "secure passwords", SCRAM-SHA1 is an option, but probably best is to disable other than 'PLAIN' and 'LOGIN' mech unless you know what you are doing.
Aki
Hi Emanuel,
I understand what you said. Users have access to SSL and TLS so it's fine, it's their options to use or not. Thanks for the help from all,
-----Original Message----- From: dovecot dovecot-bounces@dovecot.org On Behalf Of FUSTE Emmanuel via dovecot Sent: Thursday, June 20, 2019 9:53 To: dovecot@dovecot.org Subject: Re: Help on CRAM-MD5
Hello,
The world is not black or white. Yes CRAM-MD5 is old and his successor SCRAM-XXXXXX is not widely available/implemented which is sad. For your need, use TLS and forget about it. Thunderbird is conservative. If you don't configure TLS or TLS is not available, it try to use something that not expose the password. There is plenty of context where TLS is not possible/desirable. And without client certificate, mutual strong authentication is not available, but could be with TLS+SCRAM. There is plenty of room for SASL mech other than PLAIN/LOGIN. It just not fit your actual needs. Just be sure to not allow PLAIN/LOGIN in clear.
Emmanuel.
Le 19/06/2019 à 18:58, Jorge Bastos via dovecot a écrit :
Howdy,
Answering all, so cram-md5 is old, don't want then! I only noticed thunderbird as default using this, so, won't implement it!
Thanks for the clarify,
-----Original Message----- From: dovecot dovecot-bounces@dovecot.org On Behalf Of Aki Tuomi via dovecot Sent: 19 de junho de 2019 07:31 To: Alexander Dalloz ad+lists@uni-x.org; dovecot@dovecot.org Subject: Re: Help on CRAM-MD5
On 19.6.2019 7.48, Alexander Dalloz via dovecot wrote:
Am 19.06.2019 um 00:04 schrieb Jorge Bastos via dovecot:
Howdy,
I'm using dovecot and mysql users, and i'm creating the password with:
ENCRYPT('some-passwd',CONCAT('$6$', SUBSTRING(SHA(RAND()), -16)))
So far so good, everything's fine. Today saw that i didn't enabled CRAM-MD5, but if I do, and the (at least) IMAP client (roundcube/thunderbird/etc) issues CRAM-MD5 it doesn't authenticate. What am i doing wrong, or that can be done so that all types work (SASL PLAIN LOGIN + CRAM-MD5)?
Thanks in advanced,
For shared secret mechanisms like CRAM-MD5 to work the password must be stored in plaintext AFAIK. That's a good reason not to offer that.
Alexander
CRAM-MD5 can also be stored as stage 1 MD5 hashed blob. Only marginally better than plaintext. But as pointed out, CRAM-MD5, DIGEST-MD5 cannot work with crypted passwords. If you want to use "secure passwords", SCRAM-SHA1 is an option, but probably best is to disable other than 'PLAIN' and 'LOGIN' mech unless you know what you are doing.
Aki
On 20 Jun 2019, at 02:53, FUSTE Emmanuel via dovecot dovecot@dovecot.org wrote:
There is plenty of context where TLS is not possible/desirable.
I’d say that is terrible advice. There are no reasonable contexts where is it is acceptable to send mail credentials without encryption. My users have had to use STARTTLS for submission for many many years. Insecure connections from users are not an option.
And without client certificate, mutual strong authentication is not available,
For certain values of strong, sure. But nearly no one needs mutual strong authentication to the level that client certs are necessary, and if someone does need them, then that is not a significant hurdle. And the connections are still encrypted.
*ALL* user to server transactions should be encrypted and nothing should be willfully downgrading security in the flawed reasoning of convenience. That is why we have as many security issue as we do right now; we are still living down the legacy of the previous century’s lack of security at ever stage in design.
-- Yeah, Nick. Nick's the kinda guy you can trust. Nick's your buddy Nick's the kinda guy you drink beers with. The kinda guy that doesn't care if you puke in his car. Nick.
I don't desagree with your vision, but if the use of CRAM-XXXX has to use plaint text password's on the server there's a dark side, or there's a CRAM-XXX that can use encrypted on server side? There's always the thing that can clients don't support it. I think i'm not wrong with what i said,
On 20 Jun 2019, at 02:53, FUSTE Emmanuel via dovecot dovecot@dovecot.org wrote:
There is plenty of context where TLS is not possible/desirable.
I'd say that is terrible advice. There are no reasonable contexts where is it is acceptable to send mail credentials without encryption. My users have had to use STARTTLS for submission for many many years. Insecure connections from users are not an option.
And without client certificate, mutual strong authentication is not available,
For certain values of strong, sure. But nearly no one needs mutual strong authentication to the level that client certs are necessary, and if someone does need them, then that is not a significant hurdle. And the connections are still encrypted.
*ALL* user to server transactions should be encrypted and nothing should be willfully downgrading security in the flawed reasoning of convenience. That is why we have as many security issue as we do right now; we are still living down the legacy of the previous century's lack of security at ever stage in design.
-- Yeah, Nick. Nick's the kinda guy you can trust. Nick's your buddy Nick's the kinda guy you drink beers with. The kinda guy that doesn't care if you puke in his car. Nick.
On 20 Jun 2019, at 04:14, Jorge Bastos via dovecot dovecot@dovecot.org wrote:
I don't desagree with your vision, but if the use of CRAM-XXXX has to use plaint text password's on the server there's a dark side, or there's a CRAM-XXX that can use encrypted on server side? There's always the thing that can clients don't support it.
The “encrypted” password store that CRAM-MD5 supports is MD5 which cannot be classified as encryption at this point.
Not sure why you are saying CRAM-XXX as there is only CRAM-MD5.
-- Lead me not into temptation, I can find the way.
Le 20/06/2019 à 12:25, @lbutlr via dovecot a écrit :
On 20 Jun 2019, at 04:14, Jorge Bastos via dovecot dovecot@dovecot.org wrote:
I don't desagree with your vision, but if the use of CRAM-XXXX has to use plaint text password's on the server there's a dark side, or there's a CRAM-XXX that can use encrypted on server side? There's always the thing that can clients don't support it. The “encrypted” password store that CRAM-MD5 supports is MD5 which cannot be classified as encryption at this point.
Not sure why you are saying CRAM-XXX as there is only CRAM-MD5.
I think he is referring to my reference to SCRAM-XXX class of mech.
Emmanuel & Ibutlr,
I meant to say something-MD5, my fault,
-----Original Message----- From: dovecot dovecot-bounces@dovecot.org On Behalf Of FUSTE Emmanuel via dovecot Sent: Thursday, June 20, 2019 11:32 To: dovecot@dovecot.org Subject: Re: Help on CRAM-MD5
Le 20/06/2019 à 12:25, @lbutlr via dovecot a écrit :
On 20 Jun 2019, at 04:14, Jorge Bastos via dovecot dovecot@dovecot.org wrote:
I don't desagree with your vision, but if the use of CRAM-XXXX has to use plaint text password's on the server there's a dark side, or there's a CRAM-XXX that can use encrypted on server side? There's always the thing that can clients don't support it. The “encrypted” password store that CRAM-MD5 supports is MD5 which cannot be classified as encryption at this point.
Not sure why you are saying CRAM-XXX as there is only CRAM-MD5.
I think he is referring to my reference to SCRAM-XXX class of mech.
Le 20/06/2019 à 11:59, @lbutlr via dovecot a écrit :
On 20 Jun 2019, at 02:53, FUSTE Emmanuel via dovecot dovecot@dovecot.org wrote:
There is plenty of context where TLS is not possible/desirable. I’d say that is terrible advice. There are no reasonable contexts where is it is acceptable to send mail credentials without encryption. My users have had to use STARTTLS for submission for many many years. Insecure connections from users are not an option. Please, don't make me say what I did not say. I use the word "context". I did not talk about "sending mail credentials" no more I talk about Internet. And even with that, don't restrict the world as your use case .The world is not Internet only too. And SASL and by extend the CRAM-MD5 mech is not used only in email scenario/protocols.
Even in email scenario, I have to deal with equipments (scanner/copiers) not able to do TLS or not able to deal with a private CA and insisting to verify the SMTP server Cert to send email, or with broken or outdated SSL implementation etc ... They support CRAM-MD5. It is still better than clear text. I have more than 4000 of such class of equipments behind my servers each having their problems, bugs, limitations.... Yes in 2019 ... I even don't talk you about the thousands of proprietary, outdated, customs, buggy (and combine all as you want) applications that I have to deal with....
Emmanuel.
Am 20.06.2019 um 12:28 schrieb FUSTE Emmanuel via dovecot:
Le 20/06/2019 à 11:59, @lbutlr via dovecot a écrit :
On 20 Jun 2019, at 02:53, FUSTE Emmanuel via dovecot dovecot@dovecot.org wrote:
There is plenty of context where TLS is not possible/desirable. I’d say that is terrible advice. There are no reasonable contexts where is it is acceptable to send mail credentials without encryption. My users have had to use STARTTLS for submission for many many years. Insecure connections from users are not an option. Please, don't make me say what I did not say. I use the word "context". I did not talk about "sending mail credentials" no more I talk about Internet. And even with that, don't restrict the world as your use case .The world is not Internet only too. And SASL and by extend the CRAM-MD5 mech is not used only in email scenario/protocols.
Even in email scenario, I have to deal with equipments (scanner/copiers) not able to do TLS or not able to deal with a private CA and insisting to verify the SMTP server Cert to send email, or with broken or outdated SSL implementation etc ... They support CRAM-MD5. It is still better than clear text. I have more than 4000 of such class of equipments behind my servers each having their problems, bugs, limitations.... Yes in 2019 ... I even don't talk you about the thousands of proprietary, outdated, customs, buggy (and combine all as you want) applications that I have to deal with....
Emmanuel.
Hopefully we all remember the big hacks where masses of unencrypted or at least unsufficiently secured credentials were stolen. That's what I worry about and why CRAM-MD5 is no wise choice at all.
Alexander
participants (7)
-
＠lbutlr
-
Aki Tuomi
-
Alexander Dalloz
-
Benny Pedersen
-
FUSTE Emmanuel
-
Jorge Bastos
-
Shaun Johnson