Re: Successor of MD5 authentication, let's use SCRAM

On Thu, Sep 12, 2013 at 4:41 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/