Reason to hardcode username and password in config files

Question

Going through legacy apps written in multiple .NET framework languages (ASP.NET, VB, C#), I always find in their app.config or web.config connection strings with hardcoded and working username and passwords to various SQL Server and IBM databases. There are a huge number of questions on this site about protecting these but what is the reason for storing such information in configuration files when the app also asks for authentication? and do these users (the hardcoded users not the ones who enter credentials) appear in the databases audit logs every time I build and run it?

Answer 1

It's likely that these legacy applications rely on ADO.NET for database connection. The default ConnectionString property includes server name, database name, username and password. A more secure version would be using Windows Authentication to connect to the database instance, which will use the "Integrated Security" tag instead of username and password.

what is the reason for storing such information in configuration files when the app also asks for authentication?

This is unclear. Did you mean that:

• The application would ask for users to provide the same username and password as the one in the connection string in the config file? This means every user of the application knows about this username/password, which would be a security risk.

or

• User logging into the application with their own username and password, and this username and password is then used to establish connection to the database instance. If that is the case then each user account is also configured to be a user in the database server, with access to the database instance that the application is using. This type of setup can be seen in some multi-agency applications where each user is supposed to only access a certain database instance depending on their agency/department. If this is the case then the username and password in the connection string in the config file is used by the application to load data related to authentication, before users log into the application.

and do these users appear in the databases audit logs every time I build and run it?

Not by default unless you setup DDL/DML/login trigger inside the database server to specifically track database connection.