api design - php interface token data encryption

I am using php to write the app interface recently, and I have some questions

First of all, about token (token)
Token is generated when the user logs in
The user token is saved on the server and cached locally on the client. Most interfaces require the client to send the token to the server. Verify the token in the database

The unique token for each user is composed of the year and month and the client machine code identifying the user ID
(The year and month are the machine codes used for the login retention period to ensure that the user can quickly identify the login the next time he logs in. Source, important credentials to determine whether you need to log in again, the user ID is actually added by the way)

Here comes the problem
=. = This thing feels like it is no different from a session
**If you capture the package directly
Every user’s token on the client of the same platform is the same, which is of no use in preventing attacks**
And this kind of token is based on the user, so this kind of token cannot help with the user's login registration verification (anti-robot) verification
=. =I am still designing something to verify (is there a way to also do login and registration verification based on this token idea)

Reply content:

I am using php to write the app interface recently, and I have some questions

First of all, about token (token)
Token is generated when the user logs in
The user token is saved on the server and cached locally on the client. Most interfaces require the client to send the token to the server. Verify the token in the database

The unique token for each user is composed of the year and month and the client machine code identifying the user ID
(The year and month are the machine codes used for the login retention period to ensure that the user can quickly identify the login the next time he logs in. Source, important credentials to determine whether you need to log in again, the user ID is actually added by the way)

Here comes the problem
=. = This thing feels like it is no different from a session
**If you capture the package directly
Every user’s token on the client of the same platform is the same, which is of no use in preventing attacks**
And this kind of token is based on the user, so this kind of token cannot help with the user's login and registration verification (anti-robot) verification
=. =I am still designing something to verify (is there a way to also do login and registration verification based on this token idea)

This question is extremely simple, take PHP as an example.
But it is different from session, it is a bit close to cookies. This is designed to solve the problem of troublesome cookie value transfer.

---

First of all, during the login process, the data submitted by the user to the server should be
username, password, client_key
. After php gets these data on the server, it uses the verification algorithm to obtain Check value, such as md5.
(ps: It’s not possible without a password, otherwise the user can still log in quickly after changing the password. Isn’t this a scam?)
$salt is a 加密key to prevent others from guessing the encryption algorithm.

$token=md5($username.$password.date('yyyy').date('mm').$client_key.$salt);

After the calculation is completed, $token will be returned to the client as storage. In the future, the client only needs to send this $token and user name to the server.

When php receives this $token, it will do the above operation again to see if it is consistent and it can be quickly judged.

---

If you need to prevent malicious registration and login, you need to encrypt client_key on the client and then decrypt it on the server for verification. However, this is of no use. All client codes are unsafe. , can be analyzed through decompilation and deobfuscation, and then forged as usual. So client-side encryption makes no sense.
In addition, judging the server by IP is also a way.
However, fundamentally speaking, preventing malicious attacks requires verification of mobile phone numbers before registration, which is currently basically achieved through this method.

I am also writing, but it has not been implemented yet

1. If the user logs in through token verification, which is something similar to a cookie on the app, there is no problem with the user using it to log in. If the user logs in from another client, he or she needs to log in again. Then the verification Then get the client machine code and match it.

In addition, the client's token can also be complicated, encrypted using js, obtained in php and then parsed.

Although tokens are insecure to a certain extent, they are safer than passing user passwords.
The scenario of using token is generally a stateless and cookie-free mode. If there is a token, it acts as the sessionID in cookies.
Although the token is not secure, it can still be trusted with a certain degree of verification mode

I just wrote a blog not long ago. Although it didn’t involve some technical details, the ideas are still there. Let’s see if it helps you.

First of all, you have to make it clear that Token is used to verify identity after logging in, so it denies your expectation to use it to prevent malicious registration from the beginning. The two are completely incompatible. Secondly, if you want to talk about the difference between Token and Session, the difference is that Token is more customized, because it is implemented by you, you can do a lot of things that Session is inconvenient to do, such as better Device authentication, more convenient control of validity period, better cross-platform performance... Most importantly, the HTTP protocol itself is defined as stateless, and the existence of Cookie undoubtedly damages the definition of stateless, so Almost all interfaces refuse to use Cookie and abandon Cookie, so Token naturally becomes the first choice for verification. Finally, the security of Token focuses on whether it will be cracked or tampered with, not whether it will be intercepted during transmission and cause a man-in-the-middle attack. Interception protection should be achieved by strengthening the security during the transmission process, such as adding parameter signatures, or directly using HTTPS.