0

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?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
CathalMF
  • 9,705
  • 6
  • 70
  • 106

1 Answers1

0

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.

1991DBA
  • 805
  • 1
  • 9
  • 18
  • No database upgrades have occurred since about a year ago and we have been running 12c since then. Everything worked fine. Ive used wireshark and can see the connection string being sent however the connection string does not contain the username and password. Any idea how to get these with wireshark? – CathalMF Nov 09 '18 at 17:44
  • If you can see everything being passed in the connection string except the username or password, that is probably where the issue lies. How does the application access the database? I would wager that something has changed on the application side rather than this being an issue with the database itself, especially since you are able to access the database using the same credentials on your end. – 1991DBA Nov 09 '18 at 18:08
  • There is another application successfully connecting and I can't see the user and pass for that either. – CathalMF Nov 09 '18 at 18:09
  • How do these applications access the database, do they use the same method? I.e. Are they using jdbc connection strings or ODBC or something else? – 1991DBA Nov 09 '18 at 18:13
  • Yes they use the same method. This one https://www.c-sharpcorner.com/UploadFile/cb92fb/connecting-to-oracle-database-through-C-Sharp/ – CathalMF Nov 09 '18 at 18:21
  • Have you confirmed that the definition of the connection has the correct password? I would recommend trying to redefine the "string oradb" equivalent within your application and seeing if that has any impact. You could create a simple user with the create session privilege to see if using a different username has any impact as well. – 1991DBA Nov 09 '18 at 18:40