On how to prevent the theft of database

Intermediary transaction http://www.aliyun.com/zixun/aggregation/6858.html ">seo diagnose Taobao guest cloud host technology Hall

To prevent someone with ulterior motives from accessing the database from outside, stealing the names, passwords, credit card numbers, and other important information in the database, when we create a database-driven solution, the first design decision we need to consider is how to encrypt the stored data to keep it safe from being spying by others.

What kind of support in SQL Server can be used to encrypt objects and data? Discuss from the outset what SQL Server lacks is sensible, or what you should not do with the encryption part of SQL Server.

First, SQL Server has two built-in cryptographic functions-that is, Pwdencrypt () and Pwdcompare (). At the same time, there are two functions that SQL Server does not formally record to manage password hashes: Pwdencrypt () stores the password after hashing it; Pwdcompare () compares the supplied string to the hash string. Unfortunately, this hash function is not very secure, and it can be cracked by the dictionary attack algorithm (similar to a command-line application!).

These functions are constantly being modified as the version of SQL Server progresses, which is another reason not to use them. The hash of the password by earlier versions of SQL Server. Cannot be decrypted in later versions, so if you rely on a function in one version, all your encrypted data will be useless when you upgrade, unless you can decrypt it first-which violates the original purpose of encryption.

Second, you may try to create a homemade encryption solution for your database, but there are three reasons why you should not:

Unless you're an encryption expert, a random encryption system will only provide very low-level protection. What's new is that one-way cipher hashes or "rotx" forms of encryption can be easily defeated without any trouble.

If encryption is cracked because of your lack of ability, your data is screwed. You need to have all the things unencrypted, right? (Even if you encrypt, is there a security breach?)

When it comes to providing professional-level, industrial-intensity encryption solutions, you're not worth the time to do it yourself. Use your time to build a good, solid database instead of reinventing the wheel.

So what's the good way to encrypt data?

For beginners, Microsoft offers a cryptographic solution of its own generation, CryptoAPI. For lightweight encryption, military-level security is beyond consideration, and it has a relatively easy advantage: Administrators can install an ActiveX control called CAPICOM, which provides CryptoAPI functionality in T-SQL stored procedures. CAPICOM supports various types of bidirectional encryption and one-way hashing algorithms, so administrators can pick the parts of the problem that best fit the application.

If you are not interested in using Microsoft's solution, there are some good third-party solutions to use. A software LLC named Activecrypt has created Xp_crypt, a plug-in for SQL Server that can complete encryption in views, programs, and triggers by extending stored procedures and user-defined functions (in SQL Server 2000). You can download a free version of the app that supports wireless md5,des, as well as SHA1 hashes; Other cryptographic models are performed at the bit depth. (The full version is infinite.) In your own code, you can use Xp_crypt, as with ActiveX control (in a limited free version). For an ASP programmer, a component named AspEncrypt provides a simple way to integrate advanced encryption into your code.

How about encrypting the database file itself or providing security on the transport layer? For the former, you can continue to use the Encrypting File System in the Windows system. However, you must save the backup of the encryption key, which may be lost when the problem occurs. For the latter, IPSec and SQL Server's own SSL encryption, the primary effort of SQL Server and Windows, should be to avoid storing sensitive data in clear text, because extracting unencrypted data from a database is also the most vulnerable vulnerability to attack.

This article is published by http://idc.qdsset.com