On 03/30/2015 06:46 PM, Stephen Frost wrote:
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
* With "CREATE USER PASSWORD 'foo'", which hashes/verifiers should
be generated by default? We currently have a boolean
password_encryption setting for that. Needs to be a list.
This generally sounds good to me but we definitely need to have that
list of hashes to be used. The MIT KDC for Kerberos (and I believe all
the other Kerberos implementations) have a similar setting for what will
be stored and what will be allowed for hashing and encryption options.
It's very important that we allow users to tweak this list, as we will
want to encourage users to migrate off of the existing md5 storage
mechanism and on to the SCRAM based one eventually.
Unfortunately, the first major release with this will certainly need to
default to including md5 as we can't have a password update or change
break clients right off the bat. What I think would be fantastic would
be a warning, perhaps in the first release or maybe the second, which
deprecates md5 as an auth method and is thrown when a password is set
which includes storing an md5-based password. I'm sure there will be
plenty of discussion about that in the future.
Yeah. And even if client are updated, and the server is upgraded, you
still cannot use SCRAM until all the passwords have been changed and the
SCRAM verifiers for them generated. Unless we go with the scheme I
mentioned earlier, and use the MD5 hash of the password as the
"plaintext" password to SCRAM.
One additional item is that we need to have a way to prefer SCRAM-based
auth while allowing a fall-back to md5 if the client doesn't support it.
This might have to be driven by the client side explicitly saying "I
support SCRAM" from the start to avoid breaking existing clients.
I'll start a separate thread on this. It's an interesting feature on its
own. As well as an option in libpq to refuse plaintext authentication
even if the server asks for it.
* Per the SCRAM specification, the client sends the username in the
handshake. But in the FE/BE protocol, we've already sent it in the
startup packet. In the patch, libpq always sends an empty username
in the SCRAM exchange, and the username from the startup packet is
what matters. We could also require it to be the same, but in SCRAM
the username to be UTF-8 encoded, while in PostgreSQL the username
can be in any encoding. That is a source of annoyance in itself, as
it's not well-defined in PostgreSQL which encoding to use when
sending a username to the server. But I don't want to try fixing
that in this patch, so it seems easiest to just require the username
to be empty.
I don't like having it be empty.. I'm not looking at the spec right at
the moment, but have you confirmed that the username being empty during
the SCRAM discussion doesn't reduce the effectiveness of the
authentication method overall in some way?
Yes.
Is it ever used in
generation of the authentication verifier, etc? One way to address the
risk which you bring up about the different encodings might be to simply
discourage using non-UTF8-compliant encodings by throwing a warning or
refusing to support SCRAM in cases where the role wouldn't be allowed by
SCRAM (eg: in CREATE ROLE or ALTER ROLE when the SCRAM auth verifier
storage is being handled). Another option might be to define a way to
convert from "whatever" to "UTF8 something" for the purposes of the
SCRAM auth method.
Presumably the username used in the SCRAM exchange would have to match
the username sent in the startup packet. Otherwise things get weird. If
an empty string is a problem (there actually seems to be some language
in the spec to forbid or at least discourage using an empty string as
username), we could also specify some other constant that must be used,
to mean "same as in startup packet".
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
