This content has been marked as final. Show 8 replies
user6032647 wrote:I am not a security expert so not sure how valid my statement is going to be but IMO for this "How can we prevent someone else from decrypting our database passwords?" , the answer would be "you can't" . Oracle is constantly suggesting people to use more better combinations of special characters, numerics etc. So if you take care of it, chances are that it would not be so easy for someone to break into your passwords. But I am not too sure that any time, the threat can be completely nullified.
First of all sorry if this is a silly question. I'm still quite new to Oracle..
My company is using Toad for Oracle to access our database, now I found some theads on the internet saying there is a tool which allows to decrypt the oracle passwords.
How can we prevent someone else from decrypting our database passwords?
Example thread: http://toadfororacle.com/thread.jspa?threadID=36841
Is this a security concern?
Just my 2 cents.
I am not sure that it is what but what I can suggest is that you should check the same with a very renowned security expert related to Oracle database Pete Finnigan (http://www.petefinnigan.com) . He would be the most appropriate person to comment about the same besides the Guru's over here like Jonathan Lewis, Hans Forbrich (and the list is too long) .
The way I read this is that TOAD stores Oracle connection details in a .ini file, and this file can be decrypted.
Oracle does not store encrypted passwords, it stores hashed passwords which cannot be decrypted. If the hashes are exposed they can be brute-forced, so complex passwords are essential.
This is a TOAD problem. Connection passwords should not be saved (I assume TOAD has the standard Windows "save my password tickbox", haven't used it for years). If this is being used as a mechanism to hide database connection details from TOAD users then a serious security review is needed.
Pl post details of OS and database versions.
Are you referring specifically to Oracle schema passwords ? If so, Oracle employs a hashing algorithm (see http://en.wikipedia.org/wiki/SHA1 for details) - this is a process that cannot be reverse engineered to determine the plain text password from the hash value. One needs a brute force attack to try various combinations of passwords to try and match the hash value (assuming one knows the hashing algorithm in the first place).
11g R1 New Feature : Case Sensitive Passwords and Strong User Authentication [ID 429465.1]
User Passwords Are No Longer Visible In DBA_USERS As Of 11g [ID 735651.1]
Your best bet is to encrypt traffic between the client (TOAD) and the database/listener - use Advanced Security Option (this requires a separate license)
Oracle Advanced Security Frequently Asked Questions [ID 165465.1]
Is this a security concern?
Is that an oracle issue, or a Toad issue?
A Toad issue.
As the link explains Toad stores connection password information in a file (e.g. connectionpwds.ini) and it is this file that is being decrypted.
Sql Developer has the same issue since it also stores encrypted passwords in a file on the client.
Passwords are secure until they aren't stored.
Oracle database do not store password (store only the hash that cannot be decrypted) so it is quite secure.
But when you give a password to someone else, you loose the ownership of that password and the security of that password is demanded to others.
If you (or someone else that know your password) store the password (encrypted, in plain text, on a post-it on the screen, ...) that password can be retrieved by you (and this is good because you cannot remember all passwords) but can be retrieved also by unwanted people (in many ways).
So the tradeoff between security and ease of use can be to store the passwords protected with a good Master password that you keep only in your mind (and all other people that know your password must do the same).
I think that Quest Software must give to Toad users the ability to:
* Not store passwords (the most secure option, it is already implemented)
* Store passwords protected by a Master password required when you start Toad (my favorite option, but not yet implemented)
* Store passwords encrypted with an algorithm not disclosed (the current implementation, but I don't like undisclosed security)
* Store passwords in plain text (very insecure but the user should be free to choose its [un]security policy, and no one can prevent the user does not write the password in clear text on a post-it)
* Export and Import passwords with the same level of security used to store them (e.g. if you set a Master Password, it must be required to export AND to import the passwords)