I am currently maintaining an excel file with a great amount of oracle db connection information, including database name, server, port, user name, password, etc...I am trying to develop a VBA macro to export all db connection information into XML format, which could be imported directly into Oracle to get everything updated easily.
Here I have a question regarding to password encryption in this VBA macro. Knowing that password in the excel file is not encrypted, I want to make them encrypted in the exported XML file. I think I should encrypt password the same way as Oracle does, so that once XMl file generated from excel and imported in Oracle, Oracle can decrypt it correctly.
So I would like to know how oracle encryption works for password. Also, is there any corresponding function in VBA that would do the trick directly ?
Thanks
Related
My requirement is to do column level encryption.
Tried below option
TDE - data is not encrypted to one who has access to database. Please correct me if I'm wrong.
DBMS_CRYPTO package, this works but client wants to store encryption key outside Oracle database.
I'm not able to find solution for storing key outside database.
Any help on this is highly appreciated.
Perhaps two different things here.
To do TDE at column level already uses an external key store, namely a wallet. The location is specified by ENCRYPTION_WALLET_LOCATION in your sqlnet.ora file, and you'd open the wallet when the database starts, eg
ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "thePasswordIchose";
Conversely, if you are looking at doing some "home grown" encryption of data using DBMS_CRYPTO, then key management also becomes your own responsibility. You could store the key however/wherever you like, but its your job then to manage it and pass it securely into the DBMS_CRYPTO routines
We need to send data from db2 (db2 for AS400) to another data warehouse platform (Hive). But we need to encrypt data in DB2 first. And then target server will connect to DB2 to export data and decrypt data in target server.
SQL to encrypt data in DB2:
INSERT INTO TESTAES
SELECT ENCRYPT_AES( ACCOUNT, '1234567890') FROM TESTPLAIN;
I know the DECRYPT_CHAR function in DB2:
SELECT DECRYPT_CHAR( ACCOUNT, '1234567890') FROM TESTAES
But after we load this table to another platform, we don't know how to decrypt the data. We don't know the DB2 decryption algorithm.
The way I thinks may works:
(1) Get the decryption algorithm of ENCRYPT_AES in DB2 and we can write a program in targer server to decrypt the data. But IBM shared this in any documents. I searched it in IBM DB2 document, just told us
Encryption algorithm: The internal encryption algorithm used is from the CLiC Toolkit from IBM Research. The 128-bit encryption key is derived from the password using a SHA1 message digest?https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/db2/rbafzscaencryptaes.htm
(2) Get the decryption algorithm package of ENCRYPT_AES in DB2 and we can import this package in targer server to decrypt the data. Did IBM have such package?
(3) Use another open-source/common function/package to encrypt data in DB2. And we know the algorithm and we can write program/or use the same algorithm package to decrypt the data. But I don't how can we encrypt data in AS400 db2 except ENCRYPT_AES. Maybe write a java program or something else?
Would anyone share this experience in encrypted data migration to another platform.
it is standard AES algorithm, but the default CCSID in AS400 is EBCDIC.
do you need to convert DATA to UTF-8 after decryption.
I think this question can be closed. Becuase
(1) I asked IBM Technical Support, he suggest us to write encryption/decryption function by ourselves. Maybe the algorithm of DB2 encryption function is a secret.
(2) I created an DB2 UDF to call Java Program in AS400. Finally, it works. I can encrypt data in DB2 and after other database get encrypted data and it can be decrypted in other database.
Below is the oracle fixed user private dblink "create statement" as it is defined in the server. This is working fine. Now my question is, does the password mentioned in the statement PWD mean that it fetches the password from ldap or from oracle vault or it is the actual password itself?
For fixed user database links, the passwords are stored in the data dictionary. In former Oracle versions the password was stored unencrypted, but this has changed now.
I'm using japsersoft studio, I want to create my own custom data adapter for jdbc connection, so that connection details will be stored in file or class or package we can say.... and using this file I"m going to connect with data source in jaspersoft.
I have searched on internet but found nothing.
So if there is any way to create our own custom adapter for jdbc connection in jaspsersoft studio it will very helpful.
Or any way through which I can store jdbc(data source) credentials in file and can use that file for accessing database connection in jasper studio. so if i modify details in file then database source should also be modified in jaspersoft.
Thank you.
You may be interested in exporting your DataAdapter defined in JSS to an XML file and reference that one instead. More info here: Importing and Exporting Data Sources.
Be warned, that if you want to share the adapter file you will be, most likely, saving the credentials in clear text which is totally unsafe. A more secure way would be to enable the Secure Storage for credentials. This way, instead of the password, your file will contain the encrypted password.
If you export and save the adapter file inside your JSS project you can pick it from the DataAdapter drop-down when previewing the report.
We are connecting to Oracle using KornShell (ksh) scripts, which use SQL*Plus to connect to Oracle. The Oracle database is on the same Solaris box. Currently, we are storing Oracle user id and password (plain text) in a file in the .ssh folder of the connecting user, with 400 permission bits.
The DBAs are objecting to this way of working, citing the fact that we are using plain text password for authentication. When we offered that we would encode the password using base64, they still did not like the idea, citing that we would still decrypt the password in the shell script and transmit the password over network.
Now, I want to understand this-
I have been reading that Oracle encrypts/hashes the password string, before transmitting it. I can not find the reference right now though, however, I still want to confirm my understanding. Is it really like this? We are on 11g r2, would that make a difference?
Would I be able to login to SQL*Plus without decrypting the password hash? e.g., DBAs set a password, pass on the hash to me. I put that in a file, and supply to SQL*Plus as a parameter. Is there some way by which this kind of authentication work? I know some tools do allow that, if you encode using their tool, they are able to decrypt the value and use it for authentication. Does Oracle?
Help me fellas.
Its been a while since doing this (and I don't have a linux box handy atm), but you can try this to hide details from ps:
echo password | sqlplus -s username#database #myscript.sql
Note that -s is silent mode for sqlplus. I believe you can also put the password in a "protected" file (I use the term loosely, but set bits to 400) and cat the file, piping to sqlplus as above.
Edit:
If the DBAs are really concerned with passwords, then how about using NO passwords. You can try OS authentication, but you need some setup first. For example:
--in Oracle, create new user
create user ops$batch_user IDENTIFIED EXTERNALLY;
grant connect to ops$batch_user;
-- in Unix (login as batch_user, or use su command)
export ORACLE_HOME=/app/oracle/product/11.2
export PATH=$PATH:$ORACLE_HOME/bin
export ORACLE_SID=DEV
sqlplus /
Note that no passwords are used since the user is authenticated by the os. This is less complicated than Oracle wallet imo, but not perfect either.
How exactly are you connecting to the db? If you use sqlplus user/password#database from your commandline/script then you indeeed have a problem. The reason is, that you can easily see the password with the ps command.
Obfuscating it with Base64 is not really an encryption, because Base64 is a known algorithm for transfering binary data over the wire. This might baffle some, but certainly is not a safe way of sending a password.
What I do in this case, to avoid the password being shown int he process list, is that I write the password to a textfile with read only permission for the local user. Then I run sqlplus with nohup or in the background sqlplus user#db < pwdfile and immediately delete the file again.
You can use Oracle Wallets for DB authentication.
Example of tuning may be found here.