1 Why?

Recently, I read the part of architecture security in Phoenix Architecture by Zhou Zhiming. In the book, I have made a systematic explanation of architecture security and broadened my vision. I hope this article can be used to practice and summarize the key points. Today, we are more concerned about personal privacy issues, learn safety related content, to provide some theoretical guidance for the design of safety related, to be able to understand why security company did well so design, also can guide their design more secure architecture in the company, and safety related issues are basically has nothing to do with specific business, there will be a general standard, Once mastered, it can be applied to any business situation.

What can you get out of it?

  1. What are the components of architectural security, and what is the focus of each? You can also read Zhou Zhiming’s article for further details.
  2. What is the dominant/preferred approach to security in each class? What is the rationale behind all this? And you can deepen your understanding through some sample analysis.

3 Architecture security includes content and key technical points explained in this article

Architectural security covers a lot of ground, including at least the following six parts. The following definitions are expanded from zhou zhiming’s book:

Authentication: How does the system correctly identify the real identity of the user? Authorization: How does the system control what data a user should see and what functions they can operate? How does the system ensure that the commitments made between it and the user are accurate, complete, and non-repudiation of the true intentions of the parties at the time? How does the system ensure that sensitive data cannot be accessed or abused by external or internal personnel, including system administrators? Transport Security: How does the system ensure that information transmitted over the network cannot be intercepted, tampered with or impersonated by third parties? Verification: How does the system ensure that data submitted to each service is compliant and does not pose a risk to system stability, data consistency, or correctness?Copy the code

3.1 certified

The authentication framework based on HTTP protocol generally relies on the content rather than the transmission protocol to achieve the authentication mode, because the implementation form is generally used in the form of login form, so it is often called “form authentication”. Before 2019, there is no industry standard for form authentication. What does the form look like, whether the user field, password field and verification code field should be encrypted on the client side and in what way, and what is the service address that accepts the form? It is entirely up to the client and server developers to negotiate. Until March 2019, the World Wide Web Consortium approved a world’s first Web content standard “WebAuthn”, WebAuthn completely abandoned the traditional password login method, instead of directly using biometrics (fingerprint, face, etc.) or entity key as identity credentials. Experience and security is better than the existing form authentication method. Some APP clients have enabled these authentication methods, the latest version of Chrome also provides webAuthn support, but so far, there are few websites that have supported webAuthn login. The following is a Demo implemented by a netizen, the login effect is as follows:

The realization of the code can be obtained from the original blog users.

The process of registering and authenticating with webAuthn is similar. The following figure shows the process:

The signup process is taken from the website and explained as follows (it doesn’t matter if you can’t read it for the moment, just know that it’s very secure and a very good experience as a certification) :

0. Application requests registration - The application issues a registration request. The protocol and format of this request is outside the scope of the WebAuthn standard. 1. Server sends challenge, user information, and dependent party information - The server sends challenge, user information, and dependent party information back to the application. Here, the protocol and format are outside the scope of the WebAuthn standard. Typically, this can be a REST API based on HTTPS connections (perhaps using XMLHttpRequest or Fetch). However, SOAP, RFC 2549, or almost any other protocol can also be used as long as it is in a secure connection. The parameters received from the server are passed to create(), and in most cases require little or no modification. Create () returns a Promise, and returns a AuthenticatorAttestationResponse (en - US) PublicKeyCredential (en - US). Note that the challenge must be a random buffer (at least 16 bytes) and must be generated on the server to ensure security. 2. The browser to the certifier call authenticatorMakeCredential () - within the browser, the browser will validate parameter with a default value completion of parameters, these parameters will then become AuthenticatorResponse. ClientDataJSON. One of the most important parameters is Origin, which is part of clientData, and the server will be able to verify it later. The arguments to call create() are passed to the authenticator along with clientDataJSON's SHA-256 hash (only the hash is sent because the connection to the authenticator may be a low-bandwidth NFC or Bluetooth connection, after which the authenticator only needs to sign the hash to ensure that it cannot be tampered with). 3. Authenticator creates a new key pair and proof - Before proceeding to the next step, authenticator usually asks the user for some form of confirmation, such as entering a PIN, using a fingerprint, performing an iris scan, etc., to prove that the user is present and agrees to register. After that, the authenticator creates a new asymmetric key pair and securely stores the private key for future authentication. The public key becomes part of the proof and is signed by the private key burned in the authenticator during production. The private key will have a chain of certificates that can be authenticated. 4. The authenticator returns the data to the browser - the new public key, globally unique credential ID, and other proof data are returned to the browser as attestationObject. 5. The browser generates the final data and the application sends the response to the server - create() 's Promise returns a PublicKeyCredential (en-US), Containing a certificate of the globally unique ID PublicKeyCredential. RawId (en - US) and contains AuthenticatorResponse clientDataJSON response AuthenticatorAttestationResponse (en - US). You can send PublicKeyCredential (en-US) back to the server using any format and protocol you like (note that ArrayBuffer attributes need to be base64 or similar encoding) 6. The server validates the data and completes the registration - Finally, the server performs a series of checks to ensure that the registration is complete and the data has not been tampered with. The steps include: - Verify that the received challenge is the same as the sent challenge - ensure origin is consistent as expected - verify clientDataHash's signature using the certificate chain corresponding to the authenticator type number and the complete list of verification steps can be found in the WebAuthn specification. Once authentication is successful, the server associates the new public key with the user account for future use when the user wishes to use the public key for authentication.Copy the code

WebAuthn uses asymmetric encryption of public key, private key to replace the traditional password, which is a very ideal authentication scheme, the private key is confidential, only the validator needs to know it, even the user himself does not need to know, there is no possibility of artificial leakage. It also solves the risk of traditional cryptography in network transmission. WebAuthn is still young and has limited penetration for the time being, but the authors believe that within a few years it will become a mainstream form of Web authentication supported by most sites and systems.

3.2 license

Authorization essentially resolves “who can operate which resources”. Two access control and authorization schemes, RBAC and OAuth2, are common in daily development. By introducing the concept of roles, RBAC grants rights for roles to operate resources, and grants rights to users so that users with these roles can operate resources. Basically, the company’s permission control module is based on RBAC.

OAuth2 is an authentication and authorization protocol for solving third-party applications. Allows a user to give third-party applications access to the user’s private resources stored on a site (such as photos, videos, and contact lists) without having to provide a user name and password to third-party applications. For example, many websites have the function of scanning login through wechat, and also use the authentication and authorization process of OAuth2.

Wechat Sweep login uses the authorization code mode in OAuth2 (for more modes, please refer to “Phoenix Architecture”). The access process of OAuth2 authorization code mode is as follows:

In the wechat Scan login scenario, the resource owner in the figure is the user, the operation agent is the browser, the third-party application is the third-party website that wants to use wechat scan to log in, and the authorization server is the wechat server.

For example, Janshu uses wechat to scan the login process as follows:

  • Select the wechat Scan login and open the wechat TWO-DIMENSIONAL code authentication page of the server, which has the callback address of the original web page:

    https://open.weixin.qq.com/connect/qrconnect?appid=wxe9199d568fe57fdd&client_id=wxe9199d568fe57fdd&redirect_uri=https%3A %2F%2Fwww.jianshu.com%2Fusers%2Fauth%2Fwechat%2Fcallback&response_type=code&scope=snsapi_login&state=%257B%257D#wechat_r edirectCopy the code

  • The user scans wechat and returns the code after successful authentication, as shown below:

  • The third-party application server uses code and AppSecret to obtain accesstoken and get the basic information of the wechat user to mark that the user has logged in.

  • Redirect to the page where the third-party login succeeds.

3.3 proof

HTTP protocol is a stateless transmission protocol, and each request is completely independent. Therefore, cookie-session mechanism is generally adopted in web development to enable the server to distinguish the user who sends the request. Some user session information is maintained in the server, so as to ensure high availability of the server, The user’s state information is stored in a centralized storage such as Redis. In addition to cookie-session, JWT (JSON Web Token) schemes can be used to keep information from being stored on the server and prevent information from being tampered during transmission.

JWT: After authentication, the server generates a JSON object and sends it back to the user. In the future, the user will send back this JSON object when communicating with the server. The server identifies the user solely on this object. To prevent users from tampering with the data, the server generates this object with a signature. The JWT data structure consists of three parts: Header, Payload, and Signature. Write it as a line that looks like this:

Header.Payload.Signature
Copy the code

The Header section is a JSON object that describes the metadata of the JWT, usually something like this.

{
  "alg": "HS256",
  "typ": "JWT"
}
Copy the code

Payload is also a JSON object that stores data that needs to be transmitted. You can define private fields required by services. JWT defines seven official fields for selection.

Iss (Issuer) : exp (expiration time) : expiration time sub (subject) : aud (audience) : NBF (Not Before) : iAT (Issued At) : Issue time JTI (JWT ID) : numberCopy the code

The Signature section is a Signature to the first two sections, preventing data tampering. You need to specify a secret. This key is known only to the server and cannot be disclosed to users. Then, using the signature algorithm specified in the Header (HMAC SHA256 by default), generate the signature as follows.

HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
Copy the code

After calculating the Signature, compose the Header, Payload, and Signature into a string. The Header and Payload must be converted using Base64URL. Then use “dot” between the three parts (.) Delimit, and it can be returned to the user.

The final effect is as follows:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwMTIxMiIsIm5hbWUiOiJKb2huIERvZSIsImlhdCI6MTUxNjIzOTAyMn0.Roe GlqmkqtGrgjmV0Z5EF8bwCLQdzRXwPiG1ZmiNVfUCopy the code

The encoded data can be viewed and generated on the website jwt. IO /. Java has a JJWT tool to generate and parse JWT in a project at github.com/jwtk/jjwt.

The client takes this JWT with it every time it communicates with the server. You can put it in a Cookie and send it automatically, but that’s not cross-domain, so it’s better to put it in the HTTP request header Authorization field.

The application of JWT is still relatively rare, but it provides a kind of stateless idea on the server side. Under normal circumstances, cookie-session mechanism can meet the requirements.

3.4 confidentiality

How to transfer the password from the client to the server is usually a simple hash summary of the user password on the client. Fundamentally put an end to the server database or log password plaintext storage, large websites are dragged library thing emerge in endlessly, if the use of plaintext, it is more dangerous. However, plaintext is not stored. If a simple hash is used to store plaintext on the server, it is easier to obtain plaintext through rainbow table attack. Salt should be added to deal with rainbow table attack. This section focuses on why ciphertext can be easily cracked in common hash mode.

For example, the Login password of Windows XP will be saved in Sam file by some hash algorithms. The login password of Windows XP can be quickly obtained by rainbow table attack. The following is the screenshot after cracking the password by using ophcrack of Rainbow table:

In this case, a 14-length password containing letters and numbers was cracked in 15 minutes, while simpler passwords could be cracked in seconds using a lightweight rainbow list.

Taking a 14-digit combination password as an example, there are 1.24×1025 ((10+26+26) 14) possibilities if the exhaustive method is used. Even if a computer can perform 1 billion operations per second, it would take 400 million years to crack the password. If a large number of disks are used to store hash strings, and then the plaintext is retrieved by table lookup, the hash string storage (regardless of the plaintext storage) is an astronomical number (2128/8 bytes), even if only 128-bit hash strings are stored.

So the rainbow table is a balance between computing time and storage space.

The rainbow list will consist of many chains. For each chain, there will be many nodes of the chain. The relationship between these chain nodes is as follows:

[plaintext 1] -->(H)--> [second node (Hash 1)] -->(R1)-- > [third node (plaintext 2)] -->(H)--> [fourth node (Hash 2)] -->(R2)--> [fifth node (plaintext 3)] Example: 12345->(H)-> abweFsdfse ->(R1)->32112->(H)-> asdasGASdf ->(R2)- >13423 - Where H is the Hash function to decrypt the Hash string. -r1 ~ Rx are rainbow table built from Hash to plaintext functions.Copy the code

The rainbow table only needs to store the first node and the last node of the chain, thus greatly reducing the storage space (the longer the chain, the more nodes, the more space saved).

Rainbow table cracking process is as follows:

Suppose there are K Hash nodes in a chain. 1. Suppose that the ciphertext to be decrypted is located at the last Hash node of a chain, perform Rk operation on it first to see whether the corresponding value can be found in the last Hash node. If found, the plaintext that generated the Hash value is the plaintext to be cracked. 2. If the ciphertext to be decrypted cannot be found, perform R(K-1), H, and RK operations on the second-to-last Hash node, and then compare the last node. 3. Find the plaintext to decrypt.Copy the code

It is difficult to build rainbow tables by yourself. You can download rainbow tables in various Hash modes and sizes from the Internet. We need to increase the difficulty of cracking the rainbow table when doing secret work. We can add salt value to the Hash.

3.5 the transmission

The transport layer is important because if the transport layer is plaintext transport, such as HTTP transport, it is very easy for a third party to get HTTP content. HTTPS is the only way to prevent HTTP traffic from being stolen by third parties. So how does HTTPS ensure security? Simply HTTPS USES symmetric encryption and asymmetric encryption, first by asymmetric encryption delivered the symmetric encryption key, and then the subsequent HTTP content shall be transmitted by symmetric encryption, asymmetric encryption private key by the service side of the saved, and the public key can be open to all the people, by the content of the public key encryption can only be decrypted by the service side.

Currently, HTTPS generally adopts TLS1.2 protocol, and the handshake sequence of TSL is shown as follows:

In step 2, when the Server returns Server Hello, it also returns a digital certificate containing the asymmetric encryption public key. The client uses the public key to encrypt the symmetrically encrypted key and then transmits it to the server.

You can view the handshake process through WireShark, as shown in the following figure:

At this point, there is a question of how the client can be sure that the public key passed to it is the public key that the server expects it to get. So you have to use the CA mechanism. The CA authority needs to sign the digital certificate that contains the server’s public key. The client has some CA root certificates built into the operating system to verify the validity of the digital certificate and ensure that the client obtains the correct public key.

Out of curiosity, I learned through the Internet whether there is a CA organization leakage of the private key, if the CA organization’s private key leakage, that is a very dangerous thing, then the digital certificate based on the SIGNATURE of the CA organization will not be trusted. There have been cases of CA organizations leaking private keys, such as DigiNotar, a Dutch CA security certificate provider, whose servers were hacked and the private keys were stolen. The attacker issued 531 forged certificates based on the private key, and Then Microsoft scrambled to issue an operating system patch that placed DigiNotar on a list of untrusted cas, and DigiNotar went bankrupt.

However, if we want to capture HTTPS packets on the client for analysis, we can use two methods:

  1. Use a packet capture tool to issue a certificate and mark the issuing authority in the operating system as trusted. Charles, for example, captures HTTPS packets in this way.
  2. Obtain the HTTPS symmetric encryption key and use the key to decrypt the obtained encryption content. For example, Wireshark uses Chrome HTTPS to transfer symmetric keys.

3.6 validation

This part is more about business verification. Usually, we write most business code in this part, which is usually carried out at all layers from the client side to the access layer to the logical layer. There are two common problems with business logic validation in code:

  1. The code logic is filled with a lot of null-judgment logic and other verification, which affects the simplicity of the code
  2. At which level is it more reasonable for the caller and the called to perform verification

The approach advocated by the authors of the book is to take the validation behavior out of the hierarchy and do it not at the specific layer, but on the Bean. Java Bean Validation. What is done on beans can easily be reused at all levels. For example, in the following code, the Account authentication can be annotated by @uniqueAccount.

public Response createUser(@Valid @UniqueAccount Account user) {
  return CommonResponse.op(() -> service.createAccount(user));
}
Copy the code

For more examples and usage, you can check out Teacher Zhou’s Phoenix architecture.

4 summarizes

Thanks for Teacher Zhou’s book (some screenshots in the article are also quoted from Teacher Zhou’s book website), which makes me learn the safety part in a more systematic way. Besides, SOME examples have deepened my understanding of this part, and I also hope to help you understand it. If you want a more complete understanding of the relevant content, I suggest you also read zhou’s book in its entirety. Comments are welcome.

5 appendix

Individuals have also opened a wechat public account, which allows them to participate in the comments and receive the latest articles in a timely manner.

Author: csophys

Created: 2022-02-12 Sat 23:51

Validate