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

From: Xin Li <delphij_at_delphij.net>
Date: Fri, 07 Mar 2014 16:43:32 -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?

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.

> 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.

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

Will do and thanks for the offer!

Cheers,
- -- 
Xin LI <delphij_at_delphij.net>    https://www.delphij.net/
FreeBSD - The Power to Serve!           Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBCgAGBQJTGme0AAoJEJW2GBstM+nsXnkQAIYplCr5wMtENLYMQCDSrOFJ
7oxKbW2Iy1qPbbrjAb6mG0TY4ugJu2T6Sg6Wp1B+um2sWqWkNMr+8auHokwuB8+1
8NpnbcZarFvmA5tgVEsh+JcAJF1qZRFQDku+DbL9f/ZXFn/4CtmLkw5NS/kIKf/0
TIeXykNie5nFCS8ifT5Ai7vEHImOTwS4OEVzXoTQSdFGuLnHrToCnV7LpOK2ceIo
ssZ/0Go49tSzW8y3u2a0TZYTqMnh+0EzQFusWkulyCIam0NYjYON/3UY0/TpRgZd
ik2QLqKXaMZBPmi4EsmgpQr97MS0PRag4lahZZad2CckZmhiwWrHLyECf0Xk5i1W
+ACqSfJAzq+NeyDBW05y31qALeyUhm7+ALolSMDFkQMj5B7ra8qnQsbXVyG+DLmg
itpCWfXUpKPxclkvirnDQx89BE1MOYGYBbw69IR5NWcvF3f4EF177xplwAMjHhn5
EXUVIeTwjHYoYgMiZKX8aFgyNR2EX/g6JvZS8236HUbskLQl5AAKM0RA4aQkAFGW
206DYokJW3TnXNArm8kKJCZrYAJb17XyzN6HcY89N+GA0oEkehy2qyQiBVqtpjgh
6WsslScxAnQM3LG84un98cdipOWwQerTwfeji1yqfmik5oNuCm4D/Jlt6rvJBFLb
S5fUd1BQv+0woAKndGhb
=rCdB
-----END PGP SIGNATURE-----
Received on Fri Mar 07 2014 - 23:43:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:47 UTC