I am on a team that is writing a .NET Core API to service a desktop application. This application used to manage its own database connection through an OracleConnection, and all the values used to connect to the database, including password, were hardcoded into the code (yes, I know).

Currently we are moving these values into a secure location, but my question is, what values do we need to hide? Obviously the password should be on this list. But should we also hide the host, service name, package names, port, service name, or user ID? Anything not on this list that should absolutely be hidden?

  • I'm not sure your question is clear enough. Are the credentials stored on the desktop application for the database itself and just passed through to the web API? Or are the desktop credentials are to authenticate to the web api, and the web api stores the db credentials? – user52472 Feb 2 '17 at 22:09
  • @user52472 The first moving to the last, the credentials were stored hardcoded on the desktop application. That application will no longer access the database directly and the credentials will be stored in a secure location on the API. The root of the question is what types of credentials need to be protected. – kleineg Feb 2 '17 at 22:30
  • What do you mean by "types of credentials" ? – Limit Feb 2 '17 at 22:33
  • Also what are the values that are currently public. Which ones do you think should be private? This will help the community to guide you – Limit Feb 2 '17 at 22:34
  • 1
    What a weird question. Instead you should ask, "What do I need to show?" and conceal everything else. Unless your app supports multiple databases and the end user has to choose one, I fail to see why you should expose anything at all about the connection. – John Wu Feb 3 '17 at 3:42

The real answer is that's going to depend on the security requirements of the client and their threat model, but I will give you what I feel are best practices.

  1. The actual database credentials should never leave the database server. The desktop application would call the service, and the service would call the database. This will allow you to put your database server in an isolated part of the network, and will reduce your attack surface.

  2. Each user must have unique credentials to the service. This is absolutely a requirement. There is no point in doing any of this if you don't have unique logins.

  3. Communication with the server should also be encrypted. Use SSL. Even if it's an intranet application.

  4. A single sign-on (SSO) system is ideal for managing the unique credentials. Think Active Directory, if you're in a Windows environment.

  5. If an SSO system is not possible, then passwords should be encrypted when on disk. There are multiple ways of doing this. If at all possible, use a keychain which is built into the OS, or some other pre-existing solution that has been tested professionally. I would not recommend encrypting anything more than the password, since that can potentially open up more attacks on the cryptosystem. All of the server details (hostname, port, etc) will be visible to anyone who has access to the network or can run netstat on the machine anyway.

Hope that helps.


For an internal application to authenticate a database connection, the client will obviously need to know the server name and port. But any information you present to the users has the potential to make an attacker's job simpler. If your users don't need it, try not to give it to them.

See what kinds of authentication mechanisms are available that don't involve your client having to store or manage usernames and passwords. For a Windows machine connecting to Oracle, try adding Integrated Security=yes in the connection string. That will pass your user's identity and authority to the server, and you won't have to store anything on the client. Of course, you'll need to ensure your users are members of groups that have the access rights needed to connect to the database, and to use it. But you can manage all that through Active Directory, and you shouldn't need to bake user names into your app or into your Oracle database.

  • So if I am reading this right. Hide server name, port, username, and password. Correct? – kleineg Feb 2 '17 at 23:49
  • No, you can't hide the server name and port. The user should already have used their name and password to sign on, you are just telling the ODBC driver to pass their credentials to the database server. – John Deters Feb 3 '17 at 2:26
  • I believe that I can hide the server name and port. The user does not provide that information, it is currently hardcoded, the user should not know that information. And the user's user name and password are different than the database connection's username and password. – kleineg Feb 3 '17 at 14:42
  • 1
    Sorry, when I said "client", I was referring to the application, not the human user. Yes, you can hide the server and port from the user, but not the client. – John Deters Feb 3 '17 at 14:57
  • 1
    By not using the user's credentials to access the database, and instead coding them into the app, you have no good way to limit authority of what the various users can do. A supervisor and a line worker would have the same database access rights. So if a line worker examines the client app, they can figure out how it connects to the database and they can do whatever a supervisor does. Or if you fire a supervisor who still has a copy of the client app, they can still do whatever they could before. – John Deters Feb 3 '17 at 15:05

Your Answer

