Connection String Security Concerns
-
I've written a series of ASP and winform applications for a database my one of my company's software vendors built. The vendor puts user login credentials in the sql connection strings in order to authenticate users. Since the same database is to be used, I have to use the same authentication method to keep users from being confused with additional usernames/passwords to remember. Other than an attacker appending
Integrated Security=Trueto the end of the connection string. What security issues should I be concerned about with this method? -
I've written a series of ASP and winform applications for a database my one of my company's software vendors built. The vendor puts user login credentials in the sql connection strings in order to authenticate users. Since the same database is to be used, I have to use the same authentication method to keep users from being confused with additional usernames/passwords to remember. Other than an attacker appending
Integrated Security=Trueto the end of the connection string. What security issues should I be concerned about with this method?Make sure that the connecting user only have access to the bare minimum he requires. Such as only execute on sprocs and not access to change the sprocs, or direct access to the underlying tables.
--------------------------- Blogging about SQL, Technology and many other things
-
I've written a series of ASP and winform applications for a database my one of my company's software vendors built. The vendor puts user login credentials in the sql connection strings in order to authenticate users. Since the same database is to be used, I have to use the same authentication method to keep users from being confused with additional usernames/passwords to remember. Other than an attacker appending
Integrated Security=Trueto the end of the connection string. What security issues should I be concerned about with this method? -
Make sure that the connecting user only have access to the bare minimum he requires. Such as only execute on sprocs and not access to change the sprocs, or direct access to the underlying tables.
--------------------------- Blogging about SQL, Technology and many other things
<sarcasm>HAHAHA!! Of COURSE all users have very as-needed access to the DB! Our software vendor's thought of that!</sarcasm> Of course, with any of my tables I try to keep things restricted to stored procs that certain users have access to. Thanks for pointing this out, though. I appreciate any response.
-
I would be concerned about storing user names and passwords as plain text.
Bob Ashfield Consultants Ltd
In the DB, the user credentials are stored in the syslogins table, so there's at least that bit of security. In most of my user side applications, I've been known to use a 1-1 and onto encryption to store credentials. I've been known to be lazy at times, however. Fortunately, no one at this company is familiar with memory editors much less CLR reflection. Thanks for the input.
-
I've written a series of ASP and winform applications for a database my one of my company's software vendors built. The vendor puts user login credentials in the sql connection strings in order to authenticate users. Since the same database is to be used, I have to use the same authentication method to keep users from being confused with additional usernames/passwords to remember. Other than an attacker appending
Integrated Security=Trueto the end of the connection string. What security issues should I be concerned about with this method?Keep this in mind for your web apps. It doesn't apply to desktop apps because pooling is rarely an issue there. Pool Fragmentation Due to Integrated Security Connections are pooled according to the connection string plus the user identity. Therefore, if you use Basic authentication or Windows Authentication on the Web site and an integrated security login, you get one pool per user. Although this improves the performance of subsequent database requests for a single user, that user cannot take advantage of connections made by other users. It also results in at least one connection per user to the database server. This is a side effect of a particular Web application architecture that developers must weigh against security and auditing requirements. http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx[^]
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon