Зачем использовать ключ и секрет API?

Криптография с секретным ключом основана на использовании одного и того же ключа для кодирования и последующего декодирования сообщения. Таким образом, только те, кто знает секрет, могут прочитать сообщение.

Безопасность RSA основана на 2 совпадающих ключах. У каждого пользователя есть открытый ключ, и каждый может (должен) его знать. Также существует закрытый ключ, который должен знать только пользователь. Сообщение, зашифрованное открытым ключом, может быть расшифровано только закрытым ключом, и наоборот.

Таким образом, если я хочу отправить вам сообщение, которое можете прочитать только вы, я получаю (из сети) ваш открытый ключ, шифрую сообщение этим ключом, и вы единственный человек, который может его расшифровать.

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

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

OR

вы можете посетить эту ссылку для более подробного объяснения.

Как работают ключи API и секретные ключи?

Вам понадобятся два отдельных ключа: один, который сообщает им, кто вы, а другой, доказывает, что вы такой, какой вы себя называете.

«Ключ» - это ваш идентификатор пользователя, а «секрет» - это ваш пароль. Они просто используют термины «ключ» и «секрет», потому что именно так они это реализовали.

Простой ответ, если я правильно понял ...

Если вы используете свой ключ API для шифрования, как служба узнает, кто с ними обращается? Как они расшифруют это сообщение?

Вы используете ключ API, чтобы указать, кто вы, это то, что вы отправляете в виде обычного текста. СЕКРЕТНЫЙ ключ, который вы никому не отправляете. Вы просто используете его для шифрования. Затем вы отправляете зашифрованное сообщение. Вы не отправляете ключ, который использовался для шифрования, это нарушило бы цель.

Есть ответы, объясняющие, что такое секретный и (открытый) ключ. Это пара открытого и закрытого ключей, которой они дают запутанные имена. Но никто не говорит, почему API требуют и того, и другого, а многие API дают вам только один секрет! Я также никогда не видел, чтобы документы API объясняли, почему у них два ключа, поэтому лучшее, что я могу сделать, это предположить ...

Лучше всего указать в запросе только свой открытый ключ и подписать его локально своим закрытым ключом; посылать больше ничего не нужно. Но некоторым удается просто раскрыть секрет в запросе. Хорошо, любой хороший API будет использовать некоторую транспортную безопасность, такую ​​как TLS (обычно через HTTPS). Но вы по-прежнему предоставляете свой закрытый ключ серверу таким образом, увеличивая риск того, что он каким-то образом неправильно его обработает (см. Недавно обнаруженная ошибка регистрации паролей в GitHub и Twitter). И HTTPS теоретически так же безопасен, но всегда есть недостатки в реализации.

Но во многих - на самом деле, кажется, в большинстве - API вы отправляете оба ключа в запросах, поскольку это проще, чем заставлять людей делать свои собственные подписи; иначе не может быть чистых примеров cURL! В таком случае бессмысленно разделять их. Я предполагаю, что отдельные ключи предназначены только на тот случай, если они позже изменят API, чтобы воспользоваться ими. Или у некоторых есть клиентская библиотека, которая может сделать это более безопасным способом.

Одна вещь, о которой я не упоминал здесь, хотя это расширение ответа Маркуса Адамса, заключается в том, что вы не должны использовать одну часть информации как для идентификации, так и для аутентификации пользователя, если существует возможность атаки по времени, которые могут использовать разницу во времени ответа, чтобы угадать, насколько далеко продвинулось сравнение строк.

Если вы используете систему, которая использует «ключ» для поиска пользователя или учетных данных, эту информацию можно постепенно угадывать с течением времени, отправляя тысячи запросов и проверяя время, которое требуется вашей базе данных, чтобы найти (или нет найти) запись. Это особенно верно, если «ключ» хранится в виде открытого текста вместо одностороннего хеширования ключа. Вы хотели бы хранить ключи пользователей в виде открытого текста или симметрично зашифрованные, если вам нужно снова отобразить ключ пользователю.

Имея вторую часть информации или «секрет», вы можете сначала найти пользователя или учетные данные с помощью «ключа», который может быть уязвим для временной атаки, а затем использовать безопасную по времени функцию сравнения, чтобы проверить значение секрет".

Вот реализация этой функции в Python:

https://github.com/python/cpython/blob/cd8295ff758891f21084a6a5ad3403d35dda38f7/Modules/_operator.c#L727

И он представлен в hmac lib (и, возможно, в других):

https://docs.python.org/3/library/hmac.html#hmac.compare_digest

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

Тогда решениями для хранения ключей API будут:

1. Используйте отдельный ключ и секрет, используйте ключ для поиска записи и используйте безопасное по времени сравнение, чтобы проверить секрет. Это позволяет вам снова показать пользователю ключ и секрет.
2. Используйте отдельный ключ и секрет, используйте симметричное детерминированное шифрование секрета и выполните обычное сравнение зашифрованных секретов. Это позволяет вам снова показать пользователю ключ и секрет и избавить вас от необходимости выполнять безопасное по времени сравнение.
3. Используйте отдельный ключ и секрет, отобразите секрет, хэш и сохраните его, а затем выполните обычное сравнение хешированного секрета. Это избавляет от необходимости использовать двустороннее шифрование и дает дополнительное преимущество в виде сохранения секрета в безопасности в случае взлома системы. У него есть обратная сторона: вы не можете снова показать секрет пользователю.
4. Используйте единый ключ, покажите его пользователю один раз, хешируйте его, а затем выполните обычный поиск хешированного или зашифрованного ключа. Здесь используется один ключ, но он не может быть снова показан пользователю. Имеет преимущество хранения ключей в безопасности, если система скомпрометирована.
5. Используйте единый ключ, покажите его пользователю один раз, зашифруйте его и выполните обычный поиск зашифрованного секрета. Может быть снова показан пользователю, но за счет уязвимости ключей в случае взлома системы.

Из них я считаю, что 3 - лучший баланс безопасности и удобства. Я видел, как это реализовано на многих веб-сайтах при выдаче ключей.

Кроме того, я приглашаю любых реальных экспертов по безопасности критиковать этот ответ. Я просто хотел вынести это как еще одну тему для обсуждения.