Authenticating Logins - Creating Strong Passwords
(Page 2 of 24 )
The best password encryption scheme in the world will not protect you against weak passwords; therefore, let’s look at the options for creating strong passwords for SQL Server authenticated logins.
Sp_password is the system stored procedure used by SQL Server 6.5, 7.0, and 2000 to set and change passwords. Looking at the text of this stored procedure can help you understand what options you have for passwords. In SQL Server 6.5, user passwords can be up to 30 characters long, and there is no restriction on the characters used in the password. SQL Server 7.0 and 2000 both allow passwords to have as many as 128 characters, and they permit all characters on a standard keyboard. The maximum number of characters in a password is important information, but the real key to strong passwords is the kinds of characters used.
All three versions of SQL Server considered in this book interpret passwords differently for case-sensitive and case-insensitive sort orders. If the server has acase-sensitive sort order, case is significant in the password. If, however, the server uses a case-insensitive sort order, passwords are converted to uppercase before they are stored in the syslogins (SQL Server 6.5) or sysxlogins table (SQL Server 7.0 and 2000) and before they are compared to the entries in those tables when a user logs in. For example, Password0 would be stored and compared as PASSWORD0 on a server with case-insensitive sort order. You have, therefore, slightly weaker passwords when you use case-insensitive sort orders.
To get an idea of how strong a password might be, let’s look at how many combinations a brute force attack would have to try in order to find a user’s password.
Let’s first start with a password consisting of strictly uppercase letters A through Z. Each character in the password will have 26 possible options, and no character is dependent on any other character. That means there are 26 to the power of n possible combinations, in which n is the total number of characters in the password. A six-character password seems to be the norm whenever I go to client sites, so there are 266, or 308,915,776 possible six-character passwords using just uppercase letters. In contrast, if passwords contained both upper- and lowercase letters, there would be 52n possible combinations, or 19,770,609,664 possible six-character passwords.
If you assume an attacker could check 1,000 passwords per second (and that’s a big assumption), it would take 85.81 hours to try every combination of uppercase letters in a six-character password and 5,491.84 hours to try every combination of a six-character password that just used upper- and lowercase letters. As you can see, case-insensitive sort orders have a tremendous impact on how long it takes an attacker to break a user’s password.
While I was writing this book, NGSSoftware published a paper (http://www.nextgenss.com/papers/cracking-sql-passwords.pdf) on its web site detailing its discovery of how pwdencrypt() works. It turns out that the data stored in syslogins and sysxlogins is actually a combination of two representations of the passwords, one with the case intact and one with the letters converted to uppercase. That means that case insensitivity is irrelevant if an attacker can get the hashed representations of password from syslogins or sysxlogins. The sort order will only matter if an attacker attempts to log into SQL Server, because SQL Server controls how it interprets the data in the system table. An attacker with direct access to the system tables will be able to narrow his attack to just uppercase letters.
NOTE If you want to see some code, NGSSoftware includes a sample program in its paper. Additionally, it is not clear if the behavior described in the paper occurs in SQL Server 2000.
The question then becomes, how do you make it harder to determine passwords using a brute force attack? The answer is to make the password longer and to include nonalphabetic characters.
If you include at least one number (0 through 9) in your password, an attacker must assume that the number may occur anywhere in the password. That results in 36n or 62n combinations, depending on whether lowercase letters are available. In either case, the inclusion of numbers increases the number of combinations significantly. For six-character passwords, there are 2,176,782,336 possible passwords consisting of all uppercase letters plus numbers and 56,800,235,584 possible passwords consisting of upper-and lowercase letters and numbers. Adding the ten special characters that are on the number keys on standard keyboards—!, @, #, $, %, ^, &, *, (, and )—changes the number of combinations to 46n or 72n, depending on whether the password has lowercase letters.
Lengthening the password will have the greatest effect on its strength. For example, 366 is 2,176,782,336, 367 is 78,364,164,096, and 368 is 2,821,109,907,456. Just changing from six to eight characters changes the time to crack a password from 604.66 hours to 783,641.64 hours, assuming 1,000 password attempts per second. Requiring at least one special character in addition to uppercase letters and numbers increases an eight-character password to 468, or 20,047,612,231,936, possible combinations. That will take 5,568,781,17 hours (635.7 years) to try every combination. This is the prime reason not to have short passwords for administrator and database owner accounts. Make it a rule that all your passwords are at least eight characters long.
A brute force attack is not the only type of attack that could compromise your users’ passwords. A dictionary attack uses a program to try combinations of words from a list of words commonly found in passwords. The benefit of this attack is that it treats words as discrete units rather than trying all the combinations of letters, numbers, and special characters. For example, “Password0” has eight characters, but a dictionary attack considers it one word with one number, which would require 11 tries to guess, for example, Password, Password0, Password1, Password2, Password3, and so on. If the attacker can assume all passwords are stored in uppercase, then he can configure the program to try all the words in uppercase to find the words in the password and then try all combinations of upper- and lowercase to find the exact letters used in the password.
In general, dictionary attacks take a very small fraction of the time required for a brute force attack if the list of words is well chosen. The trick to defeating this kind of attack is not to use common words (for example, “password,” “server,” “windows,” “SQL,” and so on), common names (for example, “John,” “Mary,” and so on), common place names (for example, “New York,” “headquarters,” and so on), or dates (for example, birthdays). In addition, break up the words with numbers or special characters in multiple, odd places such as in the middle of the word (for example “P@s$w0rd”). Doing so fragments the words to the point that the dictionary either does not work or must be increased in size to compensate for common fragments.
CAUTION Attackers are catching on to the common habit of replacing the letter A with the @ symbol and the letter O with the number 0. Such typical replacements will not materially increase the difficulty of a dictionary attack.
The best way to defeat both the brute force and dictionary attacks is to use randomly generated sequences of letters, numbers, and special characters. As a general rule of thumb, if you can recognize words or sequences of numbers, the password is not random enough. The recommended practice for securing the sa account in SQL Server 7.0 and 2000 is to give it a very long password—at least 20 characters if not longer—composed of random strings of upper- and lowercase letters, at least five numbers, and at least five different special characters; write it down on a piece of paper; and then place the paper in a safe or safety deposit box for safekeeping in case of emergencies.
For users, my recommendation is that you specify eight characters as the minimum size and that you provide a list of words that should not be in the password. The argument for eight characters is that anything smaller is too easy to guess with a brute force attack, and any password longer than eight characters will just enhance security. Randomly generated passwords are probably not feasible because users will tend to forget them. Words that are relatively uncommon and that are broken up with numbers or special characters in unusual places will provide good security without being difficult to remember. There is always atradeoff between having highly secure passwords and users’ ability to remember them, and minimum eight-character passwords are a good compromise.
NOTE A list of simple programs that you can use to test your password strength is available from http://www.sqlsecurity.com.
Passwords in Enterprise Manager Passwords are not just stored in syslogins and sysxlogins. Enterprise Manager stores the server registration information, including the account and password, in the registry in the following key: HKEY_CURRENT_USER\Software\Microsoft\ MSSqlServer\SQLEW\Registered servers\SQL6.5\ server_name.
server_name is the name you use to identify the server. Even though that key stores its data in binary format, the Windows 95 registry editor, regedit.exe, which ships with Windows NT and 2000, will translate the binary into text for you. The only way to keep passwords from being stored in the registry in clear text is to use trusted connections (Windows logins) instead of Standard Security logins.
The reason for being concerned about the passwords in the registry is that several viruses, such as KLEZ, will upload the user’s section of the registry to a hacker’s computer for later analysis. If a system with Enterprise Manager installed is infected with one of these viruses, you have to assume that the SQL Server account is compromised and change at least the passwords for all the accounts and servers that were registered in Enterprise Manager. In addition, if Enterprise Manager is installed on Windows 9 x, the passwords will be stored in easily accessible unprotected files, which anyone with physical access to the computer can read. An attacker will not have to use a virus to steal the information.
NOTE Enterprise Manager should not be installed on Windows 9x if your servers use Standard Security.
Given the problem of the way Enterprise Manager stores its passwords, it is considered best practice to use only trusted connections. That way, the account password will be stored in the more secure database maintained by Windows NT/2000.
 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. |
Next: The Effects of Windows on Authentication >>
More MS SQL Server Articles
More By Apress Publishing
/ 18 
