@WorldofMine

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

Какой смысл в создании сигнатуры API ключа, если API ключ и так известен?
Ну например, мы создали API ключ: 1234567890, дали его человеку чтобы он им пользовался.
При запросе просто проверяем этот ключ:
if($_GET['apikey'] !== '1234567890'){
 die( 'Die Die Die' );
}
//some code


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

Допустим, человек использует сигнатуру с проверкой, приходит запрос типа: url?key=32432432&usrid=100&email@test.ru&status=update
В скрипте, проверяем эту сигнатуру так:
$siganture = sha1($key.'|'.$usrid.'|'.$email);
if($siganture !== $secret_pass) {
 die( 'Die Die Die' );
}
//some code

Получается что вторая проверка один в один что и первая где сразу сверяется ключ, но только с лишними действиями с проверкой сигнатуры.
Но если любой человек узнает строку API Запроса: url?key=32432432&usrid=100&email@test.ru&status=update, то он может отправлять что угодно, тогда спрашивается смысл такой мудренной проверки, если она не защищает, почему просто первый вариант проверки не использовать?
  • Вопрос задан
  • 140 просмотров
Пригласить эксперта
Ответы на вопрос 4
kawabanga
@kawabanga
Бью себя по рукам за каждый ответ на глупый вопрос
Чуть-чуть не изучили вопрос.

Если вы через уязвимость получите хэши паролей, вы не будете знать первоначальный пароль, верно? и не сможете его использовать в качестве ключа.
При этом вы так же не знаете, как формируется ваш хэш пароля. И в этом случае ,как минимум то, что вводит клиент - неизвестно, если вы не знаете исходный код и не внедряетесь внутрь системы. А мы то знаем, что в 95%+ пользователь использует одни и те же пароли везде. И тут мы сохраняем пароль пользователя до более серъезного взлома.
Ответ написан
pro100chel
@pro100chel
Senior Pomidor Developer | CEO of GOVNOKOD LTD.
Чтобы в открытую не передавать по сети api ключ...
Ответ написан
Sanasol
@Sanasol Куратор тега PHP
нельзя просто так взять и загуглить ошибку
Ключ никуда не передаётся при использовании хеша.

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

Зато если отправлять как в первом варианте просто ключ - данные легко можно поменять на любые другие и серверу пофиг кто и что отправил, да и проверить он это не может даже если захочет.
Ответ написан
nokimaro
@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 неизвестен злоумышленнику, то подделать такой запрос не удастся.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы