Re: Successor of MD5 authentication, let's use SCRAM
От | Magnus Hagander |
---|---|
Тема | Re: Successor of MD5 authentication, let's use SCRAM |
Дата | |
Msg-id | CABUevEzZbm7tsH1S5HKbskrKzz2W=YDCD1UQ-Z10WxwmhzAEDw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Successor of MD5 authentication, let's use SCRAM (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: Successor of MD5 authentication, let's use SCRAM
(Robert Haas <robertmhaas@gmail.com>)
|
Список | pgsql-hackers |
On Thu, Sep 12, 2013 at 4:41 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > On 12.09.2013 17:30, Andrew Dunstan wrote: >> >> >> On 09/12/2013 09:10 AM, Heikki Linnakangas wrote: >>> >>> >>> 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. >> >> >> You forgot to mention that we'd actually like to get away from being >> tied closely to OpenSSL because it has caused license grief in the past >> (not to mention that it's fairly dirty to manage). > > > Yeah. I've been looking more closely at the SRP API in OpenSSL; it's > completely undocumented. There are examples on the web and mailing lists on > how to use it, but no documentation. Hopefully that gets fixed eventually. Well, undocumented and OpenSSL tend to go hand in hand a lot. Or, well, it might be documented, but not in a useful way. I wouldn't count on it. > GnuTLS also supports SRP. They even have documentation for it :-). The API > is slightly different than OpenSSL's, but not radically so. If we are to > start supporting multiple TLS libraries, we're going to need some kind of a > shim layer to abstract away the differences. Writing such a shim for the SRP > stuff wouldn't be much additional effort, once you have the shim for all the > other stuff in place. http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol#Real_world_implementations That does not paint a very good pictures. I'd say the most likely library that we'd *want* instead of openssl is NSS, if we have to pick one of the big ones. Or one of the newer implementations that are a lot more focused and lean. And none of them support SRP. I fear starting to use that is going to make it even harder to break out from our openssl dependency, which people do complain about at least semi-regularly. I wonder how much work it would be to build something on top of lower level primitives that are provided in them all. For example, https://github.com/cocagne/csrp/ implements it on top of openssl, and it's around 1000 LOC (bsd licensed). And that's generic - it might well be shorter if we do something ourselves. And if it's BSD licensed, we could import.. (And then extend to run on top of other cyrpto libraries, of course) -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Heikki LinnakangasДата:
Сообщение: Re: Successor of MD5 authentication, let's use SCRAM