Feature request SCRAM-SHA-256

[Tributh]

Hi,
sorry for my late reply. Was too busy during the week.
Thank you for your patches. I hope I will be able with them to get now
some client support for SCRAM-SHA-256. Will report how I succeed in the
future.

Regards,

Torsten


On 07.01.19 20:31, Stephan Bosch wrote:
> 
> Op 16/12/2018 om 10:06 schreef Tributh via dovecot:
>>
>> Am 16.12.18 um 09:42 schrieb Aki Tuomi:
>>>> On 16 December 2018 at 10:27 Tributh via dovecot
>>>> <dovecot at 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.
> 
> 
> I looked a this a bit and since it is basically only a matter of
> replacing the hash algorithm, I created a quick implementation (after
> some refactoring):
> https://github.com/stephanbosch/dovecot-core/commits/auth-scram-sha-256
> 
> However, since there is no client that actually supports this, I cannot
> test this myself. I've briefly tested that the old SHA-1 still works
> (using mpop) and that the server properly announces the new mechanism
> when enabled, but that is it. It is based on the master branch.
> Configuration is identical to SCRAM-SHA-1, apart from the mechanism (and
> password scheme) name of course.
> 
> Don't expect this to be released or even merged to the master branch any
> time soon: this is likely currently very low on our priority list. But,
> at least you can run your own server with SCRAM-SHA-256 support (and so
> can client developers).  Maybe if this gets endorsed and supported by
> clients and gets some testing in the field, we can speed it along a bit,
> but that is not something I can promise.
> 
> So, I hatched a chick for you. I hope you can make it lay a few eggs in
> the future...
> 
> Regards,
> 
> Stephan.
> 
>