BUG: nopassword doesn't work with CRAM-MD5

[Aki Tuomi]

On 17.11.2016 10:49, Adrian POPA wrote:
> On 17.11.2016 10:30, Arkadiusz Miśkiewicz wrote:
>> On Thursday 17 of November 2016, Aki Tuomi wrote:
>>> On 17.11.2016 10:14, Arkadiusz Miśkiewicz wrote:
>>>> Hello.
>>>>
>>>> dovecot 2.2.26.0
>>>>
>>>> When testing nopassword extra field
>>>> (http://wiki2.dovecot.org/PasswordDatabase/ExtraFields) with CRAM-MD5
>>>> dovecot doesn't allow any password (while it should) and returns
>>>>
>>>> " Authentication failed"
>>>>
>>>> while in logs:
>>>>
>>>> Nov 17 08:22:34 auth-worker(1551): Info:
>>>> sql(pepe,127.0.0.1,<Y8amDXpBptV/AAAB>): Requested CRAM-MD5 scheme,
>>>> but we
>>>> have a NULL password
>>>>
>>>> NULL is there because our sql query returns empty password just
>>>> like wiki
>>>> says "nopassword:  you want to allow all passwords, use an empty
>>>> password and this field. "
>>>>
>>>>
>>>> If password is returned in sql query then it fails, too:
>>>>
>>>> Nov 17 09:00:49 auth-worker(2206): Error:
>>>> sql(pepe,127.0.0.1,<eO5vlnpBtNd/AAAB>): nopassword set but password is
>>>> non- empty
>>>>
>>>> So looks to be a bug.
>>> It's not a bug. CRAM-MD5 does in fact require *some* password to work,
>> Provide fake/random one for nopassword internally.
>>
>>> you can either store it with doveadm pw -S CRAM-MD5 or as plain text
>>> password.
>> Then I get
>>
>>>> sql(pepe,127.0.0.1,<eO5vlnpBtNd/AAAB>): nopassword set but password is
>>>> non- empty
>> So that doesn't help
>>
>> btw. doveadm pw -S is not documented, so no idea what it does
>>
>>> Aki
> Sorry to bump into your conversation but Aki is defending too hard
> something that is realy a bug.
> I have signaled myself this issue in the "very old" version 2.2.9(!)
> nopassword means ANY password (including none). One cannot store
> something like ANY with doveadm, SQL or anything.
> So with "nopassword" the query should simply ignore the password field
> (missing, NULL or set to anything else).
> Why would an user login with nopassword? This is an administrator
> decision and is not subject for comments.
> My problem was with LDA who refuses to store mail in INBOX if the user
> is not properly authenticated (nopassword) so you cannot receive mails
> for "hidden" users that cannot login, maybe to redirect mails later or
> do some other things with.
>
> Adrian

You can also, if you are using nopassword flag, abstain from actually
returning any field called 'password' from your SQL database. The reason
this check is done is to ensure that you know what you are doing. We do
not want to prevent you from logging in w/o password, that's fine for us
and it will work just as you want as long as you do not return
'password' attribute from your database.

Aki