SQL Server login ids may not be the most secure thing in the world but they are likely to be around for quite a while and one of the more common uses of them is as an application id. An application uses a SQL Server id to connect to SQL and then controls its own security internally. The problem comes in when developers decide “Hey, I have the password to the app id, it has way more permissions in the database than I do. I’ll just use it.” So why is that a problem? Well, here are a few examples:

• Clear text passwords. There are ways to send an encrypted password to SQL but if the developer is doing something like this they probably aren’t using them.
• Lack of clear accountability. There is no way to know for certain who is using the id. It could be anyone.
• Permissions are controlled for a reason. This developer is using permissions not properly granted to them, possibly causing a data breach through a lack of understanding of why these procedures are in place. Heck, they could be the data breach themselves. It wouldn’t be the first time an employee has stolen data.
• Avoiding being accused of stealing data. Guess what, if you have access to this account and data is stolen using it, you are a suspect. No one want’s that unless it’s unavoidable right?
• Not to mention that SQL Authentication is just less secure to begin with.

Anyone of these would cause you to fail a security audit. All of them together? Not good.

So how do we fix it?

Continue reading on SQLStudies.com.

Continue reading on SQLStudies.com.