[PROPOSAL] Add tests for supplementalCredentials, store other hash types

[Andrew Bartlett]

On Tue, 2017-04-04 at 10:24 +0200, Stefan Metzmacher via samba-
technical wrote:
> Am 04.04.2017 um 10:17 schrieb Stefan Metzmacher via samba-technical:
> > Hi Andrew,
> > 
> > > > I just wanted to give you a heads-up that Gary (CC'ed) is
> > > > working on
> > > > the issue I raised almost a year ago, regarding storing the
> > > > sha512
> > > > hashes rather than the plaintext password under GPG.
> > > > 
> > > > In preparation for that, tomorrow he will send in some tests to
> > > > lock
> > > > in
> > > > the base-line behaviour of supplementalCredentials, including
> > > > the
> > > > HTTP
> > > > digest values, then a small re-factor so that we can
> > > > practically add
> > > > additional packages.
> > > > 
> > > > I'm sorry I don't have code to show right now, but our design
> > > > is to
> > > > store a new package named Primary:userPassword{SHA512} (or
> > > > {SHA265}),
> > > > following from the OpenLDAP use of rfc2307 in this
> > > > area.  Perhaps
> > > > Microsoft may even be encouraged to do the same some day!  
> > > > 
> > > > Storage will for Samba be controlled by an smb.conf option.
> > > > 
> > > > The idea will be to re-use and extend your syncpasswords work
> > > > to
> > > > expose
> > > > these to users needing access. 
> > > 
> > > This work progresses well, and some of the patches have already
> > > been
> > > posted. 
> > > 
> > > The work in progress so far is at
> > > http://git.catalyst.net.nz/gw?p=samba.git;a=shortlog;h=refs/heads
> > > /gary-
> > > password-hash
> > 
> > I think one important thing is that it's possible to configure more
> > than
> > one hashing scheme, which is important for soft migrations.
> > Note that {SHA256} and {SHA512} are not valid scheme names in
> > RFC2307,
> > "{CRYPT}" is the generic prefix for these.

RFC2307 says:
userPassword values MUST be represented by following syntax:

        passwordvalue          = schemeprefix encryptedpassword
        schemeprefix           = "{" scheme "}"
        scheme                 = "crypt" / "md5" / "sha" / altscheme
        altscheme              = "x-" keystring
        encryptedpassword      = encrypted password

The names {SHA256}, {SHA512} are 'altscheme' in this pattern, and match
what is used in OpenLDAP for the password-hash parameter.  BTW, I'm
particularly interested in extending this to {ARGON2}, which OpenLDAP
is looking to move to. 

Additionally, if we make the scheme name {CRYPT}, it makes storing
multiple values more difficult (that name was what we were using for
the uniqueness).  

On the flip side, if libc is moving faster than Samba, it allows an
option like OpenLDAP's

password-crypt-salt-format "$1$%.8s"

to access a new hash via crypt().  However this feels overly complex.

As we already have SHA512 and SHA256 specified in your password sync
tools, I would like to keep those unambiguously handled using those
names. 

> > Maybe a configuration like this:
> > 
> > password hash openldap schemes =
> > or
> > password hash userpassword schemes =
> > 
> >    {CRYPT}:alg=5:round=1500 {SSHA} {CRYPT}:alg=6

At this stage we are trying to get a base implementation in.  I don't
mind it being extended to be a multi-valued parameter, but we are
trying to start with just one. 

In terms of how other software performs the configuration, I'll note:

https://linux.die.net/man/8/pam_unix

Here the algorithms are hard coded.  This is nice and easy for the
administrator to understand, rather than alg=5.  

> Or "CryptSHA256:round=1500 SSHA CryptSHA512 CryptSHA512:round=5000",
> in which cases if matches more what we have in 'samba-tool user
> getpassword',
> but then remove the the reference to RFC2307 from the docs.

I don't see a need to remove the reference, as long as we use {SHA512}
etc, as we also reference OpenLDAP's interpretation of that. 

> If you add the magic with specifying 'round', please try to find a
> way
> to also add it to
> samba-tool user getpassword

Passwords are complex, my strong preference is to keep this simple,
whatever we do.

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba