By the drag-and-drop attack on password field encryption policy (database encryption) _ Database other

The industry's biggest surprise was the intrusion of RSA, which directly led to a chain of attacks by several industrial giants, and many security companies themselves using RSA's tokens. The Dutch electronics certification company DigiNotar, which is much weaker than RSA, has been declared bankrupt after being invaded.

In the first half of 2011, we stood on the sidelines and discussed these things. But then we encounter the CSDN, play and Tianya and so on data leakage, which is most sensitive, on the one hand is the user information, the other is of course the user password. Because of identity real name, password universal, such as the impact of a time of insecurity. Each site is also stuck in saliva.

But in fact, according to the inference, these invasions are some of the past, that is to say, the libraries have long been underground. At the same time outflow, may be a collective psychological effect.

This theft of database records, by some attackers known as "drag library", so there is a natural and homophonic jokingly "pants off." But the attackers are increasingly not kind, once only stole the people's trousers, and now to hang in the street, and posted a notice said, "Look, ya pants have patches on it."

If the drag library is difficult to avoid, it is necessary to use a reasonable encryption strategy to reduce the impact of the attacker to a smaller base.

The age of the plaintext password must be over, but is encryption secure?

Those bad encryption policies

PlainText passwords are admittedly unacceptable, but the wrong encryption strategy is also bad. Let's look at the following situations.

Simple use of standard hash

I think of a 90 's hacker joke, someone into a UNIX mainframe, caught a shadow document, but can not crack. So, he used his machine to do a false scene, deliberately left this shadow, finally see what others use the password to try, and finally use these passwords and infiltration of the original host. Unfortunately, at that time we all took this as a joke, at best reply to a "I took the you!", and did not reflect on the use of standard algorithms.

At present, the most widely used algorithm for password preservation is the standard MD5 HASH. But in fact, for a long time, we've all overlooked the idea that the hash design was not intended for encryption, but for verification. The system Designer is because the hash algorithm has the irreversible characteristic, therefore "borrows" uses it to save the password. But its irreversible premise assumes that the set of clear text is infinitely large. But the password is not the same, the length of the password is limited, and the characters it can use are also restricted. We can look at the total number of passwords as a de facto finite set (it's hard to imagine someone using 100 characters as a password).

For example, a person's password is "123456", then any use of standard MD5 encrypted Web site database, it is stored in such a MD5 value: e10adc3949ba59abbe56e057f20f883e

Because the cipher is the same, plus the hash algorithm is one-way, so the attackers earlier use of the method is "ciphertext ratio + high-frequency statistics" after the generation of ciphertext dictionary to attack, due to the vast majority of Web sites and system encryption implementation, are the same plaintext password generated the same ciphertext, therefore, Users with high frequency redaction may be users with high frequency plaintext passwords. On the one hand, the attacker can set up high frequency plaintext corresponding to the standard algorithm to query, on the other hand, for those non-standard algorithms, high-frequency statistical attack method is also very common.

But the table attack quickly overwhelm the high-frequency statistics, it is starting from 2000 has been the site scale of the plaintext password leakage event began. In the past, every password leak event in plaintext, the attacker will use the MD5, SHA1 and other common hash algorithm processing passwords and those who use the hash value to save the library to deal with.

With the low cost of resources, the popularity of GPU, and the growth of storage capacity, an unavoidable threat began to jump on the desktop, that is, these huge hash table is not only based on the leakage of passwords and common string dictionaries to make, many attackers through the long-term division of Labor collaboration, Through the exhaustive way to produce a certain number of digits below the cipher string and a variety of algorithms to encrypt the results of the result set, these results set from the hundred to dozens of TB, this is the legendary rainbow table.

The one-way advantage of hash has only theoretical significance, because the one-way of the hash is guaranteed by the algorithm design, using a finite set to express an infinite set, its inevitable is irreversible. But the attacker is from the look-up table to complete the restore from the hash to the password plaintext. Therefore, the one-way nature of its algorithm also loses its meaning.

Joint use Hash

Some people mistakenly think that the hash is not safe because of the strength of the hash algorithm, so the combination of MD5 or SHA1, in fact, this is worthless (just the memory of the storage resources). As mentioned above, the security of the hash is that a large number of passwords and their hash value of the corresponding relationship has been made into a rainbow table. As long as you use the hash algorithm, one of them in the rainbow table, naturally can be found.

Similarly, there is no point in using the "MD5 head +sha Tail", or by using other methods that mix two values. Because the attacker can easily observe the rule of this combination method, after dismantling, continue to be cracked according to Look-up table method.

Design your own algorithm

I've always thought that since we're not a cipher, but an engineer and a programmer, it's pretty silly to have a good thing on the shelf and develop the encryption algorithm yourself. I believe many programmers have come across a "new algorithm", and then found that in a the 1980s mathematical paper, the relevant algorithms have been proposed.

Moreover, in the open source era, many algorithms have not only been implemented and published, but also experienced a long-term use of scrutiny. These are the design, their own realization can not match.

On the independent design of the algorithm is not safe, there is a thing deep in my mind. Remember when I was working in the securities system, as just take over the purchase to the Business department, need to a Clipper compiled counter system to migrate, but the original developers have not been contacted, then we developed two roads, a master Li is responsible for the data, to see if it can restore clear text, And I was responsible for cracking algorithm, if the teacher Li that go, then I need to solve the algorithm, the number of 000000~999999 between all encryption, and then do a collision with ciphertext (at that time the securities are counter operation, no online stock market, passwords are counters with the number of keyboard input).

Since the original developer added a little bit of work, I have no prospect, there is a look at the teacher Li's engineer, has issued a voice of amazement, I ran past, saw teacher Li based on the construction of a number of encryption results of the cipher, in the paper to remit a very much like the Yang Hui's triangle things. In less than half an hour, Mr. Li has already done the decryption procedure together.

The purpose of the above story is to show that the design of your own algorithm no matter how self feel good, look at the U.S. official Selection algorithm PK process We all know that we can not compete with the wisdom of the global mathematicians.

So it's not a good idea to design your own implementation algorithm. This also includes, in the implementation will not have a similar input super long string can overflow a class of bugs.

Using symmetric algorithms alone

After the standard hash security burst, and see someone called AES, in fact, this is not a good suggestion. AES These symmetric algorithms, do not have one-way. Site attacks are complex, some are only the database dragged, and some of the entire environment fall. The latter AES key, once it is received, the password will be restored, which is worse than the check table.

Of course, we also see an AES as a hash of the idea, is to retain only part of the AES encryption results, only to verify that not restore. But in fact such AES does not have an advantage over hash. For example, even if an attacker does not get the key, it only drags the library, but the attacker himself registers a sufficient number of accounts before dragging the library and uses a large number of different short passwords. Then you get a set of short plaintext and corresponding ciphertext. At this point, the key is completely possible to be analyzed.

And the use of DES, AES, a class of algorithms, or the use of labeled hash, or the design of their own algorithms, if you do not solve different users of the same password ciphertext the same statistical defects, then the attacker even if not the key, can also be a number of high-frequency password for account registration, drag the library after the ciphertext comparison. You can lock in a large number of users who use common passwords.

Add "a grain of salt"

In fact, many colleagues have pointed out that the Hashiga Salt method (Hash+salt), is the solution to the problem, the so-called salt (salt) is actually very simple, that is, when generating a hash to give a disturbance, so that the hash value and the standard hash results are different, so you can resist the rainbow look-up table.

For example, the user's password is 123456, add a salt, that is, the random string "1cd73466fdc24040b5", the two together, calculated MD5, the result is 6c9055e7cc9b1bd9b48475aaab59358e. Through this operation, even if the user's weak password, but also by adding salt, so that the actual calculation of the hash is a long string, to some extent, the defense of the exhaustive attacks and rainbow table attacks.

But judging from the implementation of our audit, many people only add "a grain of salt." In other words, for the same site, different users use the same password, their ciphertext is still the same. This goes back to encountering high-frequency statistical attacks, pre-registration attacks, and so on.

Security Policy for passwords

In the eyes of traditional cryptography, only one encryption is ideal, that is, "once a secret", of course, in fact, it is impossible. But if we apply this kind of lexical, we can also say that the password security policy ideal realm, we can call one-way, one person one secret, one station is dense.

One-way: The value of the standard hash algorithm although in this scenario, has been pushed down, but its one-way thinking is still correct, the password as long as it can be restored, it means that the attacker can do this, thereby losing meaning, so the use of one-way algorithm is necessary.

One person a secret: the same site to set the same password of different users, encrypted generated ciphertext content is not the same. This will effectively respond to the results of collisions and statistical attacks. The method of using dictionary attack is basically not convergent.

One-stop: only to ensure that one person is not enough, but also to ensure the use of the same information, the same password to register users of different sites, the password encryption results at different sites are different. Since a large number of users use the same information, the same password to register different sites, if this can be done, the loss of the library information will be further reduced. An attacker would essentially give up trying to generate a ciphertext dictionary.

The realization of these is very simple, still hash+salt, the key is that each site to have a different salt, each user must have different salt.

However, if the attacker did not acquire only the library, but also obtained the relevant encryption parameters and keys, we would see that the attacker would still be able to invoke the algorithm through the relevant parameters and keys, generate a ciphertext for each user using common passwords, and then have a match. Of course we can see the strategy of "one salt per person", the cost of computing that the attacker needs has changed, and if only once needed to be generated, if 100 common passwords are used, then a 100-time encryption operation will be done for each user as long as the password does not collide. But it is also a threat that cannot be underestimated. Because there are too many users like to use those common passwords.

Therefore, set a password to disable the table, so that users avoid the use of common passwords, you can further let the cracker pay a greater price, which ultimately leads to the calculation of resources do not converge and give up, can also be a strategy to consider. But it also needs to be a reminder to web developers that this increases the risk that your users will forget their passwords.

In addition, whether the user has set the password to 123456 of the freedom, I think as long as not the national defense, aerospace, secret systems and security requirements of the enterprise environment, if only dive, scold, the site may remind users, but may not need to be made mandatory strategy.

Specific implementation

So much, how to implement a one-stop, one-person secret strategy, December 23, 2011, we think of its empty sermon algorithm principles and strategies, as well as provide some very direct sample programs and documents.

So colleagues have written a name antiy Password Mixer (Ann Day password mixer) Open source code, of course, there is no technical content, nor "own intellectual property of domestic algorithms", and some just to achieve a better popular open source algorithm package for the demonstration of use only, the current Python version , there are only 300 lines of code, which encapsulate RSA and hash+salt usage, and give specific examples of how to initialize, register, and authenticate.

We can find this thing here: http://code.google.com/p/password-mixer/

Of course, just as we regret that many application developers lack the same emphasis on security, we don't know about application development, so the code and documentation may look ugly to application developers. Although it may be despised, we have to open the door to prove that the security team is not conservative.

At the same time, we have to go closer to the application because we are also using these applications that are considered to violate some security principles, but they cannot be modified because they are not developers.

Over the past more than 10 years, China's Web applications have been thrown off the safe and fast running, developers rely on their own diligence and impact to lay the existing pattern, but also because of a quick run left something, such as security. Maybe it's time to pick up these discards.

China's security sector, because of conservatism, sensitivity and many of its own reasons, and application of the distance farther and farther, as we still fantasize about some of the perfect security picture, we found that we have not seen the application of the spine. Perhaps, in the application will be back to wait for us, is that we accelerate the forward, pick up the application of the security left behind, chasing the time to go up.