On 02/11/2015 05:34 PM, Claudio Freire wrote:
On Wed, Feb 11, 2015 at 12:20 PM, José Luis Tallón
<jltal...@adv-solutions.net> wrote:
Moreover, requiring everybody to change all passwords and clients *at once*
seems like a very poor decision towards allowing for graceful upgrades and
make rolling changes back possible, right?
I wasn't advocating for what. I was just pointing out that
implementation of SCRAM was an all-encompassing endeavour, in that you
have to attack both password storage and the transmission protocol.
For instance, if you tell me I can do SCRAM, I'll be happy to enable
it if my lib has support for it. But if you add "oh... to use it, you
must store plaintext on pg_authid", I'd change my mind. Because you
cannot do SCRAM while storing md5.
You can't do plain SCRAM while storing md5, but you could implement a
variant where the stored md5 hash is treated like the plaintext
password. The client first calculates the MD5(plaintext password), and
then proceeds with the SCRAM authentication with that. The MD5 doesn't
add any extra security (nor reduce it AFAICS), but it would allow doing
SCRAM, using the MD5 hashes already stored in pg_authid.
You'd still be just as vulnerable to someone stealing the MD5 hashes
from pg_authid, of course. So if you don't want to continue supporting
MD5 authentication for backwards-compatibility, you'd want to transform
all the hashes to SCRAM stored keys.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
