On 9/26/16 4:54 AM, Heikki Linnakangas wrote:
> On 09/26/2016 09:02 AM, Michael Paquier wrote:
>> On Mon, Sep 26, 2016 at 2:15 AM, David Steele <david@pgmasters.net>
>> wrote:
>>> However, it doesn't look like they can be used in conjunction since the
>>> pg_hba.conf entry must specify either m5 or scram (though the database
>>> can easily contain a mixture). This would probably make a migration
>>> very unpleasant.
>>
>> Yep, it uses a given auth-method once user and database match. This is
>> partially related to the problem to support multiple password
>> verifiers per users, which was submitted last CF but got rejected
>> because of a lack of interest, and removed to simplify this patch. You
>> need as well to think about other things like password and protocol
>> aging. But well, it is a problem that we don't have to tackle with
>> this patch...
>>
>>> Is there any chance of a mixed mode that will allow new passwords to be
>>> set as scram while still honoring the old md5 passwords? Or does that
>>> cause too many complications with the protocol?
>>
>> Hm. That looks complicated to me. This sounds to me like a retry logic
>> if for multiple authentication methods, and a different feature. What
>> you'd be looking for here is a connection parameter to specify a list
>> of protocols and try them all, no?
>
> It would be possible to have a "md5-or-scram" authentication method in
> pg_hba.conf, such that the server would look up the pg_authid row of the
> user when it receives startup message, and send an MD5 or SCRAM
> challenge depending on which one the user's password is encrypted with.
> It has one drawback though: it allows an unauthenticated user to probe
> if there is a role with a given name in the system, because if a user
> doesn't exist, we'd have to still send an MD5 or SCRAM challenge, or a
> "user does not exist" error without a challenge. If we send a SCRAM
> challenge for a non-existent user, and the attacker knows that most
> users still have a MD5 password, that reveals that the username doesn't
> most likely doesn't exist.
>
> Hmm. The server could send a SCRAM challenge first, and if the client
> gives an incorrect response, or the username doesn't exist, or the
> user's password is actually MD5-encrypted, the server could then send an
> MD5 challenge. It would add one round-trip to the authentication of MD5
> passwords, but that seems acceptable.
>
> We can do this as a follow-up patch though. Let's try to keep this patch
> series small.
Fair enough. I'm not even 100% sure we should do it, but wanted to
raise it as a possible issue.
--
-David
david@pgmasters.net