Encryption of sensitive information

Currently I'm not aware of any way in which it is possible to encrypt the oracle.server.login parameter in jcart.properties. Is there a way ? 

Whilst talking about this topic I also am wondering if use of the thin java driver to communicate between the Jserver and database is potentially a security flaw. Do you know whether the connection data passed to the database is encrypted ?

Regards

Ant

Hi Ant,

Currently I'm not aware of any way in which it is possible to encrypt the oracle.server.login parameter in jcart.properties. Is there a way ?

There is a way to encrypt the oracle.server.password property. It is described here: http://www.chemaxon.com/jchem/doc/admin/cartridge.html#jcc_super_user .
 

Whilst talking about this topic I also am wondering if use of the thin java driver to communicate between the Jserver and database is potentially a security flaw. Do you know whether the connection data passed to the database is encrypted ?

Oracle's support document Is the Password Encrypted when I Logon and Other Related Questions [ID 271825.1] appears to provide the answer:

1. Is my password encrypted when I logon?


Answer


------


Yes, the Oracle password protocol provides security for client-server and server-server password communication by encrypting passwords passed over a network, . The Oracle password protocol uses a session key, valid for a single database connection attempt to encrypt the user's password. Each connection attempt uses a separate key for encryption, making the encryption more difficult to decipher.


As of version 10.2 password encryption during session authentication is based on the new AES 128 standard except for JDBC thin clients that will support AES as of 11g . Older clients use a modified Data Encryption Standard (DES) algorithm, the best algorithm available in both the server and client is negotiated during the session handshake for reasons of backward compatibility.

Hi Peter, thanks for pointing me to the encryption details in the doco, I had missed it previously. It certainly goes a long way towards achieving what I'd hoped for. Maybe it would be possible to encrypt the oracle.server.login in a future release as well, using the same approach ?

As far as the Oracle documentation is concerned it suggests that there is a potential security issue in using the thin java driver prior to Oracle11g - which may be a good reason to upgrade to 11g sooner rather than later of course. 

As always, thanks for your help.

Ant,

We will provide the option to encrypt login as well.

Regarding the encryption level mentioned in the Oracle document: my interpretation is that there is a lag between the server and the JDBC driver in terms of the supported encryption standard. While servers support AES 128 starting with version 10.2, JDBC drivers support it starting only with 11g. As JChem is bundled with a 11g JDBC driver, I'd assume that AES 128 is used when JChem Server is authenticating through JDBC with an 10.2 Oracle server.

I have to correct myself on one point in my previous posting: oracle.server.login and oracle.server.password property values are not passed through the Java RMI connection. They are only passed, as you wrote, through the JDBC connection.

Peter

Excellent !

I was in the middle of googling details on an 11g thin client to a 10.2 database when I received your reply, but am pretty sure that your interpretation is correct. It should be an easier task to upgrade the client rather than the database of course.

Regards

Ant 

The most important piece of information regarding mixed version setups is probably the interoperability matrix: http://www.oracle.com/technology/tech/java/sqlj_jdbc/index.html

Regards,

Peter

hi again

Just wondering how easy it would be to use an encrypted password when calling jchem_core_pkg.use_password ?  It would be useful for scripting index creations.

Regards

Ant

Hi Ant,

It is not particularly difficult. This feature will be available starting with 5.3.1 -- along with the capability of encrypting oracle.server.login. The only difference between the two encryptions is that you have to call the jcart-util.sh script with a different argument when generating encrypted texts for SQL scripts:

jcart-util.sh encrypt-plain

The reason being that the output with the encrypt argument contains escape sequences required by storing the output in Java property files.

To be sure: the encryption algorythm used by jcart-util.sh is mainly meant to scramble the original only so much as to make it hard to remember or directly use by someone who stumbles upon it by accident. Not unlike most passwords encrypted using some hashing algorythm, I'd consider this encryption in and by itself an assertion by the "system" that the encrypted document is not meant for public use rather than a bullet proof protection against malicious users. More effective protection must include other techniques (such as file system level protection) depending on the security level required.

Peter

Thanks Peter, I'm sure that will be a useful addition to the functionality in 5.3.1.  I note your comments re. the encryption algorithm used, which are both fine and as expected.

Regards

Ant

This feature will be available starting with 5.3.1.

The changes in the release versioning scheme of chemaxon products (described here) apply to this feature as well.

Regards,

Peter

JChem 5.3.2 has been released with the feature discussed here.

Peter