Remote connection scheme without Windows Authentication/Domain in detail [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed last year.

Improve this question

There is a legacy C++ system that needs to be "translated", that uses ODBC for connecting to remote SQL Server Database.

System is distributed to many different OS and different domains, some always online, some updated on connection, some updated via sending/receiving updates in the form of files.

Each user has been registered in the SQL Server and with certain user roles on the database.

When a user is trying to login to the system, he actually sends his id and password to the application, which in turn are packed with a common/central SA account and query the central / distributed database where a table exists with all the relevant id/passwords, depending on the role of the local domain.

If the user has been registered in the database and his id and pass are a match, then he is given the green light to enter the application and his user id and password are thereafter used on every transaction, somehow variably hard-coded, in order to avoid to system questioning the id and pass on every recordset buildup.

My question is how this scheme should be modified to comply with established best practices on remote SQL Server access.

PS: Should a creation of database users is preferred, how a new user can insert his credentials to create a new profile on the database without elevating his role to more than datareader / datawriter

Answer 1

how safe is this remote SQL Server access scheme

The shared account credentials embedded in the application can be read by anyone who controls a computer on which the application runs. No matter how you try to hide the credentials, you can never hide from a user with a debugger, who can just set a break point on the function that handles the password and examine the memory.

And from the description, it sounds like having access to the shared user credentials would, at the very least, allow a user to perform actions as some other user. So unless you really trust all these users, this scheme isn't very good.

When a user is trying to login to the system, he actually sends his id and password to the application ... whether there is an alternative or better to say a best practice on this problem.

Create a SQL Server Login or Contained Database User for each application user, instead just storing the users in a table, and use the credentials presented by the user to authenticate to SQL Server.