is not afraid of pants, password security can protect "turn"

In the previous article, "the correct posture of the design of secure account system," the main proposed some design methods and ideas, and did not give a more specific, can be implemented security encryption scheme. After my careful thinking and understanding of some of the current scenarios, I designed a security encryption scheme that I think is more secure. This article is mainly about this program, very welcome and look forward to a discussion with the reader.

First, we define the ultimate goal of the secure encryption scheme:

Even if the data is towed, the code is compromised, and the request is hijacked, the user's password is protected from disclosure.

To be specific, our ideal system of absolute security is probably this:

1. First, it is difficult to keep the data in the library.
2. Even if the data is dragged, the attacker is unable to decipher the user's password from the database.
3. Even if the data is towed, the attacker cannot forge the logon request through authentication.
4. Even if the data is dragged into the library, the attacker can hijack the user's request data and cannot decipher the user's password.

How to protect the data from being towed, this is not the start of the talk. First of all, let's say password encryption. Now it is very rare that the user's password will be saved directly by the system, or at least the MD5 of the password will be counted. MD5 this irreversible encryption method is theoretically safe, but with the advent of rainbow tables, a large number of long-length passwords can be pushed back directly from the Rainbow table.

Therefore, it is not enough to encrypt the password only MD5. Smart programmers came up with a solution, even if the user's password is very short, as long as I put a long character behind his short password, and then calculate MD5, it becomes very difficult to launch the original password. Adding this long-length character, we call it salt, which encrypts the result in this way, we call it 加盐 Hash . Like what:

Salt

As we said in the previous article, the usual hash functions, SHA-256, SHA-512 will be more secure than MD5, more difficult to crack, for the sake of higher security considerations, I will use SHA-512 in this scenario instead of MD5.

Salt

With the addition of the salt hash above, even if the attacker gets the final result, it is difficult to reverse the original password. cannot be reversed, but can be pushed forward, assuming that the attacker will also get the salt value, then he can enumerate through all 6-digit simple password, add salt hash, calculate a result comparison table, so as to crack a simple password. This is what is commonly said by brute force.

In response to brute force, I used a slow hash of salt. Slow hashing refers to the very slow execution of this hash function, which takes a very, very long time to enumerate through all the possible results of a brute-force hack. For example: Bcrypt is such a slow hash function:

Bcrypt

By adjusting cost The parameters, you can adjust how slow the function is. Assuming that Bcrypt calculates a simple password that takes 0.5 seconds to traverse 6 bits at a time, it takes: ((26 * 2 + 10) ^6)/2 seconds, about 900 years.

Well, with the basics above, take a look at my Final Solution:

Password_secutity

There are a lot of details, I said in phases:

1. Negotiating keys

The key negotiation algorithm based on asymmetric encryption can negotiate a key that only the two parties know, and then use the key to transmit the data with symmetric encryption, if the communication content is completely exposed. The ECDH key negotiated with the.

2. Request Salt

After the two parties have negotiated a key sharedkey, they can use the Sharedkey as the AES symmetric encrypted key for communication, the client passes to the server's own public key A, and the encrypted user ID (UID). The server finds the UID for the SALT1 and SALT2 from the database, and then encrypts it back to the client.

Note that the SALT1 and Salt2 saved by the server are best stored separately from the user data and saved in a database of other servers, so even if it is injected by SQL, it can be very difficult to get Salt1 and SALT2.

3. Verify the password

This is the most important step. After the client gets SALT1 and SALT2, two salt hashes can be computed:

SaltHash1 = bcrypt(SHA512(password), uid + salt1, 10)SaltHash2 = SHA512(SaltHash1 + uid + salt2)

Using SALTHASH2 as the AES key, the encryption includes Uid,time,salthash1,randkey and other content transmitted to the server:

Ticket = AES(SaltHash2, uid + time + SaltHash1 + RandKey)AES(SharedKey, Ticket)

The server uses Sharedkey to decrypt the Ticket, then find the UID corresponding SALTHASH2 from the database, decrypt Ticket, get SaltHash1, use SALTHASH1 to recalculate SaltHash2 to see if and in the database SaltHash2 to verify that the password is correct.

When verifying that two hash values are equal, use a constant time comparison function to prevent exploratory attacks.

Time is used to record when a packet is sent to prevent a replay attack from being recorded.

4. Encrypted transmission

After password authentication is passed, the server generates a random temporary key Tempkey (using a secure random function) and transmits it to the client using Randkey as the key. Both data interactions are then encrypted using Tempkey as the AES key.

Let's say the library is towed.

The above is the whole process of encrypted transmission and storage. Let's assume several attack scenarios:

1. If the data is towed, will the password be compromised?

   SALT1 in the database, SALT2, SALTHASH2 exposed, it is almost impossible to reverse the original password from the SALTHASH2 directly.

2. Assuming the data is towed, can an attacker forge a login request to authenticate?

   The attacker will need to SaltHash1 when generating Ticket, but because they do not know the password, they cannot calculate the SALTHASH1 and cannot reverse the SaltHash1 from SALTHASH2, so it is not possible to forge a login request through authentication.

3. Assuming the data is towed, the attacker uses a man-in-the-middle attack, hijacking the user's request, and the password is compromised?

   The middleman owns all the data from the real server and fakes the real one, so he can decrypt the SaltHash1 in the Ticket, but SaltHash1 cannot decrypt the original password. Therefore, the password will not be compromised.

   However, an intermediate attack can be taken to the last tempkey, so that all subsequent communication processes can be monitored. This is a difficult problem to solve, because in the case where everything on the server is exposed, the man-in-the-middle hypothesis can hijack the user data and fake the real server, which is difficult and separate from the real server. The solution might be to prevent a man-in-the-middle attack, ensuring that the Server's public key is not tampered with on the client.

   If the attack has progressed to such a degree, is there a way to remedy it? Yes. Because the attacker can only listen to the user's logon process, do not know the real password. As a result, you only need to upgrade the SALT2 on the server side to generate a new SALTHASH2 that will invalidate all attackers ' attacks.

   This is the case: the user's normal login, after the service-side verification, generate a new SALT2, and then based on the SALTHASH1 recalculated SaltHash2 into the database. The next time the user logs in, get a new SALT2, the password is not changed, the same can be logged in, the attacker before the data of the library is also invalid.

Q & A

1. With the bcrypt slow hash function, does the server handle a large number of user logon requests, performance-borne?

   In this scheme, it is careful to note that the bcrypt is only performed on the client side, and the server is directly computed by the client (SALTHASH1) and SHA-512 the results of the calculation. Therefore, the performance pressure is distributed to the various clients.

2. Why use a two Salt value?

   A two Salt value is used to prevent the user from being hijacked after a request is made to break the password after the library is dragged. Only a user with a password can calculate the SALTHASH1 with the first Salt value and cannot back up the original password. The second Salt value can increase the difficulty of decrypting the SALTHASH1 directly after being dragged into a library.

3. Why dynamic requests for SALT1 and SALT2?

   Salt value directly written on the client is not good, and write dead to modify also have to upgrade the client. Dynamic request Salt value, you can also implement a dynamic upgrade of the password without upgrading the client: The server can periodically replace the SALT2, recalculate the SALTHASH2, so that the attacker will soon be in a failed state even if the data is dragged.

4. The database has all been dragged away, the password does not leak what is the point?

   In fact, as mentioned in the upgrade SALT2 remedy, the user can be completely unaware of the situation, do not need to change the password to upgrade the account system. At the same time, it is also a responsibility to protect the user's password and not be taken by the attacker to hit another site's library.

You are welcome to discuss the proposal for this article, if there is a false or ill-conceived place, please point out. Or have better suggestions or comments, welcome to communicate!

Wen/coderzh (author of Jane's book)
Original link: http://www.jianshu.com/p/d3f5aab48158
Copyright belongs to the author, please contact the author to obtain authorization, and Mark "book author".

is not afraid of pants, password security can protect "turn"