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.
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. > >
Op 07/01/2019 om 20:31 schreef Stephan Bosch:> > 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...Tracked internally as DOP-840. Regards, Stephan.