Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZPXMY-0008JK-AX for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Aug 2015 14:50:42 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZPXMX-0004gv-8i for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Aug 2015 14:50:41 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZPXMW-0004gp-RV for pgsql-hackers@postgresql.org; Wed, 12 Aug 2015 14:50:40 +0000 Received: from mout.gmx.net ([212.227.17.21]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.84) (envelope-from ) id 1ZPXMT-0006SU-E8 for pgsql-hackers@postgresql.org; Wed, 12 Aug 2015 14:50:40 +0000 Received: from auth2-smtp.messagingengine.com ([66.111.4.228]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LiDHj-1Z2ryj2EdP-00nUjT for ; Wed, 12 Aug 2015 16:50:34 +0200 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id 222F021E7F for ; Wed, 12 Aug 2015 10:50:33 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 12 Aug 2015 10:50:33 -0400 X-Sasl-enc: SdWromRIAOINyQYmNer2pRs+RoHN7+T9c+gzTDzBgWWy 1439391032 Received: from [192.168.1.146] (unknown [204.145.120.11]) by mail.messagingengine.com (Postfix) with ESMTPA id DCF96C00016; Wed, 12 Aug 2015 10:50:32 -0400 (EDT) Message-ID: <55CB5D38.5090503@gmx.net> Date: Wed, 12 Aug 2015 10:50:32 -0400 From: Peter Eisentraut User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Robert Haas CC: Josh Berkus , Heikki Linnakangas , Michael Paquier , pgsql-hackers Subject: Re: WIP: SCRAM authentication References: <55192AFE.6080106@iki.fi> <55C4FCC2.3000503@iki.fi> <55C63B1E.2040101@iki.fi> <55C79F0A.90601@agliodbs.com> <55CA4085.30101@gmx.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:87rDkIZYRTKaiqDM7g/OaIvQTd0ldTecBOf2ZLDwW3cwrssY0A+ IC2+yVPP8g0IuLN2qm8QHELGCUD/3qQl757kvWMB8oscqp5owc1tS7Uy6SuzC+cLCXGrt8f z6yfzCwpHW08st+fWqLhuRQqDwoTXmncUyNSfqm5iIqfkgFnZizy2w8UfWf/bovB0u0yyYb /CIEtlTjudFhv1WTbQT5Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:qo/AhsLPM/w=:7rOjosDlUudi2pSb1cKWD8 qvmetWrxntO58f34baDgYB36eere/6tI0CVE7gqKBclm3XSei2VtPkoZqzg2n0CB8HN7dhtjo K42hSXR2JbMGohD9YVg5+iJUuk3Mm91gpakcghpQQZyNmWLOw+ja1uIgOKZlWvw2eD21GNJLt /TavOO5AANvj2XmrtDJvQm0SXvQUTVXFfJ28/+fUl3PCKeDy8KZiKoCULZu2feV/d6hjKmcXb 1/IPIAOTFLvW1CSocwYsn4Je3joI01gf5hDkf1BDCOeXI+JKb2/zxDs4bakvVoiB7RXTcI54H eCzF3gZHZp9tlUnODVtTQn596NMio/1i1REj5pqTiEgiezPpGeKF/McHJipZrWGj8DFIY9DbT sbPKAjeJ5wayrcfgxVZ1cUQd8Ze7PdiigecU46XKYf7TuT2h+40QBQWbDG+J4PBCBdmhTW3tE hW72j09U84VPNDprntS9TLxJm++j3/pD4cwNT7ATTv1e9wlA0qZ1jwfkZXx/URr8SNbWVnXRi SaZWj7y0Fodkf3sffP2a6SzHXUxd0eAiyKSAQOrM4oaLx/tjRQ24oOH7UCb4PtQSxwxeklNll +Vct1jGX8DXcisW5orcaEcbul9smWAg11tZgP8lddIOOobxtF1fzZGh03ek0UDPFSPJrHswjR 7ERPu3sPgmvpif5QTQhuq2ArvuIGP5rTN6uWXmnModCDI54OLrdgKOYHLVqZUYrSeETBpCNNl Yq8AR0Jpbdi3FfXsFf03AtGIJkm8qzv7tiD3hQ== X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 8/11/15 5:18 PM, Robert Haas wrote: > The thing we're actually debating here is whether enabling SCRAM > authentication for a role should also mean disabling MD5 > authentication for that same role, or whether you should be able to > have two password verifiers stored for that role, one for SCRAM and > the other MD5. If we allowed that, then you could turn SCRAM on for a > role, and only later turn MD5 off. I think that's a bad plan because, > in most scenarios, allowing two forms of authentication for the same > account is strictly less secure than allowing only one. And also > because it means adding a bunch of new system catalog machinery and > SQL syntax. Instead, I think that, for any given role, you should get > to pick the way that password authentication works for that role: > either MD5, or SCRAM, but not "whichever of those two the client > prefers". I understand this idea, but I think it's not practical for many uses. There is no way to find out, on the server, whether all current clients would support a switch to SCRAM. Let alone all not-current clients. The only way to do such a switch would be to do the switch and then check for connection failures in the log, which is not good. It would be better if we allowed both methods side by side. Then an administrator can check in the logs which clients are using an old method and track those down without interrupting production. (Now that I think about this, to counter my point, this is very similar to the switch from crypt to md5. You couldn't turn that on until you were sure that all clients would support it. I don't remember the experience from back then, though.) Also, correct me if I'm wrong, but I believe using SCRAM would also make it harder to use the password exchange sniffed from the wire. So there might be a benefit to using SCRAM even if you have to keep old and supposedly insecure md5 hashes around for a while. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers