How to implement client application authorization?

Question

PHP

There are two web applications, I'll call them Client and Server for clarity .
The Client requests data from the Server , the Server responds to it. POST (or GET) request to a known URL, JSON response. SSL is not used.
Authorization of the Client on the Server occurs by key. The client sends the key, the Server checks it and processes (or does not process) the data.
Potentially, the key can be intercepted by an attacker, and then he will get access to the Server data .
Checking by the Server of the Client 's IPsomewhat reduces the risk, but it is not a panacea.
The source code of both the Client and the Server will be open, so the attacker probably knows how the key is generated and how it is checked.
Tell me how to organize the authorization of the Client on the Server as safely as possible in this situation.

Answer 1

If an attacker can access the current version key at any time and has access to the generation and verification method, it’s hard to come up with something.
If not, then the first thing that comes to mind is a constantly changing identifier for each question-answer pair, which the client receives from the server with each response, and signs with a secret with the next request and returns to the server. If the server decides that the key is valid, it processes the request and starts all over again.

Answer 2

If the sources are open, then the only option is asymmetric encryption with public keys.
The client and server exchange public keys and keep the secret ones.
There are many implementations. One of the possible:
1. The client connects to the server, provides him with his public key
2. the server sends the client a question signed with the client's public key
3. the client uses his private key to find out the server's question, resolves the issue and signs it with the server's public key, passes it to the server
4 The server applies its private key to the response, thereby removing the encryption, and verifies the response. if everything is OK - the server considers that the client is confirmed.
perhaps the same thing, but in the other direction so that the client checks the Server

Answer 3

1. Use RSA
2. Store the key on the client encrypted based on the login and password.
3. For authorization, use the electronic signature mechanism:
   
   • The server sends a randomly generated string like $sKey = md5(rand())
   • The client also generates a random string of the same type $cKey = md5(rand())
   • We glue the strings and sign their hash using the RSA private key (there are many implementations in JS) like sign(sha256($sKey+$cKey))
   • We send the signature and the string generated on the client to the server
   • On the server, we verify the signature using the public key
   
   

Or use Rutoken Web, but this is his work, you need to install the plugin.

Answer 4

Anonym , then each request must be assigned a unique number and not processed twice.
The Client tells the Server I want to delete the data, the Server saves the request and sends the Request ID to the Client. The client forwards this ID to the Server. The server deletes the data and writes down the ID. If an attacker sends this request again, then the Server will do nothing after checking this ID. already completed this request.
Something like this ... I don’t see any other options yet.

Answer 5

To protect against a Man-in-the-middle attack, encryption of transport or messages will help you.
Those. you either encrypt the data transfer layer, which means you use SSL, or the messages at the application layer. In the age of frameworks, it's easier to do things over SSL.
In general, the first chapter and the second chapter, paragraph 2.2 of the book Applied Cryptography, by Bruce Schneier. For you