Does an known account name like sa, pose a security threat to database? When using windows authentication on SQL Server does it impose the same password policy(if it was set to say account lockout after 5 times)?
SQL Server Security Threats – Risks of SA and Known Account Names
Securitysql server
Related Question
- Sql-server – How does “Be made using the login’s current security context” pass the users password to remote server
- Sql-server – If the users need INSERT/UPDATE/DELETE permissions, is Windows auth still more secure than SQL Server auth
- Sql-server – Are passwordless logins like ##MS_SQLResourceSigningCertificate## , ##MS_AgentSigningCertificate## a vulnerability
- SQL Server Service Account – Why ‘Impersonate a Client After Authentication’ Right?
- SQL Server 2012 Security – How to Know Remaining Expiration of SQL Login Password Date
- SQL Server – Mixed Mode Authentication Not Being Set
Best Answer
A "god" user account with a known name is generally considered a worse idea than a god user with a less well known name. It makes brute force attacks that bit easier as the attacker only has to guess the password and not the username and the password.
Also having a god user anyway can be dangerous. You are generally better off having specific users with specific rights for what they need to do. This sort of privilege based security is easier to implement from scratch than it is to retrofit into your environment later.
Disabling sa and giving specific users specific admin rights as needed in SQL server is essentially the same recommendation as disabling
rootand handing out admin rights as needed viasudounder Linux and similar. You can always re-enablesaonce directly connected to the machine with adequate privileges should anything go wrong and you end up dropping all the rights your users need to operate (and fix the issue) just the same as you can engineer root access to a Linux box if you have physical access to the box - so disabling the account is no magic bullet (but once an attacker has physical access to your machine, or full Administrative access via RDC or SSH, all bets are off anyway).When using Windows Integrated Authentication SQL server has no control over account lockouts and such - it just maps a Windows user to an SQL user and asks the OS to vouch for the fact that the user has provided appropriate credentials. For interactive human users this means any lockout would occur as the user attempted to authenticate with Windows, not as they logged in to SQL Server.