On 02/11/2015 04:38 AM, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On 2/10/15 8:28 PM, Robert Haas wrote:
>>> I don't actually care which algorithm we use, and I dowannahafta care.
>>> What I do want to do is provide a framework so that, when somebody
>>> discovers that X is better than Y because Z, somebody who knows about
>>> cryptography and not much about PostgreSQL ca add support for X in a
>>> relatively small number of lines of code.
>
>> sounds like SASL
>
> Sounds like pie in the sky really :-(.
SASL won't automatically solve any of ourproblems. We still have to
write the support for all the authentication mechanisms we wanted to
support. The nice thing about SASL is there is a list of well-understood
and documented mechanisms that go with it, with canonical names like
"SCRAM-SHA-1". If we use those, it's well-defined what the mechanism is,
with less design work for us. And who knows, it just might make it
easier to add client-support, if there's an existing SASL library for
language X.
So +1 for implementing SASL. It's simple to implement, and AFAICS isn't
any more difficult than rolling our own.
> We could make the server turn on
> a dime perhaps, but the client-side population will not come along nearly
> that quickly, nor with small effort. Stored passwords won't migrate to a
> new scheme transparently either.
Yep.
> I think it's probably reasonable to think about a more modern password
> auth method, but not to imagine that it will be pluggable or that the
> adoption time for any revision will be less than years long.
It makes sense to make it pluggable if it's simple, but in reality most
drivers will support only a few most common mechanisms. That's OK. We
need to design the protocol so that multiple mechanisms can be used
side-by-side for years.
- Heikki