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 timeMaybe 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.> http://wiki.dovecot.org/Authentication/PasswordSchemes > For example if you're going to use CRAM-MD5 authentication, the > password needs to be stored in either PLAIN or CRAM-MD5 scheme.Cheers Conrad
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.>> http://wiki.dovecot.org/Authentication/PasswordSchemes >> For example if you're going to use CRAM-MD5 authentication, the >> password needs to be stored in either PLAIN or CRAM-MD5 scheme-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20150318/753ee944/attachment.sig>
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