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?
Cheers Conrad
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
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.
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
Quoting Reindl Harald h.reindl@thelounge.net:
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
Am 18.03.2015 um 20:56 schrieb Conrad Kostecki: 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?
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@thelounge.net:
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
Am 18.03.2015 um 20:56 schrieb Conrad Kostecki: 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@bl4ckb0x.de:
Quoting Reindl Harald h.reindl@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
Am 2015-03-18 21:10, schrieb Rick Romero: 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.
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.
participants (3)
-
Conrad Kostecki
-
Reindl Harald
-
Rick Romero