Re: [HACKERS] SCRAM auth and Pgpool-II
От | Tatsuo Ishii |
---|---|
Тема | Re: [HACKERS] SCRAM auth and Pgpool-II |
Дата | |
Msg-id | 20170708.084240.1800247571793601438.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] SCRAM auth and Pgpool-II (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
> I think it is. From a security point of view, the fact that the same > salt is always used for the same username is a weakness of md5 > authentication which SCRAM corrects. In my understanding, md5 does not always use the same salt for the same username. PostgreSQL keeps md5(password+username) in pg_authid. When md5 auth is required, the backend sends a random number (i.e. salt) to the client. The client replies back md5(salt+md5(password+username)) to the backend. The backend does the calculation (md5(salt+md5(password+username))). If the result matches the value sent from the user, md5 authentication succeeds. So the salt is differ in each session in md5. The weakness in md5 is , IMO, each PostgreSQL installation always keeps the same value (md5(password+username)). > IIUC, things will get even worse once channel binding is committed, > presumably for PostgreSQL 11. The point of channel binding is to > guarantee that you are conducting the authentication exchange with the > target server, not some intermediate proxy that might be conducting a > hostile MITM attack. pgpool may not be a hostile attack, but it is > acting as a MITM, and channel binding is going to figure that out and > fail the authentication. So unless I'm misunderstanding, the solution > you are proposing figures to have a very limited shelf life. Check... Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
В списке pgsql-hackers по дате отправления: