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=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? > > 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... :( >
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. -- Allan Jude
signature.asc
Description: OpenPGP digital signature
