Date: Sat, 08 Mar 2014 00:22:08 -0500 From: Allan Jude <freebsd@allanjude.com> To: d@delphij.net, nanoman@nanoman.ca, secteam@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, freebsd-current@freebsd.org Subject: Re: Feature Proposal: Transparent upgrade of crypt() algorithms Message-ID: <531AA900.6090406@allanjude.com> In-Reply-To: <20140308021536.GB17019@funkthat.com> 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> <531A67B4.1010303@delphij.net> <20140308021536.GB17019@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8VlEoeaiv6lkd8vwqjbd63D4bpNBc8KuP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-03-07 21:15, John-Mark Gurney wrote: > 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=3D15000 >>>>>>>> >>>>>>>> Like this? >>>>>>>> >>>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D182518 >>>>>>>> >>>>>>>> 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? >=20 > 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 benefi= t.. > Or someone forgets to update the other tool... or we could detect that= > the CPU is the same, and keep the previous results... >=20 >> 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. >=20 > 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... >=20 > 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... >=20 > 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 >=20 > these times are aprox as the timing varies quite a bit, ~+/-10%... >=20 > code available at: https://www.funkthat.com/~jmg/testcrypt.c >=20 > 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.. :) >=20 > 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! :) >=20 > 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... >=20 >>> 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. >=20 > Guess this is more common than I think/hope... :( >=20 One possible solution would be just setting the default login.conf number of rounds, based on a test in the installer. Although this won't help for systems that are deployed by imaging, or VM images (like EC2 images) etc. I think there is a downside to trying to detect the speed of the CPU at boot time, in that the CPU can be busy then. A note about the 100ms or 250ms or whatever, that is taking 1 cpu core that long, It might make sense to scale the rounds based on the number of logical CPUs, although that isn't as good an indicator of actual CPU capability. I do agree with the idea of having the default be smarter, either cranking it quite a ways up, and requiring users who have slow machines to manually turn it down, or doing something like jmg@ suggests, and basing it on 'how much can be done in 250ms', it just comes down to 'when' do we decide how much the CPU can do in 250ms. Generally, I imagine most servers do not 'change CPU speed' much, but, Virtual machines do, a single EC2 image can be booted on a wide variety of configurations, and the load on a VPS system can change, live migrations to different machines etc. --=20 Allan Jude --8VlEoeaiv6lkd8vwqjbd63D4bpNBc8KuP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTGqkDAAoJEJrBFpNRJZKfFlEP/iKPCJggkRNJfH5ijpQEOAo0 nSZKBfHMhKU3/1vO1RtSE64WeGm4cnZ5rW+VjqC9qm3zRdOr6uswNmvhcY0j7x5A JAVocowrt1rfeREwOuJ2seBY9CuNgVUBRhdE9W1tPQI1fQA/MZX2Zf8eyKb0negz KG1eNBqu2cpPzdFkdWOFsW3ZqqtGMa5Lo5XxtJRQ8oPHhPPrS06EJoY8AWBoKVCn JyWqrLdEkL4cViO/t0ROK3i2SocrB/Tp5FhOxc2QCHELUaxA6/AlvRG0CANKDFVv KaX5vN6I1j/g5oH7t9bLV8BceoT8XaTzJ6GXjXSdLglsZBjzB2FsRGEfGLNBAxAC JaSNbLm9jxIc+2lyiUO7PK7d38fInhMNE2kmFhK3uE72VKDCSMUmsefuebN6Skjq 5+NKuqtedPZj3igcSXiIM5LIZDAykPAlBvoqwgOekydy2Gyq4bdrNSP6kNZrsx2R IPCvGAL19kg/oMtGooGep4sJp4iUUWccMb+Ay/qkUy3AQM4kkdHEizvvwthbph/H yekP1hPb2qJqXnqCiC9Cg7Dx3ADzjvnmVWBda6NTD/gjov74I/lqMab/qv/Waivf DyQ5yCte78+IAy1nHmHi04D8dTyT24h6pmrUZ50ne+o+AMB+2I5Ecz0uGCNfn9t5 vK4LoKlZm7z45NN6DxOi =h41u -----END PGP SIGNATURE----- --8VlEoeaiv6lkd8vwqjbd63D4bpNBc8KuP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?531AA900.6090406>