Re: [Ejbca-develop] debug log ejbca.sh

[Tomas G. <to...@pr...>]

It all depends on what you are trying to protect against.

What's your threat analysis?
Are you protecting against someone dumping the EJBCA database trying to 
brute-force one-time enrollment codes before they are being used?

16 rounds is too slow even for a single use imho. On my laptop a single 
call (a single bcrypt) with 16 rounds takes >20 seconds.

/Tomas


On 2015-02-26 16:09, Michael Ströder wrote:
> Tomas Gustavsson wrote:
>>
>> Ok, as far as I can see there is:
>>
>> - One call starting the command (getting list of CA ids)
>> - One call for each CA in the system (getting detailed information for
>> the specific CA)
>>
>> So when your first CA shows up, you have run two bcrypt operations.
>
> So there is not kind of a session established between ejbca.sh and JBOSS.
>
>> Do you have very many CAs?
>
> Half a dozen, could be some more in the long run.
>
>> If you are using 16 rounds and it is too slow, I think you are using too
>> many rounds. The security of bcrypt is about how long time you want it
>> to take, so if it takes too long, you're using too many rounds.
>>
>> http://security.stackexchange.com/questions/17207/recommended-of-rounds-for-bcrypt
>
> The only reasonable comment on the page above is the cause for the user's
> question:
>
> "The speed of my own system should not be leading for the number of
> iterations. It is the current speed of the brute-forcers that should dictate
> how many iterations are considered safe."
>
> Yes!!! The whole point of using a strong password hashing schemes is to
> protect against the brute force power of off-line attacks (hashcat with big
> graphic cards) and *not* the amount of time of local command invocation.
>
> An acceptable timing using ejbca.sh is currently using 2^8 = 256 rounds but I
> guess this makes brute force programmers laught about.
>
> Ciao, Michael.
>
>> On 2015-02-26 08:19, Michael Ströder wrote:
>>> Tomas Gustavsson wrote:
>>>> It would be good if you include a little more of the original conversation.
>>>> What was the command you were running again that is slow?
>>>
>>> ejbca.sh ca editca --help (see old message attached below).
>>>
>>>> But, using bcrypt with many rounds does affect performance ;-)
>>>
>>> But I did not expect the impact to be so big and to vary for differnt
>>> commands. I suspect the password is checked many times for some commands. Right?
>>>
>>> I'm currently using ejbca.passwordlogrounds=8 for acceptable performance which
>>> is not that much for *the* sensitive admin password.
>>>
>>> Ciao, Michael.
>>>
>>> -------- Forwarded Message --------
>>> Subject: [Ejbca-develop] ejbca.sh slow
>>> Date: Wed, 26 Nov 2014 15:35:24 +0100
>>> From: Michael Ströder <mi...@st...>
>>> Reply-To: ejb...@li...
>>> To: ejb...@li...
>>>
>>> HI!
>>>
>>> I'm having a hard time finding out why sometimes (not always) ejbca.sh is so
>>> damn slow:
>>>
>>> root@vm-ejbca-ocsp-01:~# time /opt/ejbca/bin/ejbca.sh ca --help
>>> [..]
>>> real	0m2.251s
>>> user	0m2.748s
>>> sys	0m0.288s
>>> root@vm-ejbca-ocsp-01:~# time /opt/ejbca/bin/ejbca.sh ca editca --help
>>> [..]
>>> real	0m25.008s
>>> user	0m18.069s
>>> sys	0m0.192s
>>>
>>> I'm looking with strace and tcpdump what's going on. But still nothing obvious.
>>>
>>> Which debug logs should I enable in the JVM?
>>>
>>> BTW: Any reason why using --help requires a running JBOSS?
>>>
>>> Ciao, Michael.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>>> things parallel software development, from weekly thought leadership blogs to
>>> news, videos, case studies, tutorials and more. Take a look and join the
>>> conversation now. http://goparallel.sourceforge.net/
>>>
>>>
>>>
>>> _______________________________________________
>>> Ejbca-develop mailing list
>>> Ejb...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejb...@li...
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>
>
>
> --
> Michael Ströder                 Klauprechtstr. 11
> Dipl.-Inform.                   D-76137 Karlsruhe, Germany
> Tel.: +49 721 8304316           Mobil: +49 170 2391920
> E-Mail: mi...@st...    http://www.stroeder.com
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>