Support for multiple passwords?

[Rick Romero]

  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, 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.

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.