Menu
▾
▴
ejbca-develop
|
From: Michael S. <mi...@st...> - 2014-12-03 16:22:02
|
HI! How can I trace what's going on within ejbca.sh? I'm still looking why it's so slow in my setup. Ciao, Michael. |
|
From: Tomas G. <to...@pr...> - 2014-12-03 16:38:24
|
Enable trace logging and check in the server.log if there are any strange pauses. Also apply recommended database indexes from doc/sql-scripts. Cheers, TOmas On 2014-12-03 17:21, Michael Ströder wrote: > HI! > > How can I trace what's going on within ejbca.sh? > > I'm still looking why it's so slow in my setup. > > Ciao, Michael. > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Michael S. <mi...@st...> - 2014-12-03 16:55:42
|
Tomas Gustavsson <to...@pr...> wrote > Enable trace logging How? For ejbca.sh I'm looking here: /dist/ejbca-ejb-cli/log4j.xml /src/java/log4j.properties Are those the right files to tweak ejbca.sh console output? Ciao, Michael. |
|
From: Tomas G. <to...@pr...> - 2014-12-03 17:19:58
|
Yes that should be it. I was actually thinking about the server log as well, so you can see if there is anything on the server side that is slow. But the client is good first of course. Regards, Tomas On 2014-12-03 17:55, Michael Ströder wrote: > Tomas Gustavsson <to...@pr...> wrote >> Enable trace logging > > How? > > For ejbca.sh I'm looking here: > /dist/ejbca-ejb-cli/log4j.xml > /src/java/log4j.properties > > Are those the right files to tweak ejbca.sh console output? > > Ciao, Michael. > > |
|
From: Michael S. <mi...@st...> - 2015-01-27 22:05:12
Attachments:
smime.p7s
|
Tomas, this issue is still driving me crazy... :-[ ejbca.sh ca listcas takes nearly a minute on different systems. Tomas Gustavsson wrote: > On 2014-12-03 17:55, Michael Ströder wrote: >> Tomas Gustavsson <to...@pr...> wrote >>> Enable trace logging >> >> How? >> >> For ejbca.sh I'm looking here: >> /dist/ejbca-ejb-cli/log4j.xml >> /src/java/log4j.properties >> >> Are those the right files to tweak ejbca.sh console output? > > Yes that should be it. > > I was actually thinking about the server log as well, so you can see if there > is anything on the server side that is slow. But the client is good first of > course. Could you please suggest a content of the files above writing out nearly everything? Ciao, Michael. |
|
From: Michael S. <mi...@st...> - 2015-02-25 20:45:16
|
Michael Ströder wrote: > this issue is still driving me crazy... :-[ > > ejbca.sh ca listcas takes nearly a minute on different systems. A colleague found out that it took so much time because I set ejbca.passwordlogrounds=16 It seems to me that the password check with the 2^16 rounds is performed many times, not only once within kind of a session. Ciao, Michael. |
|
From: Tomas G. <to...@pr...> - 2015-02-26 06:07:18
|
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? But, using bcrypt with many rounds does affect performance ;-) Cheers, Tomas On February 25, 2015 9:45:02 PM GMT+01:00, "Michael Ströder" <mi...@st...> wrote: >Michael Ströder wrote: >> this issue is still driving me crazy... :-[ >> >> ejbca.sh ca listcas takes nearly a minute on different systems. > >A colleague found out that it took so much time because I set > >ejbca.passwordlogrounds=16 > >It seems to me that the password check with the 2^16 rounds is >performed many >times, not only once within kind of a session. > >Ciao, Michael. |
|
From: Michael S. <mi...@st...> - 2015-02-26 07:19:45
Attachments:
smime.p7s
|
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. |
|
From: Tomas G. <to...@pr...> - 2015-02-26 14:02:57
|
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. Do you have very many CAs? 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 Regards, Tomas 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 > |
|
From: Michael S. <mi...@st...> - 2015-02-26 15:09:34
Attachments:
smime.p7s
|
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 |
|
From: Manuel D. <ma...@de...> - 2015-02-26 15:54:35
|
*off-topic* I cannot add any content to the original question of why this or that command is so slow, but I'd like to comment on how the "rounds" of a key derivation hash, see below. On Thu, Feb 26, 2015 at 4:09 PM, Michael Ströder <mi...@st...> wrote: > 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. Not quite. Yes, it is the whole point of using a strong password hashing scheme to protect against brute force attacks as much as possible. The hashing mechanism should in itself already be safe. The point of doing additional rounds is not to secure a single password. The point of doing additional rounds is to push the safety margins as far as possible before it hurts for normal operation of a single user (logon, ...), SO THAT it does hurt (if) an attacker tries to crack a long table/list of passwords that has been dumped somewhere or even tries to brute force every conceivable combination of chars. You are concerned about the security now and confidentiality in the far future ? Then increase the number of rounds (or change the password more often in the future, with steady higher number of rounds) and live with the performance impact :) of course, what I am saying here is helping neither of you, I am well aware of that :) cheers, Manuel |
|
From: Tomas G. <to...@pr...> - 2015-02-26 15:39:46
|
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 > |
|
From: Michael S. <mi...@st...> - 2015-02-26 16:08:16
Attachments:
smime.p7s
|
Tomas Gustavsson wrote: > 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? Yes. Or a SQL injection revealing the user's password via web application. > 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. The important factor is at what speed brute force attackers can work. Ciao, Michael. |
|
From: Tomas G. <to...@pr...> - 2015-02-26 16:48:19
|
What's your use case? Why don't you use 24 character randomly generated one-time enrollment codes? You can surely design your work-flow to be more secure, still giving a decent user experience, better than waiting 30 seconds in a browser window? Cheers, Tomas On February 26, 2015 5:08:03 PM GMT+01:00, "Michael Ströder" <mi...@st...> wrote: >Tomas Gustavsson wrote: >> 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? > >Yes. Or a SQL injection revealing the user's password via web >application. > >> 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. > >The important factor is at what speed brute force attackers can work. > >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 |
|
From: Tomas G. <to...@pr...> - 2015-02-26 16:52:46
|
You know that you can limit how long an enrollment code is active? On February 26, 2015 5:48:06 PM GMT+01:00, Tomas Gustavsson <to...@pr...> wrote: >What's your use case? Why don't you use 24 character randomly generated >one-time enrollment codes? > >You can surely design your work-flow to be more secure, still giving a >decent user experience, better than waiting 30 seconds in a browser >window? > >Cheers, >Tomas > >On February 26, 2015 5:08:03 PM GMT+01:00, "Michael Ströder" ><mi...@st...> wrote: >>Tomas Gustavsson wrote: >>> 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? >> >>Yes. Or a SQL injection revealing the user's password via web >>application. >> >>> 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. >> >>The important factor is at what speed brute force attackers can work. >> >>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 |
|
From: martijn.list <mar...@gm...> - 2015-02-26 17:05:21
|
On 02/26/2015 05:48 PM, Tomas Gustavsson wrote: > What's your use case? Why don't you use 24 character randomly generated > one-time enrollment codes? > > You can surely design your work-flow to be more secure, still giving a > decent user experience, better than waiting 30 seconds in a browser window? It also makes your application vulnerable to a DOS. If you try to login with 100 parallel connections using random passwords, your server comes to a grinding halt going through all the rounds. If you want to use this many rounds, you should put the burden on the client. For example by using javascript to go calculate all the rounds. Downside of this is that javascript is probably too slow to make this acceptable. Kind regards, Martijn Brinkers -- CipherMail email encryption Open source email encryption gateway with support for S/MIME, OpenPGP and PDF messaging. http://www.ciphermail.com Twitter: http://twitter.com/CipherMail > On February 26, 2015 5:08:03 PM GMT+01:00, "Michael Ströder" > <mi...@st...> wrote: > > Tomas Gustavsson wrote: > > 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? > > > Yes. Or a SQL injection revealing the user's password via web application. > > 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. > > > The important factor is at what speed brute force attackers can work. > > 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 > |
|
From: Michael S. <mi...@st...> - 2015-02-26 17:21:42
Attachments:
smime.p7s
|
Tomas Gustavsson wrote: > What's your use case? Why don't you use 24 character randomly generated one-time enrollment codes? I'm not talking about enrollment codes. I'm talking about user and its log-term password used with ejbca.sh on a local system command-line (see subject). Since EJBCA is a monolithic web application with a single DB user accessing the whole database a SQL injection flaw could reveal the password hash to an attacker. I wish local connections could go over Unix Domain Socket and get authenticated based on Unix peer credentials making such a long-term password unnecessary. Same for accessing the local DB. But I guess that's pretty unusual (or even impossible) with Java. Ciao, Michael. |
|
From: Tomas G. <to...@pr...> - 2015-02-26 17:54:52
|
That password should use a non brutable length. If you wish you can disable the command line interface completely even. Anyhow, the cli password is only usable for the cli. If you manage to get hold of it, you also need to manage to get access to the command line of your CA, not so easy I hope. /Tomas On February 26, 2015 6:21:26 PM GMT+01:00, "Michael Ströder" <mi...@st...> wrote: >Tomas Gustavsson wrote: >> What's your use case? Why don't you use 24 character randomly >generated one-time enrollment codes? > >I'm not talking about enrollment codes. I'm talking about user and its >log-term password used with ejbca.sh on a local system command-line >(see subject). > >Since EJBCA is a monolithic web application with a single DB user >accessing >the whole database a SQL injection flaw could reveal the password hash >to an >attacker. > >I wish local connections could go over Unix Domain Socket and get >authenticated based on Unix peer credentials making such a long-term >password >unnecessary. Same for accessing the local DB. But I guess that's pretty >unusual (or even impossible) with Java. > >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 |
|
From: Michael S. <mi...@st...> - 2015-02-27 08:41:12
Attachments:
smime.p7s
|
Tomas Gustavsson wrote: > That password should use a non brutable length. Yes, of course. > If you wish you can disable the command line interface completely even. I deliberately keep this enabled until it's sure that the admins take care of renewing their admin certs in time. > Anyhow, the cli password is only usable for the cli. If you manage to get > hold of it, you also need to manage to get access to the command line of > your CA, not so easy I hope. I also hope this and of course the operators are doing their best to harden the machines. But given all the really serious security threats in Java during the last 2 years I'm really concerned that I have to allow direct HTTPS access to adminweb for individual authentication/authorization with client certs. Letting components run under different OS accounts communicating over Unix Domain Sockets (or other OS pipes) would be really great. Ciao, Michael. |
|
From: Tomas G. <to...@pr...> - 2015-02-27 10:00:32
|
Https and Java is of course another topic than bcrypt performance. You can implement various barriers and additional steps to further harden this access as well. We managed to be non affected by most of these vulnerabilities in our implementations. There is of course never any definite guarantee against vulnerabilities. Cheers, Tomas On February 27, 2015 9:41:00 AM GMT+01:00, "Michael Ströder" <mi...@st...> wrote: >Tomas Gustavsson wrote: >> That password should use a non brutable length. > >Yes, of course. > >> If you wish you can disable the command line interface completely >even. > >I deliberately keep this enabled until it's sure that the admins take >care of >renewing their admin certs in time. > >> Anyhow, the cli password is only usable for the cli. If you manage to >get >> hold of it, you also need to manage to get access to the command line >of >> your CA, not so easy I hope. > >I also hope this and of course the operators are doing their best to >harden >the machines. But given all the really serious security threats in Java >during >the last 2 years I'm really concerned that I have to allow direct HTTPS >access >to adminweb for individual authentication/authorization with client >certs. > >Letting components run under different OS accounts communicating over >Unix >Domain Sockets (or other OS pipes) would be really great. > >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 |
