Quoting Reindl Harald <h.reindl at thelounge.net>:> Am 18.03.2015 um 20:56 schrieb Conrad Kostecki: >> Am 2015-03-18 20:46, schrieb Reindl Harald: >>> Am 18.03.2015 um 20:40 schrieb Conrad Kostecki: >>>> Hi! >>>> Currently, the passwords are stored in plaintext for my dovecot, as I >>>> am >>>> still using cram-md5 AND digest-md5. >>>> I have still to offer that, as I have some deprecated clients, >>>> therefore, I am unable to hash at least those passwords for that >>>> accounts. >>>> >>>> I've found on the Wiki: >>>>> In future it's possible that Dovecot could support multiple passwords >>>>> in different schemes for a single user. >>>> >>>> Is there any news about this? Are there still any plans to supportthis>>>> maybe in future? >>>> For my understanding, that would solve my problem, that I could >>>> define a >>>> password in both schemes (cram and digest) and don't have to use >>>> plaintext password? >>> >>> if you would read http://en.wikipedia.org/wiki/CRAM-MD5 and understand >>> how CRAM-MD5 works you would know that you just can't store cram >>> because the whole purpose is that it changes all the time >> >> Maybe I am totally wrong, >> but according to the Wiki, if I would be use using CRAM-MD5 without >> DIGEST-MD5, the password could be stored not in plain text but instead >> in a cram-md5 scheme? >> At least, that had worked for me in a test setup. But I will have alook.> > only in a broken and unsecure implementation - or how do you store > "arbitrary string of random digits, a timestamp"? > > http://en.wikipedia.org/wiki/CRAM-MD5 > > Challenge: The server sends a base64-encoded string to the client. > Before encoding, it could be any random string, but the standard that > currently defines CRAM-MD5 says that it is in the format of a Message-ID > email header value (including angle brackets) and includes an arbitrary > string of random digits, a timestamp, and the server's fully qualified > domain name. >Too much irrelevant information. Goal: Don't store cleartext passwords. Question: Do your clients support PLAIN authentication and SSL? The authentication method is (mostly) independent of the storage method. Only CRAM requires either a clear text password or Dovecot's CRAM 'cleartext workaround'. If you use PLAIN, then your passwords can be stored encrypted. If the clients support SSL, then you can require SSL/TLS and encrypt the password (and ALL the content) at the transport layer. Rick
Am 2015-03-18 21:10, schrieb Rick Romero:> Quoting Reindl Harald <h.reindl at thelounge.net>: > >> Am 18.03.2015 um 20:56 schrieb Conrad Kostecki: >>> Am 2015-03-18 20:46, schrieb Reindl Harald: >>>> Am 18.03.2015 um 20:40 schrieb Conrad Kostecki: >>>>> Hi! >>>>> Currently, the passwords are stored in plaintext for my dovecot, as >>>>> I >>>>> am >>>>> still using cram-md5 AND digest-md5. >>>>> I have still to offer that, as I have some deprecated clients, >>>>> therefore, I am unable to hash at least those passwords for that >>>>> accounts. >>>>> >>>>> I've found on the Wiki: >>>>>> In future it's possible that Dovecot could support multiple >>>>>> passwords >>>>>> in different schemes for a single user. >>>>> >>>>> Is there any news about this? Are there still any plans to support > this >>>>> maybe in future? >>>>> For my understanding, that would solve my problem, that I could >>>>> define a >>>>> password in both schemes (cram and digest) and don't have to use >>>>> plaintext password? >>>> >>>> if you would read http://en.wikipedia.org/wiki/CRAM-MD5 and >>>> understand >>>> how CRAM-MD5 works you would know that you just can't store cram >>>> because the whole purpose is that it changes all the time >>> >>> Maybe I am totally wrong, >>> but according to the Wiki, if I would be use using CRAM-MD5 without >>> DIGEST-MD5, the password could be stored not in plain text but >>> instead >>> in a cram-md5 scheme? >>> At least, that had worked for me in a test setup. But I will have a > look. >> >> only in a broken and unsecure implementation - or how do you store >> "arbitrary string of random digits, a timestamp"? >> >> http://en.wikipedia.org/wiki/CRAM-MD5 >> >> Challenge: The server sends a base64-encoded string to the client. >> Before encoding, it could be any random string, but the standard that >> currently defines CRAM-MD5 says that it is in the format of a >> Message-ID >> email header value (including angle brackets) and includes an >> arbitrary >> string of random digits, a timestamp, and the server's fully qualified >> domain name. >> > > Too much irrelevant information. Goal: Don't store cleartext > passwords. > > Question: Do your clients support PLAIN authentication and SSL?Not all. I know, that this just sucks in the year 2015.> If you use PLAIN, then your passwords can be stored encrypted. If the > clients support SSL, then you can require SSL/TLS and encrypt the > password (and ALL the content) at the transport layer.That's what I am planning. Only enable PLAIN and force SSL/TLS. I hope, that till end of the year, I can shutdown that finally and switch to force SSL/TLS and disable CRAM-MD5/DIGEST-MD5, so my passwords can be encrypted.
Quoting Conrad Kostecki <ck+dovecot at bl4ckb0x.de>:> Am 2015-03-18 21:10, schrieb Rick Romero: >> Quoting Reindl Harald <h.reindl at thelounge.net>: >> >>> Am 18.03.2015 um 20:56 schrieb Conrad Kostecki: >>>> Am 2015-03-18 20:46, schrieb Reindl Harald: >>>>> Am 18.03.2015 um 20:40 schrieb Conrad Kostecki: >>>>>> Hi! >>>>>> Currently, the passwords are stored in plaintext for my dovecot, asI>>>>>> am >>>>>> still using cram-md5 AND digest-md5. >>>>>> I have still to offer that, as I have some deprecated clients, >>>>>> therefore, I am unable to hash at least those passwords for that >>>>>> accounts. >>>>>> >>>>>> I've found on the Wiki: >>>>>>> In future it's possible that Dovecot could support multiple >>>>>>> passwords >>>>>>> in different schemes for a single user. >>>>>> >>>>>> Is there any news about this? Are there still any plans to support >> >> this >>>>>> maybe in future? >>>>>> For my understanding, that would solve my problem, that I could >>>>>> define a >>>>>> password in both schemes (cram and digest) and don't have to use >>>>>> plaintext password? >>>>> >>>>> if you would read http://en.wikipedia.org/wiki/CRAM-MD5 andunderstand>>>>> how CRAM-MD5 works you would know that you just can't store cram >>>>> because the whole purpose is that it changes all the time >>>> >>>> Maybe I am totally wrong, >>>> but according to the Wiki, if I would be use using CRAM-MD5 without >>>> DIGEST-MD5, the password could be stored not in plain text but instead >>>> in a cram-md5 scheme? >>>> At least, that had worked for me in a test setup. But I will have a >> >> look. >>> only in a broken and unsecure implementation - or how do you store >>> "arbitrary string of random digits, a timestamp"? >>> >>> http://en.wikipedia.org/wiki/CRAM-MD5 >>> >>> Challenge: The server sends a base64-encoded string to the client. >>> Before encoding, it could be any random string, but the standard that >>> currently defines CRAM-MD5 says that it is in the format of aMessage-ID>>> email header value (including angle brackets) and includes an arbitrary >>> string of random digits, a timestamp, and the server's fully qualified >>> domain name. >> >> Too much irrelevant information.? Goal: Don't store cleartextpasswords.>> >> Question: Do your clients support PLAIN authentication and SSL? > > Not all. I know, that this just sucks in the year 2015. > >> If you use PLAIN, then your passwords can be stored encrypted.? If the >> clients support SSL, then you can require SSL/TLS and encrypt the >> password (and ALL the content) at the transport layer. > > That's what I am planning. Only enable PLAIN and force SSL/TLS.I hope, > that till end of the year, I can shutdown that finally and switch to > force SSL/TLS and disable CRAM-MD5/DIGEST-MD5, so my passwords can be > encrypted.Depending on your options, this could be a good stop-gap solution: https://www.stunnel.org/downloads.html Use stunnel to establish the encrypted connection between the client PC and your server, then the client connects to localhost.