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_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... :( > 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_at_ 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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:47 UTC