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

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Successor of MD5 authentication, let's use SCRAM
Дата
Msg-id 5231CFFD.5020605@dunslane.net
обсуждение исходный текст
Ответ на Re: Successor of MD5 authentication, let's use SCRAM  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: Successor of MD5 authentication, let's use SCRAM  (Stephen Frost <sfrost@snowman.net>)
Re: Successor of MD5 authentication, let's use SCRAM  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
On 09/12/2013 09:10 AM, Heikki Linnakangas wrote:
>
>
> 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.
>
>


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).

cheers

andrew




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Successor of MD5 authentication, let's use SCRAM
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Protocol forced to V2 in low-memory conditions?