Authenticating Logins - Summary
(Page 24 of 24 )
In summary, remember that in general, authentication is a matter of trust. Different authentication mechanisms have different levels of perceived trust. Supplying an account and password proves only that the user knows two pieces of information. The account is usually public information, and the password is often something someone can guess or derive through brute force testing of specific patterns of characters. There are other ways to identify users, but they all have some flaw that makes them imperfect. For example, there is an old story of a bank in Australia that thought thumbprint scanners were the perfect way to identify users at automated teller machines until kidnappers started forcing victims to use their thumbs to log in and withdraw money. Some of the more ruthless robbers made the rather gruesome discovery that they did not need their victims to be alive to make withdrawals. This is an extreme example, but it does show that attackers will try to circumvent even really good authentication mechanisms if the reward is great enough.
The key is to make the task so difficult that an attacker will prefer to look elsewhere for another target. The first step is to ensure all accounts use long, complex passwords that are difficult to guess. All versions of SQL Server support a password length and a list of legal characters that can potentially make brute force or dictionary-based password attacks completely infeasible. It does not matter whether you use Windows authenticated logins or SQL Server authenticated logins. Windows’ list of legal characters for passwords is different from SQL Server’s, but it is still possible to have passwords on Windows accounts that are just as hard to break. As a rule of thumb, the minimum requirement should be eight-character passwords with both upper- and lowercase letters, at least one number, and at least one special character. Every character beyond eight increases the security of the password by several powers of ten, so use more than eight characters if you can. For example, all my production servers have aminimum of fourteen characters and after a while, it takes a fraction of a second longer to type the six extra characters. The added protection is worth it.
The next most important task is to secure the password exchange between the client and server. If you use SQL Server authenticated logins, use IPSec, SSL, or the Multiprotocol network library encryption to encrypt the password. The security offered by strong passwords can still be foiled if an attacker can read them in plain text in the network packets sent during the login process. If you use Windows authenticated logins, seriously consider upgrading from Windows NT to Windows 2000 or XP for both the database servers and the clients. The NTLM authentication protocol has been broken, so you need to move to NTLM version 2 to protect your passwords. If moving to Windows 2000 or XP is not an option, IPSec can be a good way to protect the authentication network traffic.
Of the three main network libraries—Named Pipes, Multiprotocol, and TCP/IP—Named Pipes offers the least security for authentication, at least for SQL Server 7.0 and 2000. That makes it a poor choice for insecure environments. For SQL Server 7.0 and 2000, the TCP/IP network library combined with SSL is a good alternative to the Multiprotocol network library’s encryption. The main drawback is that each server will need its own digital certificate for SSL, whereas the Multiprotocol network library does not need anything else. If obtaining adigital certificate is not a significant impediment, the TCP/IP network library with SSL is a superior choice for SQL Server 7.0 because the encryption algorithm is stronger. For SQL Server 2000, the Super Socket network library is the best choice for speed and encryption.
SQL Server 6.5 has several limitations in terms of securing the authentication process. SSL is not an option at all, and its TCP/IP network library does not support Windows authenticated logins. For environments that use Windows NT, the weakness in the NTLM authentication protocol makes Windows authenticated logins a little more risky than SQL Server authenticated logins because an attacker that compromises a Windows account can use it to log into SQL Server. At least with SQL Server authenticated logins, there is an additional step in the authentication process that can be encrypted using the Multiprotocol network library. The fact that SQL Server 6.5 only supports three levels of access for Windows authenticated logins—user, guest, and sa—means that administrators have a limited range of choices for granting server access.
The general rule is that if you protect the authentication process, unauthorized users will not have access to the data on the server. Protecting the sa account and the accounts that are members of the sysadmin role (in SQL Server 7.0 and 2000) is critically important because those accounts have unlimited privileges within SQL Server. Just remember that the authentication process involves both Windows and SQL Server; therefore, you must be alert for security flaws that affect either one of them. Keeping your patches and service packs up to date is vital to keeping your login authentication safe and secure.
 This is from SQL Server Security Distilled, second edition, by Morris Lewis (Apress, ISBN 1590592190). Check it out at your favorite bookstore today. Buy this book now. |
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
/ 17 
