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