Re: WIP: SCRAM authentication

Heikki,

* Heikki Linnakangas (hlinnaka(at)iki(dot)fi) wrote:
> On 03/30/2015 06:46 PM, Stephen Frost wrote:
> >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.

I don't like using the MD5 hash of the password for the token or to
generate the verifier. I'm no cryptographer and can't speak with any
certainty on the topic, but I understand there can be cases where doing
such would actively reduce the complexity required to find a usable
token. Further, to be frank and slightly paranoid, it's possible that
individuals have built up caches of known-to-be-valid PG-encoded md5
strings from backups or other stolen data and we would not be doing
people who run those systems any favors with that approach.

At the end of the day, I'd much prefer to see a clean break with new
passwords rolled out by administrators working with their users. That,
of course, would be much easier if we provided the basics that every
other auth system out there does today, which are the capabilities
available through pam_unix, pam_pwquality, pam_cracklib, etc. In
particular, things like password history, password validity, password
complexity, account inactivity, account login history (successful vs.
failed attempts), are required in many environments, specifically called
out by NIST 800-53 which is required for US Government deployments, and
probably included in other standards also (eg: PCI, HIPPA, etc).

These are all things I was fighting for 10-or-so years ago. I sincerely
hope that we're ready to consider these capabilities as being desirable.
I'm certainly hoping to work on them for 9.6 and will be happy to
support them going forward.

> >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.

Agreed on both counts.

> >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".

Ok.. Having it be a constant which means "same as in startup packet"
may be workable. My suggestion above was intended to be "let's figure
out a way to encode whatever is in the startup packet to work in UTF8,
and then we will decode it ourselves" kind of idea. That would make it
byte-wise different (at least in some cases- we might be able to
minimize the number of cases that happens), but semantically identical.
What would be *really* nice would be to say "if your client only speaks
UTF8, then you don't have to worry about this and everything just works
like normal." That might be too much of a stretch though.

Thanks!

Stephen