Six risk judgments for SQL password management

When managing the internal accounts and passwords of SQL Server, it's easy to assume that all of this is fairly secure. But that is not the case. Here, we list some very dangerous judgments for SQL Server passwords.

When managing the internal accounts and passwords of SQL Server, it's easy to assume that all of this is fairly secure. After all, your SQL Server system is protected in the firewall, and Windows authentication is protected, and all users need a password to enter. It sounds very safe, especially when you think everyone is doing it. But actually, it's not as safe as we think.

Here, we list some very dangerous judgments for SQL Server passwords:

No plan for password testing

When testing, it would be a big mistake to start trying to crack the password directly. Whether you are testing locally or over the Internet, I strongly recommend that you get permission and suggest that an account be locked out of the rollback scheme. The last thing you need to do is to make sure that when the account is locked, the database user is unable to operate, and the application connected to it will not function properly.

Through the Internet, passwords are still safe.

For a hybrid implementation of SQL Server, you can easily get the password from the Internet through some analysis software (such as OmniPeek, Ethereal) immediately. At the same time, Cain and Abel can be used to crawl passwords based on TDs. You might think that you can avoid this problem with an intranet switch? However, the Cain ARP Poison routing function can be easily cracked. In about a minute, this free software can break through your switch and see the internal data exchange of the local network, which helps other software to crawl the passwords easier.

In fact, the problem has not ended. There are some misconceptions that using Windows Authentication in SQL Server is safe. However, that is not the case. The software can also quickly capture windows, Web, e-mail, and other related passwords from the Internet, gaining access to SQL Server.

By using the password policy, we can not test the password

No matter how tough your password policy is, there are always ways to get around it. For example, there is now a server that is not configured, a host outside windows, an unknown SQL Server, or some special tools that can crack the strongest passwords. These things can take advantage of your password weaknesses and your code policy becomes ineffective.

Also, it is equally important that some test results may say that your database is safe because your password is already very strong, but you must not be credulous. Be sure to test yourself and verify that the password flaw is still there. Although you may feel that everything is fine, you may have dropped something.

Since the SQL Server password is not available, if I know that he is strong and safe, why do I have to crack him?

In fact, the password for SQL Server can be obtained again. In SQL Server 7 and SQL Server 2000, you can use a tool like Cain and Abel or fee-based Ngssqlcrack to get a hash table and then attack it with brute force. These tools allow you to reverse engineer the SQL Server Password Sha hash table. Although the results are not guaranteed, it is indeed a weakness of SQL Server.

I used MBSA to check for a flaw in the SQL Server password and did not find any serious problems

Microsoft Baseline Security Analyzer is a tool to root out the vulnerabilities of SQL Server, but he is not perfect, especially in terms of password cracking. For deep SQL Server and Windows password cracking, we need to use third-party software such as free Sqlat and Sqlninja (which can be found in sqlping 3) and Windows password cracking tools, such as ElcomSoft ' s proactive Password Auditor and Ophcrack.

In addition, using Windows Authentication in SQL Server does not mean that your password is safe. Some people just understand how to crack windows passwords and take some time to break your passwords and control the entire network. In particular, it will be easier if they use <>ophcrack ' s LiveCD to attack a physically insecure Windows host, such as a laptop or an accessible server.

You just have to worry about you. Primary database server

It's easy to focus on our own SQL Server system, ignoring the possible MSDE, SQL Serve Express, and other possible SQL Server programs on the network. These systems may be using insecure default settings, or even no passwords at all. By using tools such as Sqlping 3 to attack these systems on the database server, you will easily be cracked.

It's like everything else, you're always overwhelmed by the details. If you can discard these dangerous judgments about SQL Server passwords, you will certainly improve your SQL Server security.