Re: WIP: SCRAM authentication - Mailing list pgsql-hackers

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Tue, Aug 18, 2015 at 2:07 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > SCRAM itself, as has been discussed, supports multiple password
> > verifiers- that's a specific case all by itself, and it's done
> > specifically to address the issue that one or another of the algorithms
> > used is compromised, or that a new algorithm becomes available which is
> > better.  AD and Kerberos support multiple password verifiers because of
> > this and that it allows you to migrate from one to the next without
> > having to do wholesale replacment across all systems involved.  I bring
> > them up as examples of the advances in password-based authentication
> > which we've missed and because they are what users expect from current
> > password-based authentication systems, not because we support them and
> > therefore should just push everyone to them.
>
> OK, that's an interesting argument.  If SCRAM supports multiple
> password verifiers, and we support SCRAM, then I guess we should
> probably do that, too.  I still don't like it all that much, though.
> I think it's absolutely inevitable that people are going to end up
> with an account with 3 or more different passwords that can all be
> used to log into it, and that won't be good.  How do other systems
> avoid this pitfall?

They provide:

a) ability to configure which algorithms are used at change-password
 MIT Kerberos, kdc.conf: supported_enctypes and                 kadmin: enctype-salttype

b) ability to configure which algorithms are allowed to be used at all
 MIT Kerberos, libdefaults: default_tgs_enctypes, default_tkt_enctypes, and permitted_enctypes, along with
allow_weak_cryptowhich removes all those considered 'weak' from the other sets if set to false (the default). 

c) password aging (to get users to change their password regularly, so  you know after, say, 90 days of the change to
theset configured in  'a' that all users will have either expired passwords or have been  updated to the latest set). 

Note that we don't need quite so many options, these were done over time
for Kerberos and also address the different types of tickets involved in
that system.

Today, they discourage explicitly setting default_tgs_enctypes and
default_tkt_enctypes.  We really just need to allow configuration of
which should be stored at change-password time and the set of allowed
types.  I wouldn't want those to be the same because you'd want to
remove a compromised type as soon as possible from the "change-password"
set while still allowing those users to connect, to get them to change
their password using self-service (doing it all through the
adminstrators of the system would be very painful in large
organizations).

We also don't strictly need password aging, but it certainly helps.  We
definitely do need to provide administrators with easy interfaces
through functions and tools to manage the password verifiers used.
Thanks!
    Stephen