Re: Feature Proposal: Transparent upgrade of crypt() algorithms

Xin Li wrote this message on Fri, Mar 07, 2014 at 16:36 -0800:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 03/07/14 14:50, A.J. Kehoe IV (Nanoman) wrote:
> > Xin Li wrote:
> >> Hi,
> >> 
> >> On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote:
> >>> Allan Jude wrote:
> >>>> On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote:
> >>>>> Allan Jude wrote:
> >>>>> 
> >>>>> [...]
> >>>>> 
> >>>>>> Honestly, my use case is just silently upgrading the
> >>>>>> strength of the hashing algorithm (when combined with my
> >>>>>> other feature request). Updating my bcrypt hashes from
> >>>>>> $2a$04$ to $2b$12$ or something. Same applies for the
> >>>>>> default sha512, maybe I want to update to rounds=15000
> >>>>> 
> >>>>> Like this?
> >>>>> 
> >>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=182518
> >>>>> 
> >>>>> Request for comments:
> >>>>> 
> >>>>> http://docs.freebsd.org/cgi/mid.cgi?20140106205156.GD4903
> > 
> > [...]
> > 
> >> Speaking for adding rounds, the only problem that needs to be
> >> fixed is that the proposed patch makes it possible to create
> >> conflicting configuration (passwd_format and passwd_modular can
> >> use different hashing algorithms) and need to be fixed and
> >> polished.  I like the idea of making it possible to use more
> >> rounds though.
> > 
> > This was deliberate for backward compatibility.  passwd_format will
> > be used by default if passwd_modular isn't defined.  If
> > passwd_modular is defined as "disabled", then passwd_format will be
> > used.
> 
> Well, my point is that the two shouldn't be allowed to exist together
> if they can mean something conflicting.  Allowing passwd_format=sha512
> AND passwd_modular=$2a$08$ in the same configuration creates confusion
> and it's not good.
> 
> My suggestion is that we either have:
> 
> a) passwd_format and passwd_round (so that they don't conflict), or
> 
> b) extend passwd_format in a compatible manner to allow specifying a
> round, or,

Couldn't we merge passwd_format and passwd_modular into one, being
either the name, or the begining salt string?  since the salt string
always begins w/ $, they wouldn't conflict, and could be properly
resolved...

> c) make passwd_format and passwd_modular conflict so we don't silently
> accept it and instead bail out when doing pwd_mkdb.
> 
> > What do you think of the idea of putting this into libcrypt instead
> > of pam_unix.c, and then patching pam_unix.c and pw_user.c to
> > reference libcrypt?
> 
> Which part of the idea?  I think it's a bad idea to make libcrypt to
> depend on libutil (for login_cap(3)) but we should probably provide
> new wrappers in login_cap(3) to do the common things when requested
> for various password manipulating tools to reduce duplicated code.

So, the current code in pam_unix is:
login_setcryptfmt which calls crypt_set_format as necessary
makesalt
crypt

So, we could expand crypt_set_format to understand the two, and keep
a copy of the rounds data, or we could expose makesalt into maybe
crypt_makesalt (this would be nice) w/ an optional arg that provides
either the name or the beging salt string w/ rounds, i.e. what
passwd_format would contain...  and update pam_unix and friends to
use this...  This last method would make login_setcryptfmt unnecessary,
so I'm not sure how good/bad that is..

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."