{PATCH] store extra password hashes in supplemental credentials

[Andrew Bartlett]

On Mon, 2017-05-08 at 11:54 +1200, Gary Lockyer wrote:
> 
> On 06/05/17 06:06, Andrew Bartlett wrote:
> > On Wed, 2017-04-12 at 16:09 +1200, Andrew Bartlett via samba-technical
> > wrote:
> > 
> > > Err..
> > > 
> > > If you could suggest a syntax that you like, we can code it up. 
> > > Options include:
> > > 
> > > CryptSHA512:5500 CryptSHA256
> > > 
> > > or probably better:
> > > 
> > > CryptSHA512:rounds=5500 CryptSHA256
> > > 
> > > I'm not sure how to fit those in to the attributes for the 'samba-
> > > tool
> > > user getpassword' case, but perhaps you have clearer ideas.
> > 
> > I've been chatting to metze and we agreed to the above, but with a new
> > name:
> > 
> > password hash userPassword schemes = CryptSHA512:rounds=5500 CryptSHA256
> 
> Do I need to store multiple rounds for a scheme i.e. would
> CryptSHA512:rounds=5500 CryptSHA512:rounds=10000 CryptSHA256
> be valid?

It would still need to be stored under CryptSHA512 as the name.  I
don't see a reason for multiple different round calculations to be
valid for the same hash (as it is pointless). 

> > 
> > For the getpassword, we agreed to 
> > 
> > --attributes="virtualCryptSHA256;rounds=5500,virtualCryptSHA512"
> > 
> > The documentation will explain that the rounds is only used if a
> > plaintext password is present, and does not change the returned
> > attribute name in the LDIF.
> 
> I'll use the following logic for determining the virtualCryptSHAxxx
> values in getpassword.
> 
> 1) IF rounds specified AND plaintext password
>    THEN
>        calculate hash from plaintext password and rounds
>    END
> 
> 2) IF rounds specified AND NO plaintext password
>    THEN
>        No value
>    END

We need to return the hashed password from the userPassword scheme,
even if the rounds is specified.  

This is contradictory, unexpected and Metze and I disagreed for a bit
on it, but it is needed so that we can support a directory holding both
(GPG) plaintext passwords and userPassword hashed passwords, which may
have been laid down over time with different hash strengths.  

It is still better to return a password always, even if of a slightly
different strength.  We need to document that the rounds= will be
ignored if a hashed password is found.  (A concerned administrator can
always just read the values and reject them). 

> 3) IF rounds NOT specified AND userPassword for scheme
>    THEN
>        Use the user password value
>    END
> 
> 4) IF rounds NOT specified AND NO userPassword for scheme AND
>       plaintext password
>    THEN
>        Calculate hash from plaintext password
>    END
> 
> 5) IF rounds NOT specified AND NO userPassword for scheme AND
>       NO plaintext password
>    THEN
>        No value
>    END
> 
> > 
> > We also agreed that the WDigest implementation patches need to be
> > second, in a distinct patch, after the WDigset tests.  
> > 
> > Then implement the ;rounds for getpassword. 
> > 
> > Then the IDL if not required earlier. 
> > 
> > Then the userPassword tests, then the C changes, then the userPassword
> > samba-tool changes. 
> > 
> 
> Should I submit these as separate patch sets, i.e.
>   1) WDigest changes
>   2) rounds support for the virtual crypt parameters
>   3) then the userPassword changes
> It will be easier to review that way.

The easier to review the better.

Thanks!

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