I am working on an application that uses Oracle OCI to connect to the Oracle database server. The application allows the user to change their Oracle password and uses Alter User xxx Identified By to perform this.
However, this transmits the user's new password in clear text over the network (we cannot use Oracle SSL to encrypt network traffic). I have found that Oracle recommends using the PASSWORD command in SQLPlus rather than ALTER USER, one reason being that the new password encrypted.
Does the OCI method OCIPasswordChange also encrypt the new password when it is transmitted over the network?
This is using Oracle 10 and 11.
Yes, OCIPasswordChange does encrypt the new password sent over the network.
I have now implemented this and done a packet trace. An encrypted AUTH_NEWPASSWORD packet is transmitted to the Oracle database server.
Related
I need to create a user in an oracle database that only allows connections through JDBC and not through some IDE for example, is this possible?
There's no good, foolproof way to do what you're asking (limit connections based on connection protocol, or other client-side parameters). Any of the session parameters that you could base a database logon trigger or smart application role on can be spoofed or altered to bypass your security filter. The generally accepted approach is to secure a user account's permissions so that it doesn't matter how they connect - their access to and view of the data is always the same.
If you want to limit access just to your application server, do this using firewall rules on the database server that only allow inbound connections from the app server IP on the database port, or (if you have Enterprise Edition) use Oracle Connection Manager to filter access by IP address and Oracle Service Name.
Basically it hard to set this up really securely.
You can use such an approach:
Create DB user with no privileges on Application schema (except for connect)
Grant user password protected ROLE: APP_ROLE. Having access to APP_SCHEMA tables.
In your app, after DB logon execute:
SET ROLE APP_ROLE IDENTIFIED BY "some role's password";
Then execute:
ALTER SESSION SET CURRENT_SCHEMA='APPL_SCHEMA';
So even if anybody know username and password for database, he can connect, but is not allowed to see any data. APP_ROLE's password is hard-coded in your app, or is passed to your app from outer source (config file or databases global context).
So basically you need two passwords to access database data:
user's password
role's password
When a user logs in to the (linux/unix) system as a user and runs a 4GL or ESQL/C program, the program can connect to a DB as the system account user without entering a password. e.g. If I login as rob and run a program it can connect to a DB without providing a password, providing rob has connect permission.
I would like to do a similar thing with a local java program that uses JDBC to talk to the DB server. Is this possible?
Yes, this is fully supported in the JDBC driver for Informix. You can connect without a password as the user who started the Java process that is on the same machine as the Informix server.
As Luis notes in his comment, you forego the username and password fields in your JDBC URL for this to work.
I have an application which has been successfully logging into our database for years without issue.
The password hasn't changed and i can manually login.
I enabled the audit trail in the database and can see the failed login attempt and return code of 1017 indicating invalid username and password combination.
The password being entered in the application is correct but is still being rejected by the database. I confirmed the user and pass combination by logging in with SQL Developer.
Is there any way for the audit trail to show the password being received so that i can find out how the password is being altered between the app and the db.
Are there any other causes to 1017 than an invalid user/pass?
No, the audit trail does not show the passwords of failed log in attempts. Using the audit trail you can determine things such as the machine name and OS user that is attempting to log in, but it will not capture the password that was used.
Since this application has been logging into the database for years, I am guessing that the database itself has been updated a number of times, correct? If so, is it possible that you are running into password case sensitivity issues as a result of an older client being used on the application side? If the application is connecting from a machine using an older client, you may want to check out this question: ORA-01017 Invalid Username/Password when connecting to 11g database from 9i client
To test this hypothesis, you could try logging in from the application side by using quotes to pass the credentials. From the question above:
oracle9i defaults to uppercase as it didn't cater for case
sensitivity. instead of changing the database to insensitive, you can
connect by pasting your password in double quotes eg `sqlplus
youruser/"Password"#db to pass mixed case.
If that is not the case, and you want to determine what password is being passed from the application to rule out that avenue, you could use a tool like Wireshark to listen to the traffic and see if you can sniff out what credentials they're using, assuming they aren't using an encrypted connection. Please only explore this if you have complete control over the network or the permission from the appropriate powers that be, as it could be illegal or against your organizations policy to use a tool like Wireshark without permission.
Am conducting a penetration test on Oracle flexcube direct banking solution. I managed to retrive a users login dump from the system however the fldPassword value is encrypted.
If i have the fldPassword=value and fldEncrKey=value. How is it possible to decrypt fldPassword?
Oracle FCDB user's password can't be decrypt back because FCDB password encryption/hashing is a one-way trip. During authentication the plain input password decrypt and compare with the stored fldPassword.
We are trying to shape up an old, 2 tier, Delphi based application. It originally uses database authentication, we'd like to transform the db user accounts to global users, so an OID server could perform the authentication instead of the database.
The Delphi program can no longer log into the database if the account is a global user. I'm trying to understand the login protocol, so far without results.
Similar thing happens with SQLDeveloper, I can't connect as a global user. SQLPlus however works with both kinds of users. We checked the information flow with Wireshark. When the dbserver asks back for a password, the SQLPlus sends it, while the SQLDeveloper doesn't send a password when attempting to connect as a global user.
The client sends the application name too in the login request. Is it possible that we have to store the client app name in the LDAP itself?
To connect to Oracle using OID, application must properly configure OCI (Oracle Call Interface). The data access components (which one ?), you are using, must set OCI_ATTR_DISTINGUISHED_NAME session attribute. If that is not done, then you will be not able to connect to Oracle server using ODI and OCI.
You should check your components documentation for this feature. And if it is not implemented, then discuss this issue with the components vendor. Actually, there is not much work to implement, but some work to setup testing environment is required ...