From owner-freebsd-current@FreeBSD.ORG Sat Mar 8 00:43:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD47D281; Sat, 8 Mar 2014 00:43:33 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 87A9C2C1; Sat, 8 Mar 2014 00:43:33 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 0E6C816F87; Fri, 7 Mar 2014 16:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1394239413; bh=gAHIm7Yjazz9C9zqpFfJjqeOsDB+da66XyeAQwyF3W0=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=h64S8OWLE54nsZYT5vk9qLY+jZiEL5bTpz1AioFxHfW8STK6OusI9uwbYMMbVw6yq uWqgMP+h3fHCdQWnWROkmmr3H/TzUFL35FLuoPo85RscHTDdyUj0de7ICy+eZet8Mc X+bS31Opna7TpthvzYOflDWJeZXyxCMO3zoIEuMk= Message-ID: <531A67B4.1010303@delphij.net> Date: Fri, 07 Mar 2014 16:43:32 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Allan Jude , d@delphij.net, nanoman@nanoman.ca, secteam@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8?= =?ISO-8859-1?Q?rgrav?= , freebsd-current@freebsd.org Subject: Re: Feature Proposal: Transparent upgrade of crypt() algorithms References: <2167732.JmQmEPMV2N@desktop.reztek> <201403070913.30359.jhb@freebsd.org> <5319DE84.3040602@allanjude.com> <20140307161313.GA49137@nanocomputer.nanoman.ca> <531A2CC1.8080802@allanjude.com> <20140307215223.GB49137@nanocomputer.nanoman.ca> <531A42F3.5020207@delphij.net> <531A4DE1.3070507@allanjude.com> <20140307230715.GA17019@funkthat.com> In-Reply-To: <20140307230715.GA17019@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 00:43:33 -0000 -----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@, 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 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-----