(reviving an old thread)
On 23.10.2012 19:53, Peter Eisentraut wrote:
On 10/22/12 1:25 PM, Stephen Frost wrote:
* Peter Eisentraut (pete...@gmx.net) wrote:
On 10/12/12 3:44 PM, Stephen Frost wrote:
In general, I think it's good to build on existing implementations where
possible. Perhaps we could even consider using something which already
exists for this?
Sounds like SASL to me.
aiui, that would allow us to support SCRAM and we could support
Kerberos/GSSAPI under SASL as well... Not sure how comfortable folks
would be with moving to that though.
Considering all the design and implementation challenges that have been
brought up in this thread:
- not using MD5
- not using whatever we replace MD5 with when that gets broken
- content of pg_shadow can be used to log in
- questions about salt collisions
- making the hash more expensive
- negotiating how much more expensive, allowing changes in the future
- using HMAC to guard against length-extension attacks
- support for poolers/proxies
I think I would be less comfortable with a hand-crafted solution to each
of these issues, and would be more comfortable with using an existing
solution that, from the look of it, already does all of that, and which
is used by mail and LDAP servers everywhere.
That said, I don't have any experience programming SASL clients or
servers, only managing existing implementations. But I'd say it's
definitely worth a look.
SASL seems like a good approach to me. The SASL specification leaves it
up to the application protocol how the SASL messages are transported.
Each application protocol that uses SASL defines a "SASL profile", which
specifies that. So for PostgreSQL, we would need to document how to do
SASL authentication. That's pretty straightforward, the SASL messages
can be carried in Authentication and PasswordMessage messages, just like
we do for GSS.
SASL specifies several "methods", like PLAIN and GSSAPI. It also has a
couple of methods that use MD5, which probably could be used with the
hashes we already store in pg_authid. I believe we could map all the
existing authentication methods to SASL methods. In the distant future,
we could deprecate and remove the existing built-in authentication
handshakes, and always use SASL for authentication.
The SASL specification is quite simple, so I think we could easily
implement it ourselves without relying on an external library, for the
authentication methods we already support. That doesn't buy us much, but
would be required if we want to always use SASL for authentication. On
top of that, we could also provide a configure option to use an external
SASL library, which could provide more exotic authentication methods.
Now, to a completely different approach:
I just found out that OpenSSL has added support for SRP in version
1.0.1. We're already using OpenSSL, so all we need to do is to provide a
couple of callbacks to OpenSSL, and store SRP verifiers in pg_authid
instead of MD5 hashes, and we're golden.
Well, not quite. There's one little problem: Currently, we first
initialize SSL, then read the startup packet which contains the username
and database to connect to. After that, we initialize database access to
the specified database, and only then we proceed with authentication.
That's not a problem for certificate authentication, because certificate
authentication doesn't require any database access, but if we are to
store the SRP verifiers in pg_authid, we'll need to database access much
earlier. Before we know which database to connect to.
But that's just an implementation detail - no protocol changes would be
required.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
