When not to use the sa password in SQL Server applications

Where are the places that I should not use the sa login:

• Embedded in management tools or application development tools
• Hard coded in application connection strings
• DTS or SSIS connection objects
• UDL files
• Batch files
• SQLCMD, OSQL or ISQL T-SQL scripts
• In casual conversation
• On sticky notes on your desk or monitor

Alternatives to using the sa login

Depending on how the sa login and password is being used in your environment, dictates what steps can be taken to limit the sa usage. Once you have that information, then you can make a decision on how to migrate from using the sa credentials to other alternatives outlined below.

• Windows authentication to SQL Server with a Windows domain account
• Setup application logins that are assigned the needed rights in order for the application to operate properly
• Convert the code to execute in Jobs without having to authenticate externally to SQL Server
• Use the trusted connection switches for the connection strings or applications

Next Steps

• Assess the usage of the sa login in your environment to determine if the usage is acceptable or needs to be corrected to improve this portion of SQL Server security.
• Once you understand where the sa login is used, determine if the sa login is truly needed. See what alternatives can be put into place to limit the sa login usage and better secure the sa credentials.
• Be sure to properly test your applications to understand the needed rights and validate that the applications work properly.
• Secure the sa password to prevent this login from being used in future applications just because the password is known.
• Work with your team to understand the security needs as new applications are built.