Re: WIP: SCRAM authentication
От | Robert Haas |
---|---|
Тема | Re: WIP: SCRAM authentication |
Дата | |
Msg-id | CA+TgmoYR+gPyf-4-iUSXA-8A8CSnSM70VRGPYDqEAtMxrxn8Vw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: SCRAM authentication (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: WIP: SCRAM authentication
|
Список | pgsql-hackers |
On Wed, Aug 12, 2015 at 9:36 PM, Stephen Frost <sfrost@snowman.net> wrote: >> Yes, the SCRAM implementation could be buggy. But also, OpenSSL has >> repeatedly had security bugs that were due to forcing servers to >> downgrade to older protocols. I wouldn't like us to start growing >> similar vulnerabilities, where SCRAM would have been just fine but an >> attack that involves forcing a downgrade to MD5 is possible. > > I agree that such similar vulnerabilities would be unfortunate, but > the way to avoid that is to not implement the actual hashing or > encryption algorithms ourselves and to stick to the protocol as defined > in the specification. Nothing in that will protect us if the client can request a non-SCRAM form of authentication. >> I don't think you are quite correct about the scenario where pg_authid >> is compromised. Even if the hash stored there is functionally >> equivalent to the password itself as far as this instance of >> PostgreSQL is concerned, the same password may have been used for >> other services, so cracking it has a purpose. > > I attempted to address that also by stating that, should an attacker > compromise a system with the goal of gaining the cleartext password, > they would attempt the following, in order: What if they steal a pg_dump? All of the password verifiers are there, but the live system is not. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: