What is the point in creating an API key signature if the API key is already known?

Question

PHP

What is the point in creating an API key signature if the API key is already known?
Well, for example, we created an API key: 1234567890, gave it to a person so that he can use it.
When requested, we simply check this key:

if($_GET['apikey'] !== '1234567890'){
 die( 'Die Die Die' );
}
//some code

Why do all those hashes, md5, sha etc. key, if it is known and you can do a simple check?

Suppose a person uses a signature with verification, a request like this comes in: url?key=32432432&usrid=100&[email protected]&status=update
In the script, we check this signature like this:

$siganture = sha1($key.'|'.$usrid.'|'.$email);
if($siganture !== $secret_pass) {
 die( 'Die Die Die' );
}
//some code

It turns out that the second check is the same as the first one, where the key is immediately checked, but only with unnecessary actions with checking the signature.
But if any person recognizes the Request API string: url?key=32432432&usrid=100&[email protected]&status=update, then he can send anything, then the meaning of such a tricky check is asked, if it does not protect, why not just use the first check option?

Answer 1

Slightly did not study the issue.
If you get password hashes through a vulnerability, you won't know the original password, right? and you can't use it as a key.
At the same time, you also do not know how your password hash is formed. And in this case, at least what the client enters is unknown, unless you know the source code and are not embedded inside the system. And we know that in 95%+ the user uses the same passwords everywhere. And here we save the user's password until a more serious hack.

Answer 2

In order not to openly transfer the api key over the network ...

Answer 3

The key is not passed anywhere when using a hash.
Only the server and the client know the key.
The hash is made up of the data + the key on the client.
The server checks that the data was sent using this key and that the data is exactly the same as when it was sent. In all other cases, the hash will not converge and the request will be sent by the forest.
There is nothing smart about this. Conventional cryptography to protect against interception of data + protection against unauthorized requests from third parties.
https://tproger.ru/articles/cryptography-encryption/
But if you send, as in the first version, just a key, the data can be easily changed to any other and the server does not care who sent what, and he cannot check it even if he wants to.

Answer 4

As you described, hashing doesn't make sense. But as a rule, 2 identifiers are always used, say the same api key (public key) and secret key ( secret key ). The name can change, for example ID + token or client_id + client_secret
Only the api key, parameters such as usrid and signature (hash) are passed in the request. Moreover, for the formation of the hash, it is the secret key that is known only to the sender and the recipient.
This allows you to prevent request spoofing, since the receiving party can check the hash, and in which case understand that the request data has been changed.
This approach is often used when integrating with payment systems, where after a successful payment, the payment system sends a request (postback, webhook) to the merchant's website, notifying that such and such a payment has been successfully completed.
For example, such a notification includes the order_id, sum, status parameters. If an attacker recognizes the url on the site where the parameters need to be passed, he can fake a notification from the payment system. This is where the mechanism for calculating the checksum comes into play, for example md5(order_id, sum, secret_key), and since the secret_key is unknown to the attacker, such a request cannot be faked.