Six dangerous judgments on Microsoft SQL server password management

Six dangerous judgments on Microsoft SQL server password management

When managing SQL Server's internal accounts and passwords, it is easy to think that all this is quite safe. But not actually. Here, we list some very dangerous SQL Server passwords.

When managing SQL Server's internal accounts and passwords, it is easy to think that all this is quite safe. After all, your SQL server system is protected in the firewall and protected by Windows authentication. All users need a password to access it. This sounds safe, especially when you think everyone is doing this. Actually, it is not as secure as we think.

Here we list some very dangerous SQL Server passwords:

No plan for password Testing

It would be a big mistake to try to crack the password directly during the test. Whether you are testing locally or over the Internet, I strongly recommend that you obtain permissions and recommend a rollback solution after your account is locked. The last thing you need to do is to ensure that database users cannot perform operations when the account is locked, and the applications connected to the database cannot run normally.

The password is still secure over the Internet

For SQL Server implemented in hybrid mode, you can easily get its password from the Internet through some analysis software (such as omnipeek and ethereal. At the same time, Cain and Abel can be used to capture the TDS-based password. Do you think you can avoid this problem through an intranet switch? However, the ARP poisoning routing function of Cain can easily crack it. In about one minute, this free software can break your switch and view the internal data exchange in the local network to help other software easily capture passwords.

In fact, the problem has not ended. Some Misunderstandings hold that it is safe to use Windows Authentication in SQL Server. However, this is not the case. The above software can also quickly capture windows, web, email and other related passwords from the Internet, so as to obtain the access permissions of SQL Server.

By using the password policy, we do not need to test the password.

No matter how strict your password policy is, there will always be ways to bypass it. For example, an unconfigured server, a host outside windows, an unknown SQL server, or some special tools can crack the strongest passwords. These things can exploit the weakness of your password and make your code policy ineffective.

In addition, it is equally important that some test results may say that your database is safe because your password is strong, but you must never trust it. Be sure to test and verify whether the password defect is still there. Although you may think everything is good, you may actually get rid of something.

Since the SQL server password cannot be retained, if I know that it is strong and safe, why should I crack it?

In fact, the SQL server password can be re-obtained. In SQL Server 7 and SQL Server 2000, you can use tools like Cain and Abel or charged ngssqlcrack to obtain the password hash table, and then use brute force attacks to crack it. These tools allow you to reverse engineer the SQL server password Sha hash table. Although the results of the cracking cannot be guaranteed, it is indeed a weakness of SQL Server.

I have used mbsa to check SQL server password defects and have not found any serious problems.

Microsoft baseline security analyzer is a tool used to eradicate SQL Server Vulnerabilities, but it is not perfect, especially in 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, for example, elcomsoft's proactive password auditor and ophcrack.

In addition, using Windows Authentication in SQL Server does not mean that your password is secure. Some people only need to know how to crack the Windows Password and take some time to crack your password and control the entire network. In particular, if they use <> ophcrack's livecd to attack a physically insecure Windows host, such as a laptop or an accessible server, it will become easier.

You only need to worry about your primary database server

We can easily focus on our own SQL Server System, ignoring the possible MSDE, SQL Serve Express, and other possible SQL server programs in the network. These systems may be using insecure default settings, or even have no password at all. By using tools such as sqlping 3 to attack these systems on the database server, you will be easily cracked.

Like other things, you are always overwhelmed by some details. If you can discard these dangerous judgments on the SQL server password, you will certainly improve the security of your SQL Server.