Зачем использовать ключ API и секрет?
Я столкнулся со многими API, которые дают пользователю как API ключ и секрет. Но мой вопрос: в чем разница между тем и другим?
в моих глазах одного ключа может быть достаточно. Скажем, у меня есть ключ, и только я и сервер это знаем. Я создаю хэш HMAC с этим ключом и выполняю вызов API. На сервере мы снова создаем хэш HMAC и сравниваем его с отправленным хэшем. Если это то же самое, вызов аутентифицируется.
Так зачем использовать два ключи?
изменить: или этот ключ API используется для поиска секрета API?
4 ответов
криптография секретного ключа полагается на использование того же ключа для кодирования, а затем декодирования сообщения. Таким образом, только те, кто знает "секрет", могут прочитать сообщение.
безопасность RSA основана на 2 совпадающих ключах. Есть открытый ключ для каждого пользователя, и каждый может (должна) это знать. Есть также закрытый ключ, который должен знать только пользователь. Сообщение, зашифрованное открытым ключом, может быть расшифровано только закрытым ключом, и наоборот.
таким образом, если я хочу отправить Вы сообщение, которое только вы можете прочитать, я получаю (из сети) Ваш открытый ключ, зашифровать сообщение с этим ключом, и вы единственный человек, который может расшифровать его.
или, если я хочу доказать вам, что я отправил сообщение, я могу зашифровать сообщение своим закрытым ключом, рассказать вам (в открытом тексте или в другом сообщении), Как оно было зашифровано. Затем вы можете расшифровать сообщение с помощью моего открытого ключа, и если оно станет читаемым, вы знаете, что оно пришло от меня.
эта форма шифрования довольно компьютерный, поэтому иногда делается шифрование одноразового "секретного ключа" с помощью технологии RSA, затем шифрование остальной части сообщения с помощью секретного ключа, а затем шифрование моей подписи вторым способом. Затем вы обращаете этот процесс вспять, так что если сообщение и подпись читаемы, вы и только вы можете прочитать его, и вы уверены, что я отправил сообщение.
или
вы можете посетить эту ссылку для более подробного объяснения.
вам нужны два отдельных ключа, один, который говорит им, кто вы, а другой, который доказывает, что вы тот, кто вы говорите, что вы.
"ключ" - это Ваш идентификатор пользователя, а" секрет " - ваш пароль. Они просто используют термины" ключ "и" секрет", потому что именно так они его реализовали.
простой ответ, если я правильно понял...
Если вы используете свой ключ API для шифрования, как служба узнает, кто с ними связывается? Как они расшифруют это сообщение?
вы используете ключ API, чтобы указать, кто вы, это то, что вы отправляете в обычном тексте. Секретный ключ ты не отправлять кому угодно. Вы просто используете его для шифрования. Затем вы отправляете зашифрованное сообщение. Вы не отправляете ключ, который использовался для шифрования, что бы победить цель.
есть ответы, объясняющие, что такое секретный и (открытый) ключ. Это пара открытого и закрытого ключей, которым они дают запутанные имена. Но никто не говорит, Почему Апис требует и того, и другого, и многие Апис дают вам только один секрет! Я также никогда не видел, чтобы документы API объясняли, почему у них есть два ключа, поэтому лучшее, что я могу сделать, это спекулировать...
лучше всего поместить только ваш открытый ключ в ваш запрос и подписать запрос локально с вашим закрытым ключом; отправка ничего больше не потребуется. Но некоторые уйти с просто секрет в запросе. Хорошо, любой хороший API будет использовать некоторую транспортную безопасность, такую как TLS (обычно через HTTPS). Но вы все еще подвергаете свой закрытый ключ серверу таким образом, увеличивая риск того, что они каким-то образом неправильно его обрабатывают (см.: недавно обнаруженная ошибка регистрации паролей GitHub и Twitter). И HTTPS теоретически так же безопасен,но всегда есть недостатки реализации.
но многие-на самом деле большинство кажется-Апис у вас отправить оба ключа в запросах, так как это проще, чем заставить людей делать свои собственные подписи; иначе не может быть чистых примеров cURL! В таком случае бессмысленно разделять их. Я думаю, что отдельные ключи просто на случай, если они изменят API позже, чтобы воспользоваться ими. Или у некоторых есть клиентская библиотека, которая может сделать это более безопасным способом.