Anti-drag library ――web front-end slow encryption

0x00 Preface

The World martial arts, only fast not broken. But password encryption is different. The faster the algorithm, the more likely it is to break.

0x01 Brute Force hack

Password cracking, is to restore the encrypted password into plaintext password. There seems to be a lot of ways, but eventually we have to go one way: violence is poor. You may say that you can also look up the table, the instant results. Although the checklist does not need to be exhaustive, the manufacturing process of the table is still needed. Tabular just put the poor forward.

Password encryption is used for one-way hash calculations. Since one-way, that is irreversible, it can only be poor lift. The principle of poor lifting is very simple. As long as the ciphertext is what algorithm encryption, we also use the same algorithm, the common phrases run again. If the result is the same as the cipher, guess it.

How fast is the speed of the poor lifting? This is related to cryptographic algorithms. How fast encryption once, guess once also so fast. For example, MD5 encryption is very fast. Encryption takes 1 microseconds at a time, which is a simple phrase to guess, and only 1 microseconds (assuming the same machine performance, the phrase length is similar). Attackers can guess 1 million in a second, and this is only a single-threaded speed.

Therefore, the faster the encryption algorithm, the easier it is to crack.

(Picture from: netdna-ssl.com)

0x02 Slow Encryption

If you can increase the encryption time, obviously also can increase the crack time. If the encryption is increased to 10 milliseconds at a time, the attacker can only guess 100 per second, and the crack speed is 10,000 times times slower. How can I make encryption slow? The simplest is to encrypt the result after encryption, repeat multiple times.

For example, the original 1-microsecond encryption, repeated 10,000 times, is 10,000 times times slower:

For i = 0 ~ 10000 x = MD5 (x) end

It takes a little more time to encrypt, and it can be exchanged for attackers who have a lot of time to crack.

In fact, such a "slow encryption" algorithm already exists, such as Bcrypt, PBKDF2 and so on. They all have a factor of difficulty factor, can control the encryption time, think how slow is slow.

The slower the encryption, the longer the crack time.

0X03 Slow Encryption Application

The most need for slow encryption, is the site database password.

In recent years, the website has been frequently heard by the "Drag Library" news. User data are stored in clear text, leaked and can not be retrieved. Password only, you can also fight against the attackers. However, many websites use fast encryption algorithms, so it is easy to crack a bunch of weak password accounts. Of course, sometimes you just want to crack a particular person's account. As long as it is not a particularly complicated vocabulary, running for a few days, it is likely to break out.

But the Web site used slow encryption, the results may be different. If the encryption time is increased by 100 times times, the crack time will take months and become difficult to accept. Even if the data is compromised, the last privacy of the "password" can be guaranteed.

0x04 Slow Encryption disadvantage

However, slow encryption has obvious drawbacks: it consumes a lot of computing resources. With a slow-encrypted web site, the server CPU may not be enough if multiple users are at the same time. If a malicious user is encountered, a large number of logon requests are initiated, and even resources are exhausted. Performance and security are always difficult to get both. Therefore, it is generally not used too high strength.

Some large web sites, even for this purpose, are clustered to handle a large number of cryptographic computations. But it takes a lot of cost.

Is there any way that we can use computationally powerful, free computing resources?

0X05 Front-end encryption

In the past, the speed of the PC and the server, there is still a big gap. But now, as hardware grows into a bottleneck, the gap is narrowing. On single-line task processing, even on a par. Client has a powerful calculation, can you share some of the server's work? In particular, such as "Slow encryption," the algorithm open source, but computationally heavy tasks, why not to the client to complete?

In the past, a clear-text password was submitted, and now commits a "slow encryption result" of the plaintext password. Whether it's registering or logging in. And the service side, without any changes. The "Slow encryption result" will be received as the original plaintext password. How it was saved and how it was saved. In this way, even if the library is dragged, the attacker will only crack the "slow encryption results", but also need to crack again, in order to restore the "plaintext password."

In fact, the "slow encryption results" This middle value, is impossible to crack out! Because it is a hash value--an irregular random string, such as a 32-bit hexadecimal string, and the dictionary is a meaningful phrase, it is almost impossible to run to it! Unless the bytes are individually exhaustive. But there are 16^32 kinds of combinations, it is an astronomical. Therefore, "slow encryption results" can not be leaked in the database of ciphertext "inverse push" out.

Perhaps you are thinking that even if you do not know the plaintext password, you can log in directly with "slow encryption results". In fact, when the backend storage is encrypted again, it is not possible to reverse this hash value.

Of course, it cannot be reversed, but it can be pushed forward. The phrase in the dictionary is executed once in turn using the algorithm of the front and back end:

Back_fast_hash (Front_slow_hash (password))

Then compare the ciphertext to determine if there is a guess. This can be used to run a dictionary to crack. But with Front_slow_hash this obstacle, the crack speed is greatly reduced.

0x06 vs. Pre-calculation

However, everything on the front end is public. So Front_slow_hash's algorithm is known to everyone. An attacker could use this algorithm to calculate the "slow encryption results" of a commonly used phrase in advance to create a "new dictionary". After dragging the library, you can run the new dictionary directly.

Against this approach, you have to use classical means: add salt. The simplest, the user name as the Salt value:

Front_slow_hash (password + username)

In this way, even if the same password, for different users, "Slow encryption results" is not the same. Perhaps you would say that this salt value is unreasonable, because the user name is public. An attacker could create a dictionary for an important person's account alone.

So, is it possible to provide a hidden salt value? The answer is: No.

Because this is on the front end. If the user is not logged in, whose salt value is returned? You can get the salt value of the account before you log in, this is not public. Therefore, the salt value of the front-end encryption can not be hidden, only public. Of course, even if exposed, providing a salt value parameter alone is better than a username. Because the user name will never change, and the independent salt value can be changed periodically.

The salt value can be generated by the front end. For example, when registering:

# front-end salt value generation
Salt = rand ()
Password = front_slow_hash (password + salt)

# Submit with salt value
Submit (..., password, salt)

The back end stores the user's salt value as well. When you log in, you can start querying the user's corresponding salt values by completing the user name:

Of course, it is important to note that this interface can test whether the user exists, so there must be some control.

The replacement of the salt value is also very simple and can even be done automatically:

The front end encrypts the current password, opens a new thread at the same time, calculates the new salt value and the new password. When submitting, bring them all on. If the current password validation succeeds, the old is overwritten with the new password and new salt values. This changes the salt value, or only the calculation force of the front end.

This is all automatic, equivalent to the user no sense of the situation, regularly help him to change the password!

The cipher has changed, and the dictionary produced for the "specific salt value" has been invalidated. The attacker had to make a re-production.

0X07 Strength Strategy

The problem with cryptography is over, and the implementation is discussed below.

In reality, the user's calculation force is unbalanced. Some people use the divine configuration, but also some antique machines. In this way, the encryption strength is difficult to set. If the antique machine user logs on the card for a few 10 seconds, that must not be possible. For this scenario, only the following options are available:

Strength fixed

Variable strength

1. Fixed strength

According to the public's configuration, a moderate intensity is established, which is acceptable to the vast majority of users. But if the time has not been completed, the calculation of the half of the Hash and the number of steps to submit, the rest of the server to complete.

[Front end] Complete 70%----> [backend] calculation 30%

However, this requires a "serializable" algorithm to restore progress on the server side. This scenario is not available if there is a large amount of temporary memory in the calculation. Compared to the past 100% backend slow encryption, this small number of users "mixed" way, can save a lot of server resources.

For users requesting assistance, there must also be certain restrictions to prevent malicious overdraft of server resources.

2. Variable Strength

If the back end does not provide any assistance, it can only be based on their own criteria for trade-offs. Poor configuration of users, less encryption a little. When the user registers, the encryption algorithm does not limit the number of steps to run, to see how many steps can be counted in a given time:

# [Registration Phase] evaluation of the force (thread aborted after 1 seconds) while x = hash (x) step = step + 1 End

This number of steps, which is the encryption strength, will be saved to his account information. As with salt, the intensity is also public. Because front-end encryption needs to know this strength value at logon.

# [Login phase] First get step for i = 0 ~ Step x = hash (x) end

This scheme allows high-profile users to enjoy higher security, low-profile users, and no impact on basic usage. (with a good computer can also improve security, there is a sense of superiority bar ~)

But this has an important premise: registration and login must be on a device with similar performance. If it is registered on the high-profile computer account, one day to the antique machine login, it is tragic, probably half a day can not be counted out ...

3. Dynamic adjustment Scheme

In this case, there is a universal reality. such as the PC-side registered account, on the mobile side login, the force may not be enough. If there is no back-end assistance, it can only wait. If you often log on to low-end devices, do you have to wait every time? Wait one or two times even if, if each time is waiting, it is better to re-measure their ability. Adjust the encryption intensity dynamically to better adapt to the current environment. In the future if you do not use low-end equipment, and then automatically adjusted back. Let the encryption strength, can dynamically adapt to the common equipment of the calculation force.

The implementation principle is similar to the automatic replacement salt value in the previous section.

4. Whimsical Solutions

The following YY a brain hole big open plan, if the website has large enough traffic. If there are many online users, aren't they just a bunch of free compute nodes? The problem of large computational volume, thrown to them to solve.

But there are some doubts about it, but what if it just goes to the bad guy? Obviously, you can't put too much sensitive data out. The node calculates, without knowing or knowing the ultimate purpose of the task.

However, what if I encounter a prank node and deliberately calculate the data in error? So you can't just push it to one node. Choose a few more, the final result is consistent is correct. So the risk probability is reduced.

Compared to peer computing, the site is a central, real-name, management will be easier. For prank users, penalties can be imposed, and users who have participated in the help are given a certain reward.

Imagine this, and continue to discuss the actual.

0x08 Performance Optimization

1. Why to optimize

Perhaps you would ask, "slow encryption" is not the hope that the calculation is slower, why do you want to optimize?

If this is a self-created covert algorithm, and confusing to outsiders simply can not read, that is not optimization is OK. You can even put some empty loops inside, deliberately consuming time. But in fact, what we have chosen is definitely a "cipher recommendation" public algorithm. Each of these operations has a mathematical meaning. Originally an operation only need a CPU instruction, because not enough optimization, with two instructions, then the extra time is internal friction. Causes encryption to last longer, but does not increase in strength.

2. Front-End computing weaknesses

If it is a local program, do not consider this problem at all, to the compiler on the line. But in the WEB environment, we can only use the browser to calculate! Scripts are much slower than local programs, so there is a lot of friction.

Why is the script slow? The main points are:

Weak type

Explanatory type

Sand box

3. Weak type

Scripts, which are used to handle simple logic, are not used for dense computations, so there is no need for strong typing. But now there's a black tech: Asm.js. It can provide true strong typing for JS through the use of syntactic sugars. This allows a significant increase in computational speed, which can be close to the performance of local programs!

But what about browsers that don't support asm.js? For example, there are a large number of IE users in the country, their calculation is very low. Fortunately, there is a back-up plan--flash, which has a variety of high-performance language features. Type, nature is a cinch.

It's slower than Asm.js,flash, but it's much faster than IE.

4. Explanatory type

Interpreted language, not only requires parsing, but also loses the "compile-time depth optimization" brought about by the performance improvement. Fortunately, Mozilla provides a tool that can be compiled from C-+ + Asm.js: Emscripten. With it, you don't have to write it naked. And when compiled with LLVM optimization, the resulting code quality will be higher.

In fact, this concept has been in Flash in the early days. There used to be a tool called Alchemy that could cross-C + + to compile Flash virtual machine instructions much faster than ActionScript.

Alchemy is now renamed FlasCC, and the open source version of Crossbridge

5. Sand Box

Some native languages seem to operate in a simple way, not in the sandbox. For example, array manipulation:

Vector[k] = V

The virtual machine first has to check if the index is out of bounds, or there will be serious problems. If the "front-end slow encryption" algorithm involves a lot of random access to memory, then there will be a lot of meaningless internal friction, so it has to be considered carefully. However, there are special occasions when scripts can be even faster than local programs! For example the MD5 mentioned at the beginning of the mass is repeatedly computed.

This is actually not difficult to explain:

First, the MD5 algorithm is simple. There are no memory operations such as tables, and local variables are used. The location of local variables is fixed, eliminating the overhead of cross-border checks. Second, Emscripten's optimization capability is no worse than the local compiler. Finally, after the local program compiles, the machine instructions will no longer change, and now the scripting engine has a tool for JIT. It generates more optimized machine instructions in real time, depending on the situation of the runtime.

Therefore, the choice of encryption algorithm, but also to take into account the actual operating environment, weaknesses, to play the maximum effect.

0x09 against the GPU

As we all know, running a password using the GPU can be many times faster. The GPU can be imagined as a processor with hundreds of of thousands of cores, but can only perform some simple instructions. Although the single core speed is less than the CPU, it can be won by quantity. When violence is poor, you can remove thousands of words from the dictionary while running, and the efficiency of the hack is improved.

Can you add some features to the algorithm that just hit the soft rib of the GPU?

1. Memory bottleneck

You've heard the word "Wright". Unlike Bitcoin, the scrypt algorithm is used to mine the Wright coin. This algorithm is very memory dependent and requires frequent reading and writing of a table. GPU Although each thread can be independently calculated, but only one video memory, everyone shared use. This means that only one thread can operate the video memory at the same time, and the other needs to wait. In this way, the advantages of concurrency are greatly curbed.

2. Transplant difficulty

When the cottage coins bloom, there is also a coin called X11coin, allegedly able to fight the ASIC. The principle is simple, with 11 different encryption algorithms in it. In this way, the resulting ASIC complexity has increased dramatically. Although this is not a long-term confrontation plan, but the idea can be used for reference. If one thing is too complicated, a lot of attackers are intimidated, so it's better to do something easier.

3. Other ideas

The reason why the GPU can be a big line, because the current encryption algorithm, are simple formula operations. This does not have much advantage over the CPU. Can you design an algorithm that relies on the benefits of the CPU? The CPU has many hidden strengths, such as pipelining. If the algorithm has a large number of conditional branches, perhaps the GPU is not good at it.

Of course, this is just a scenario. It is very difficult to create your own cryptographic algorithms, and it is not recommended to do so.

0x0A Extra Meaning

In addition to reducing the speed of password cracking, front-end slow encryption has some other meanings:

1. Reduce risk of leakage

The plaintext password entered by the user is encrypted in the front-end memory. Leaving the browser, the risk of disclosure is over. Even if the communication is bugged or the malicious middleware on the server is not able to get the plaintext password. Unless the Web page itself has malicious code, or if the user's system has malicious software.

2. Unable to stash plaintext

Although most sites claim that the user's plaintext password is not stored. But there is no evidence, perhaps privately, that it is still being quietly stored. If the front-end encryption, the site will not be able to get the user's plaintext password. Perhaps this is the point where many websites are reluctant to use front-end encryption.

In fact, the site is not willing to do so, we can make a stand-alone version of the slow encryption plugin. When the page password box is selected, pop up our plugin. After entering the password in the plugin, start the slow encryption calculation. Finally, the results are filled in the page password box. This way, all the sites are available. Of course, the registered account is not possible, you have to manually adjust.

3. Increase the cost of the pool

"Front-end slow encryption" needs to consume the user's computational power, and this disadvantage is sometimes a good thing.

For normal users, waiting for one second to log on is not very significant. But for users who log in frequently, this is an obstacle. Who will log in frequently? Maybe it's the attacker who hit the vault. They can not drag down the database of this website, so they use online login method, constantly testing the weak password account. If the frequency is controlled by IP, attackers can find a large number of proxies-how fast the speed of the Internet can be tried.

But using the front-end slow encryption, the attackers each try a password, you have to consume a large number of calculations, so the bottleneck card on the hardware-how fast, to try how fast. So, here is a bit like the meaning of the PoW (Proof-of-work, workload proof). We will introduce the PoW in detail later.

0x0B can't do it.

Although "front-end slow encryption" has many advantages, but it is not omnipotent. As mentioned in the previous section, it is possible to reduce risk rather than eliminate it. If there is a problem with the local environment, then any password input is risky.

Let's consider a scenario where a Web site uses "front-end slow encryption" but does not use https--, which causes the link to be tapped. Review the 0x05 section, if you get "slow encryption results", you can directly board the account, even if you do not know the plaintext password. That's true. But please think about it, does it reduce the loss?

Not only the account is stolen, and the plaintext password will be leaked, but now, only the account is stolen, plaintext password is still not available. So, the real protection of the front-end slow encryption is "password" instead of "account". Account stolen, password not to get!

If the attacker can not only eavesdrop, but also control the traffic, you can inject the attack script into the page to obtain the plaintext password. Of course, this is like computer poisoning, keyboard peeping, all belong to "environmental problems", not within the scope of this article. This article discusses the scenario of a database leak.

0x0C Multithreading Slow Encryption

The user's configuration is getting better, many are four-core, eight-core processor. Can you take advantage of multithreading to decompose slow encryption calculations? If each step of the calculation depends on the previous results, it is not possible to disassemble the solution. For example:

For i = 0 ~ 10000 x = hash (x) end

This is a serial calculation. However, only parallel problems can be decomposed into multiple small tasks. However, a different way of multithreading is also possible. For example, we use 4 threads:

# thread 1 x1 = hash (password + "SALT1") for i = 0 ~ 2500 x1 = Hash (x1) End # thread 2 x2 = hash (password + "SALT2") for i = 0 ~ 2500 x2 = Hash (x2) End # ...

The result is a combination of 4 results, once again encrypted, as a result of slow encryption. But does that make it easier to crack? Keep it for everyone to think about.

0x0D Summary

The front-end slow encryption is to allow each user to contribute a small amount of computing resources, so that encryption becomes stronger. Even if the data leaks, it also condenses the entire website user's calculation force, thus greatly increases the crack cost.

0xFF PostScript

When Bitcoin was popular in previous years, it was a whim to use a browser to dig mine. Although not done, but obtained some cryptographic posture. Recently re-organized and added some new ideas, so write a detailed article to share. Because cryptography belongs to the traditional domain, the combination of the current popular Web technology can be more innovative.

If you have doubts about the algorithm, you can look closely at the 0x05 section first.

If you are patient after reading this article, hope to have harvest:)

"Turn" http://www.techweb.com.cn/network/system/2015-12-01/2234147.shtml

Anti-drag library ――web front-end slow encryption