API Design-PHP interface token data encryption

Recently in the interface with PHP to write apps, there are some questions

First on token (token)
Token is generated when the user logs on
User Token save inbound client on the server the local majority of the interfaces require the client to send tokens in the token and server-side database for authentication

Each user's unique token consists of the month and the client machine code that identifies the user ID.
(year and year is to do the registration period limit for the machine code is to ensure that users at the next logon, quickly identify the source of login, to determine whether the need to re-login important credentials, the user ID is actually by the way add)

Here's the problem.
= = This thing feels like it doesn't make any difference to the session.
* * If you just grab the bag
The token for each client on a platform is the same. There is no use for anti-attack * *
And this token is user-based so the user's login registration verification (anti-BOT) verification on this token is not helpful
= = I am still in the design of a what to verify (there is a way to sign on this token thinking of registration verification also done?)

Reply content:

Recently in the interface with PHP to write apps, there are some questions

First on token (token)
Token is generated when the user logs on
User Token save inbound client on the server the local majority of the interfaces require the client to send tokens in the token and server-side database for authentication

Each user's unique token consists of the month and the client machine code that identifies the user ID.
(year and year is to do the registration period limit for the machine code is to ensure that users at the next logon, quickly identify the source of login, to determine whether the need to re-login important credentials, the user ID is actually by the way add)

Here's the problem.
= = This thing feels like it doesn't make any difference to the session.
* * If you just grab the bag
The token for each client on a platform is the same. There is no use for anti-attack * *
And this token is user-based so the user's login registration verification (anti-BOT) verification on this token is not helpful
= = I am still in the design of a what to verify (there is a way to sign on this token thinking of registration verification also done?)

This is a very simple question, with PHP as an example.
But session unlike, and cookies a little closer, design this is to solve the problem of the trouble of the value of cookies.

First, in the process of landing, the user submits data to the server should be
username, password ,client_key
PHP gets the data from the server, using the checksum algorithm to get the checksum value, such as md5 .
(PS: No password is not possible, otherwise the user changes the password before or can be fast landing, this does not deceptive?)
$saltis one 加密key that prevents others from guessing the encryption algorithm.

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

When the calculation is complete $token , it is returned to the client as storage. In the future, clients only need to send this $token and user names to the server.

When PHP receives this $token , do one more of the above operation, see whether the same can be quickly judged.

If you need to prevent malicious registration and login, you need to encrypt the client, client_key and then the server decryption to do the verification, but this does not have any eggs, all the client's code is not safe, can be anti-compilation, anti-aliasing analysis, and then forged. so the client's encryption doesn't make sense.
In addition, the server through IP judgment is also a method.
However, from the root point of this, to prevent malicious attacks on the need to verify the mobile phone number to register, is basically implemented by this method.

I'm writing it, and I haven't realized it yet.

1. If the user is through token authentication login, in the app is similar to the cookie thing, the user to login is no problem, if it is when the user for the client login, you need to re-login, that in the verification time to obtain the client machine code matching a bit.

In addition, the client token can also be made complex, with JS encryption processing, in PHP to obtain and then parse.

While token is somewhat unsafe, it is more secure than passing a user's password.
The use of tokens is generally a stateless, cookie-free mode, if tokens act as SessionID in cookies.
Token is unsafe, but it can be trusted by a certain degree of validation.

Just before soon wrote a blog, although not related to some technical details, but there are some ideas, see if you have any help.

First of all, you have to be clear, Token is used to authenticate the identity after login, so in the beginning, you are expected to use it to do anti-malware registration, the two completely do not play. Secondly, to say Token with Session what difference, that difference lies Token in more has the custom type, because it is by you realization, can do many inconvenient Session things, such as better equipment certification, more convenient control validity period, better cross-platform ... Most importantly, the HTTP protocol itself is stateless, and the existence of Cookie such a thing is undoubtedly detrimental to the definition of stateless, so almost all of the interfaces are refused to use Cookie , abandoned Cookie , which Token naturally became the first choice of authentication. Finally, Token the security focuses on the fact that it will not be cracked and will not be tampered with, not because it will not be intercepted when it is transmitted, resulting in intermediate attacks. Interception of protection should be implemented by you to enhance the security of the transmission process, such as increasing the parameter signature, or directly on HTTPS.

