I'd be more than interesting for me to understand which technique is being used here to persist sensible data since I'm needing to implement a similar solution. Here's a sample connection configuration and the resulting exported snippet:
Oracle SQL Developer Connections http://i44.tinypic.com/2lcwpkg.gif
<?xml version = '1.0' encoding = 'UTF-8'?>
<References xmlns="http://xmlns.oracle.com/adf/jndi">
<Reference name="My Connection" className="oracle.jdeveloper.db.adapter.DatabaseProvider" xmlns="">
<Factory className="oracle.jdeveloper.db.adapter.DatabaseProviderFactory"/>
<RefAddresses>
<StringRefAddr addrType="user">
<Contents>username</Contents>
</StringRefAddr>
<StringRefAddr addrType="password">
<Contents>054D4844D8549C0DB78EE1A98FE4E085B8A484D20A81F7DCF8</Contents>
</StringRefAddr>
<SKIPPED />
</RefAddresses>
</Reference>
</References>
Any advice would be really appreciated.
I don't know, but I wouldn't be surprised if it was DBMS_OBFUSCATION_TOOLKIT being used something like this:
The same code as kornelissietsma has given, but written on java:
Can be executed as following:
For the curious, what you're actually seeing is the secret key concatenated with the encrypted password. For example, I tried encrypting the password "SAILBOAT" using:
In this particular instance, the result was:
The first byte is constant:
The next 8 bytes represent the randomly generated secret key (for the DES cipher):
The remaining bytes are the encrypted password:
Therefore, to decrypt the password, you simply use this:
Note that Tim's password hash above is not for "apps_ro" - presumably he cut and pasted from the wrong place... I won't post the real password in case it's something he doesn't want shared!
I had a similar problem, trying to store my db credentials centrally (for non-secure databases!) and then exporting sql developer xml files. I have no idea what the algorithm is - however, you don't really need to know the algorithm, as you can just call the Oracle java API yourself. If you have SQLDeveloper, just grab the right Jar files:
Then either load them in your Java app, or use something like JRuby as I do:
Note that the algorithm, whatever it is, has a random factor so the same password used twice can produce two different hex strings.
FYI the password 'apps_ro' encrypts as:
Given solution is too old and only works with version 2.x but not now. because Oracle SQL Developer, changed the encryption algorithm in version 3.x and 4.x.
Version 3
Passwords are stored encrypted in the connections.xml file in those locations:
Version 4
Passwords are stored encrypted in the aforementioned connections.xml file but the encryption key uses a machine-unique value db.system.id in the product-preferences.xml file accessible here:
To decrypt latest encrypted file you can use Show me password extension for SQL Developer. Or decrypt file with SQL Developer password decryptor