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

Xin Li wrote this message on Fri, Mar 07, 2014 at 16:43 -0800:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 03/07/14 15:07, John-Mark Gurney wrote:
> > 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...
> 
> Or by the installer/a tool that gets run when doing
> mergemaster/etcupdate/freebsd-update: it's rare that CPU gets faster
> after installation, and we can probably just write in the
> configuration anyway?

It's just easier to throw something into /etc/rc.d w/ an enable/disable
switch than it is to update one/all of those tools to do it...  If you
update only one, then the users of the other tools won't get the benefit..
Or someone forgets to update the other tool...  or we could detect that
the CPU is the same, and keep the previous results...

> Personally I'm not a big fan of making it something that changes over
> time: the attacker may do offline attacker than doing it on the victim
> system that revealed the salted hashes, so how fast the system CPU
> runs doesn't really matter, except for how long a system administrator
> is willing to have the user to wait.

This is my point, there is currently the default number of rounds which
provides basic security, but if the sysadmin wants to provide
additional security, they can do so, either by fixing the number of
rounds to something larger, or by providing a time they are willing
to spend to do the work...

I'm tired of default security parameters not being ideal, or secure
enough...  Most sysadmins won't go and increase the number of rounds
since they don't know enough to (or couldn't before the other patch
was even presented), but they will continue to install FreeBSD on ever
faster machines, yet our only response so far is to switch algorithms,
instead of including more rounds, etc...  This feature would allow us
to provide better security out of the box, and continue to scale our
security as time goes on...

Performance for default, sha512 w/ 5k rounds:
AMD A10-5700 3.4GHz		3.8ms
AMD Opteron 4228 HE 2.8Ghz	5.4ms
Intel(R) Xeon(R) X5650 2.67GHz	4.0ms

these times are aprox as the timing varies quite a bit, ~+/-10%...

code available at: https://www.funkthat.com/~jmg/testcrypt.c

Most people won't notice a 50ms delay on login, yet it'll give us a
10x security benefit...  Just for fun, compare how long it takes to
run sleep .005 and sleep .05 from the command line...  Heck I think
most people would be fine w/ 100ms delay.. try it.. :)

and if they don't mind something similar to how geli does it, it
could be as long as 2 seconds, giving a 500x benefit! :)

and with the auto recrypt path, we could automatically "downgrade"
users passwords if system ends up w/ a slower CPU, or we could prevent
the downgrade...

> > 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...
> 
> I'm currently using SSH key plus Google Authenticator for my systems
> but all remote login via password is disabled.  I am aware of,
> however, many people who refuse to use SSH key authentication because
> they don't want to carry their keys, which is a bad idea but they do
> it anyways.

Guess this is more common than I think/hope... :(

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

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