Re: Feature request SCRAM-SHA-256
On 16 December 2018 at 10:27 Tributh via dovecot <dovecot@dovecot.org> wrote:
Hi, is that here the right place to make feature requests?
dovecot supports as authentication mechanism SCRAM-SHA-1 from RFC 5802 which was updated to SCRAM-SHA-256 in RFC 7677
Can SCRAM-SHA-256 be added to the authentication mechanisms?
I would not like to request, that SCRAM-SHA-1 will be exchanged by SCRAM-SHA-256, since several applications only support SCRAM-SHA-1
Regards
Torsten
Hi!
Adding this is possible, it can even be done as a separate plugin. But I have to ask, why? Do you actually have clients that support this?
Aki
Am 16.12.18 um 09:42 schrieb Aki Tuomi:
On 16 December 2018 at 10:27 Tributh via dovecot <dovecot@dovecot.org> wrote:
Hi, is that here the right place to make feature requests?
dovecot supports as authentication mechanism SCRAM-SHA-1 from RFC 5802 which was updated to SCRAM-SHA-256 in RFC 7677
Can SCRAM-SHA-256 be added to the authentication mechanisms?
I would not like to request, that SCRAM-SHA-1 will be exchanged by SCRAM-SHA-256, since several applications only support SCRAM-SHA-1
Regards
Torsten
Hi!
Adding this is possible, it can even be done as a separate plugin. But I have to ask, why? Do you actually have clients that support this?
Aki
Hi Aki, let me first answer the second question. Sadly I have no client which supports it, yet. Here we have a chicken or the egg causality dilemma. There was some communication with mail-client developers which stated that they would start developing it, when they have a publicly usable server to test against. Now I hope that the most common IMAP server could be the one, which gives this possibility. Sadly, most communication is not publicly available.
In the past CRAM-MD5 was very popular. When the insecurity came out, everything just shifted to TLS, but that prevented not from sending a plain password now. If a malicious actor is able to change DNS/TLS endpoints, he will receive the plain passwords immediately. I am not the expert in explaining how such an actor could do this. I just wanted to have possibilities for everybody to prevent this possible exposure of a plain password, which could than easily used abusively.
I just hope for better security in the future.
Regards Torsten
participants (2)
-
Aki Tuomi
-
Tributh