Support for multiple passwords?

[Conrad Kostecki]

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.