When giving advice to, or doing an audit for, a SQL Server shop, I do a whole range of checks, including security checks. There is one that I do to check the password strength of the SQL Server logins, based on this page on MSDN, PWDCOMPARE (Transact-SQL), except that I join to a huge list of all the common passwords that I can find that are known to the hacker community. I expire the password of any account that fails the check. It takes a minute or so, but it is very effective. I hope you have a similar system in place, even if you are already enforcing a windows password policy on SQL Server logins.

Why? Several times in the past, I've found SQL Server Logins with ridiculously weak passwords that have been assigned the SysAdmin role. In one case, it was the same password for that login on all machines in the domain. The test I run tells you what the password is, of course, but there are many ways to do that without leaving any forensic clues.

As a DBA and custodian of data, I'm motivated to be a saint rather than a sinner, of course, but I must admit that I enjoy checking that I indeed have access to all the other SQL Server instances in the domain at SysAdmin level. These privileges would give you control over every SQL Server instance, and if XP_CmdShell was enabled, then you could control the machine. Any determined and well-informed person would be able to make this permanent control. Your data is in the public domain and as a DBA you need to be very familiar with what it is possible for the sinner to do with a handy password, and how easily that sinner can get hold of it.

If you have a SQL Server that is exposed to the internet, even on just a couple of ports, you will probably find, as I have, that your intrusion-detection software will pick up countless probing attempts to log in via id/password. If you have a password that is weak, then the instance is at high risk. If the same password is used on several machines, then an intruder can leapfrog to the other machines, just as can be done from a SQL Injection attack.

If you really don't need SQL Server passwords, as when your instances are within the domain, then don't use them. Use Windows security instead.

Phil Factor