Какой смысл в создании сигнатуры API ключа, если API ключ и так известен?

Question

[WorldofMine]

Какой смысл в создании сигнатуры API ключа, если API ключ и так известен?
Ну например, мы создали API ключ: 1234567890, дали его человеку чтобы он им пользовался.
При запросе просто проверяем этот ключ:

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

Зачем делать все эти хэши, md5, sha и т.д. ключа, если он известен и можно сделать простую проверку?

Допустим, человек использует сигнатуру с проверкой, приходит запрос типа: url?key=32432432&usrid=100&[e-mail]&status=update
В скрипте, проверяем эту сигнатуру так:

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

Получается что вторая проверка один в один что и первая где сразу сверяется ключ, но только с лишними действиями с проверкой сигнатуры.
Но если любой человек узнает строку API Запроса: url?key=32432432&usrid=100&[e-mail]&status=update, то он может отправлять что угодно, тогда спрашивается смысл такой мудренной проверки, если она не защищает, почему просто первый вариант проверки не использовать?

Answer 1

[Dmitry Bay]

Чуть-чуть не изучили вопрос.

Если вы через уязвимость получите хэши паролей, вы не будете знать первоначальный пароль, верно? и не сможете его использовать в качестве ключа.
При этом вы так же не знаете, как формируется ваш хэш пароля. И в этом случае ,как минимум то, что вводит клиент - неизвестно, если вы не знаете исходный код и не внедряетесь внутрь системы. А мы то знаем, что в 95%+ пользователь использует одни и те же пароли везде. И тут мы сохраняем пароль пользователя до более серъезного взлома.

Comments

[WorldofMine]

Но перехватив хэш, мы сможем повторить сколько угодно раз исходный запрос.

[Александр Аксентьев]

WorldofMine, вот именно что исходный, не сможет поменять параметры никакие.
Ну а чтобы это не ломало что-либо существует идемпотентность или тупо номер заказа/иеднтификатор какой-либо по которому будет понятно что запрос уже прошел и не надо второй раз его обрабатывать.

Answer 2

[Александр Аксентьев]

Ключ никуда не передаётся при использовании хеша.

Ключ знают только сервер и клиент.
Хеш составляется из данных + ключа на клиенте.
Сервер проверяет что данные отправлены с использованием этого ключа и данные именно те которые были при отправке. Во всех остальных случаях хеш не сойдётся и запрос будет отправлен лесом.
Ничего мудрёного нет в этом. Обычная криптография для защиты от перехвата данных + защита от несанкционированных запросов третьих лиц.
https://tproger.ru/articles/cryptography-encryption/

Зато если отправлять как в первом варианте просто ключ - данные легко можно поменять на любые другие и серверу пофиг кто и что отправил, да и проверить он это не может даже если захочет.

Answer 3

[nokimaro]

В том виде как описали вы, хэширование не имеет смысла. Но как правило всегда используется 2 идентификатора, скажем тот же api key (открытый ключ) и секретный ключ (secret key). Назваие может меняться, например ID + token или client_id + client_secret
В запросе передаётся только api key, параметры например usrid и сигнатура (хэш). Причём для формирования хэша используется именно секретный ключ, который известен только отправителю и получателю.
Это позволяет предотвратить подмену запросов, так как принимающая сторона может сверить хэш, и в случае чего понять что данные запроса были изменены.

Такой подход часто используется при интеграции с платёжными системами, где после успешного совершения платежа, платёжная система посылает запрос (postback, webhook) на сайт магазина, уведомляя что такой-то платёж успешно завершён.
Например такое уведомление включает в себя параметры order_id, sum, status. Если злоумышленник узнает url на сайте, куда нужно передать параметры, то сможет подделать уведомление от платёжной системы. Тут и вступает в игру механизм для подсчёта контрольной суммы, например md5(order_id, sum, secret_key), и так как secret_key неизвестен злоумышленнику, то подделать такой запрос не удастся.

Comments

[WorldofMine]

Вот Вы говорите, что: "В запросе передаётся только api key, параметры например usrid и сигнатура (хэш). Причём для формирования хэша используется именно секретный ключ, который известен только отправителю и получателю.
Это позволяет предотвратить подмену запросов, так как принимающая сторона может сверить хэш, и в случае чего понять что данные запроса были изменены."
Что мешает злоумышленнику отправить тот же api key, параметры например usrid и сигнатура (хэш), на сервере где будет проходить проверка, он же пройдет проверку сигнатуры. Что в этом случае?

[nokimaro]

WorldofMine, ничего не помешает.
Сервер в любом случае должен иметь логику по работе с повторами одних и тех же запросов. При этом злоумышленник не сможет отправить другой запрос, поменяв один из параметров, так как в таком случае хэш не совпадёт.
В простейшем случае, у каждого запроса может быть уникальный идентификатор, например request_id который является одним из параметров при вычислении хэша. Соотв-но сервер после обработки запроса с указанным request_id повторные будет отклонять.

[nokimaro]

WorldofMine, например запрос вида "начисление request_id=123, пользователю user_id=1, сумму денег sum=100"

имеем

request_id=123&user_id=1&sum=100&api_key=...
&
sign = md5(request_id, user_id, sum, secret_key)

не зная secret_key который идёт в паре к передаваемому открыто api_key невозможно подделать такой запрос, так как изменение хоть одного из параметров приведёт к тому что принимающая сторона отклонит запрос из-за невалидного sign

[nokimaro]

WorldofMine, стоит понимать это как "цифровая подпись данных" которая служит для того чтобы гарантировать аутентичность запроса, и защитить от его модификации третьей стороной.
Например похожий механизм использует в vk open api https://vk.com/dev/openapi_2