On 2014-03-07 21:15, John-Mark Gurney wrote:
> Xin Li wrote this message on Fri, Mar 07, 2014 at 16:43 -0800:
>> 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

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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to