Support for multiple passwords?

Conrad Kostecki
Wed, 18 Mar 2015 20:56:01 -0000

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.