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

Allan Jude wrote this message on Fri, Mar 07, 2014 at 17:53 -0500:
> On 2014-03-07 17:06, 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
> >>>>
> >>>
> >>> This looks like what we wanted. In the feedback you talked about
> >>> some changes to your patch required to make it work, is there any
> >>> progress on those?
> > 
> >> Derek's patches worked perfectly for our needs, but we're the sort
> >> of people who use vipw and our own utilities for user management.
> >> It wasn't until later that we discovered at least one other file
> >> would need patching to satisfy everyone.  We didn't want to employ
> >> the same copy-pasta method, so we asked for feedback about our
> >> proposed alternative.
> > 
> >> secteam_at_, do you have any comments?  Before we put any more work
> >> into this, we want to be sure that our proposal is an acceptable
> >> one.
> > 
> > 
> > Did you mean adding rounds capability, or transparent upgrade of
> > crypt() algorithms, or both?
> 
> There are 2 separate but related threads
> 
> 1) specify rounds for crypt()
> 
> 2) transparent upgrade of crypt() algo (or more likely just number of
> rounds)

Can't the two be merged...  where 2 becomes a flag in login.conf instead
of an algo fetch, and then if it's true, it does the algo fetch from
1?

I really would like us to get 1 in, and then on boot dynamicly adjust
the number of rounds depending upon CPU usage... obviously, a flag will
adjust how long/many rounds the admin wants, but it would allow an
automatic increase in security as faster CPUs are used...

Anyways, how many people are still using passwords instead of ssh keys?
Setting the time to be something like 100ms may seem long, but
considering few people should be using passwords these days, it's less
of an issue...

Xin Li, if you need help reviewing, testing, let me know...

> > I need some time to digest the whole transparent upgrade idea but in
> > general I think it's good.
> > 
> > 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.

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

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