| Author |
Message
|
| ganesh |
 Posted: Thu Mar 01, 2012 7:04 am Post subject: FileInputNode - passphrase setting. |
 |
|
Master
Joined: 18 Jul 2010
Posts: 294
|
I have a scenario where a file input node gets a encrypted file and decrypts using PGP key and passphrase, the decryption logic is handled by java code in JCN.
The java code has passphrase for the private key hardcoded, for security reasons i am going to remove the passphrase from the code and externalize it. I have three options to externalize it...
1) To put the passphrase in a configuration file and make the code read it from cache.
2) To put it in a separate file and set access level security so that not everyone can open it.
3) To put the passphrase in a db table and the code can fetch it.
Is it also possible to store the passphrase in jks key store? The documentation says the jks keystore is for web services security i.e. SOAP nodes can get the passphrase from jks. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Mar 01, 2012 7:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You have several other options to externalize it.
- store it in a queue and the code can browse it and then cache it.
- store it in a user defined configurable service and the code can use the CMP API to read it
- store it in a user defined property and the code can read it
In all cases, you should make sure that the value is at least obfuscated.
I don't believe that jks keystores have the same notion of the stash file that cms keystores have, so I don't believe there's a 'native' way to save this.
Most stand-alone java solutions would have the passphrase be read from a property that had been set with -D on the program invocation or in a properties file. Don't do that with Broker - use one of the more manageable broker native methods mentioned above (udp is the most straight forward). |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Mar 01, 2012 7:25 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
In my projects, I have found that there are many passwords that needs to be secured, not just one. I would suspect overtime, you too will discover the need to get passwords securely for many different user Ids. Also, user Ids and passwords change between environments for the same service (ie. in Test environment, the user Id and password are different than in the Prod environment).
Therefore, one solution I have often implemented is a web service, where passwords are returned when a user Id is presented. The flow calls the password service each time it needs to access a secured resource.
Caching any password is a security risk in its own right. Passwords can show up in core dumps and error logs under certain circumstances. They can also be compromised by accessing the memory that holds these values. So a flow that uses the web service described above gets the needed value before use, accesses the secured resource, then immediately overwrites that variable that contained the password.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Mar 01, 2012 7:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| one solution I have often implemented is a web service, where passwords are returned when a user Id is presented. |
This is a really insecure notion.
At best you are swapping one form of security for another. At worst, you are exposing *all* of your passwords to the entire internal network.
It is never a good idea of any kind to transmit a password across a network link. Let me amend that a bit. It is never a good idea to transmit a password across a network link, where that network link is *NOT* involved in authenticating the password. It gives you two places of vulnerability instead of one. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Mar 01, 2012 7:49 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
There are solutions to address the challenges you mentioned. The mgt feels that placing passwords in UDPs are less secure than getting them from a web service. The password web service IP traffic is restricted to only the runtimes that need access. Ad hoc requests from unrecognized IP addresses are blocked.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| ganesh |
| Posted: Thu Mar 01, 2012 8:39 am Post subject: |
|
|
Master
Joined: 18 Jul 2010
Posts: 294
|
| Thanks mqjeff and lancelotlinc. |
|
| Back to top |
|
|
|
|
