Shulou(Shulou.com)06/01 Report--

Christmas is coming soon, and enthusiasm for penetration testing continues unabated. Our SINE security is here to develop a comprehensive detection method and key points for user authentication login security. Json web token (JWT) is an open standard based on JSON (RFC 7519) for transmitting statements between network application environments. The token is designed to be compact and secure and is particularly suitable for single sign-on (SSO) scenarios at distributed sites. The declaration of JWT is generally used to transfer authenticated user identity information between the identity provider and the service provider in order to obtain resources from the resource server, and can also add some additional declaration information necessary for other business logic. The token can also be directly used for authentication or can be encrypted.

7.2.2. Constitute

It is divided into three parts, namely header/payload/signature. Where header is the type of declaration and the algorithm used for encryption. Payload is the load, followed by HMAC ((header) + (payload), secret)

7.2.3. Safety problem

7.2.3.1. Header part

Whether the algorithm is supported to modify whether the nonekid field has injected jwk elements and whether the encryption algorithm on the whitelist is forced to be used

7.2.3.2. Payload part

Whether there is sensitive information to check expiration policies, such as exp, iat

7.2.3.3. Signature part

Check whether the signing key can be forcibly logged in and whether the key can be obtained by other means.

7.2.3.4. Other

Modify the algorithm RS256 to HS256 weak key cracking

Kerberos

7.3.1. Brief introduction

In a nutshell, Kerberos provides a single sign-on (SSO) method. Consider a scenario where there are different servers in a network, such as print servers, mail servers, and file servers. These servers have the need for authentication. Naturally, it is not possible for each server to implement its own authentication system, but to provide a central authentication server (AS-Authentication Server) for these servers to use. In this way, any client only needs to maintain a password to log in to all servers.

Therefore, there are at least three roles in the Kerberos system: authentication server (AS), client (Client) and normal server (Server). The client and server will authenticate each other with the help of AS. In Kerberos systems, both the client and the server have a unique name, called Principal. At the same time, both the client and the server have their own passwords, and their passwords are known only to themselves and the authentication server AS.

7.3.2. Simplified authentication process

The client initiates a request to the server. The content of the request is: the principal of the client. After receiving the request, the principalAS of the server randomly generates a password Kc, s (session key), and generates the following two data to return to the client 1. The data to the client is encrypted with the password of the client, and the content is a random password, session,server_principal2. The data on the server side is encrypted with the server password, and the content is a random password. After getting the two data in the second step, the session,client_principal client first uses its own password to unlock the data, get Kc, s, and then generate an Authenticator, which mainly includes the current time and Ts,c check code, and encrypts it with SessionKey Kc,s. Then the client sends the Authenticator and the data to server to the server at the same time. First, unlock the data with its own password, get the SessionKey Kc,s, then unlock the Authenticator with Kc,s, and do the following check 1. Check that the timestamp in Authenticator is within 5 minutes of the current time, and check that the timestamp appears for the first time. If this timestamp does not appear for the first time, it means that someone intercepted the content previously sent by the client and carried out a Replay attack. two。 Check whether the checksum is correct 3. If all are correct, the client uses the authentication server segment to selectively reply a message to the client to complete the two-way authentication. The content is that the client verifies the server by unlocking the message and comparing whether the timestamp sent back is consistent with the timestamp sent by the client itself.

7.3.3. Complete certification process

The process described above has been able to complete the mutual authentication between the client and the server. However, the inconvenient thing is that each authentication requires the client to enter its own password.

Therefore, in the Kerberos system, a new role is introduced called data Authorization Service (TGS-Ticket Granting Service), which is similar to an ordinary server, except that the service it provides is to distribute data for clients to authenticate with other servers.

In this way, there are four roles in the Kerberos system: authentication server (AS), client (Client), normal server (Server) and data authorization service (TGS). In this way, the authentication process for the client to communicate with the server for the first time is divided into the following six steps:

The client initiates a request to AS. The content of the request is: the principal of the client. After the rincipalAS of the data authorization server receives the request, it randomly generates a password Kc, s (session key), and generates the following two data to return to the client: 1. The data to the client is encrypted with the password of the client, and the content is a random password, session,tgs_principal2. The data for tgs is encrypted with the password of tgs, and the content is random password. After getting the two data in the second step, the session,client_principal client first uses its own password to unlock the data to get Kc, s, and then generates an Authenticator, which mainly includes the current time and Ts,c check code, and encrypts it with SessionKey Kc,s. After that, the client initiates a request to tgs, including: 1.Authenticator2. Send the data to tgs at the same time to the server 3.server_principalTGS first unlock the data with your own password, get the SessionKey Kc,s, then unlock the Authenticator with Kc,s, and do the following check 1. Check that the timestamp in Authenticator is within 5 minutes of the current time, and check that the timestamp appears for the first time. If this timestamp does not appear for the first time, it means that someone intercepted the content previously sent by the client and carried out a Replay attack. two。 Check whether the checksum is correct 3. If both are correct, the client passes the authentication tgs to generate a session key to assemble two data to the client 1. Encrypt data with client and tgs session key, including newly generated session key and server_principal2. Encrypt the data with the server's password, including the newly generated session key and client principal clients, after receiving the two data, unlock their own, and then generate an Authenticator, send a request to the server, including 1.Authenticator2. After receiving the request, the data server to the server unlocks the data with its own password to get the session key, and then uses session key to unlock the authenticator to verify for no reason. The server can choose to return a timestamp encrypted with session key to complete two-way verification. The client verifies the server by unlocking the message and comparing whether the timestamp sent back is consistent with the timestamp sent by itself.

SAML

7.4.1. Brief introduction

SAML (Security Assertion Markup Language), translated as Security assertion markup language, is a xXML format language that uses XML format interaction to complete the function of SSO. There are two versions of SAML, 1.1and 2.0. these two versions are not compatible, but are similar in logical concept or object structure, but differ in some details.

7.4.2. Authentication process

The authentication of SAML involves three roles, namely, service provider (SP), authentication service (IDP) and user (Client). A typical authentication process is as follows:

Client accesses protected resources SP generate authentication request SAML returns to ClientClient submit request to IDPIDP return authentication request Client logs in to IDP authentication success, IDP generates private key signature identifies the authorized SAML, returns to ClientClient, submits SAML to SPSP to read SAML, determines that the request is valid, and returns resources

7.4.3. Safety problem

Due to the authentication option in ssl mode, signature tags can be deleted to bypass authentication. If expiration is missing in SAML and asserting that ID is not unique, it may be affected by replay attacks. More and more website security problems are emerging day by day. If you want to conduct comprehensive security testing and penetration testing on the website or platform, you can consult a professional website security company to conduct security reinforcement penetration testing. Domestic relatively good recommendations Sinesafe, Green Alliance, Kai Ming Star, convinced and so on are relatively large security companies.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.