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

Я встречал множество API, которые предоставляют пользователю как ключ API, так и секрет . Но мой вопрос: в чем разница между ними?

На мой взгляд, одного ключа может хватить. Скажем, у меня есть ключ, который знают только я и сервер. Я создаю хеш HMAC с этим ключом и выполняю вызов API. На сервере мы снова создаем хеш HMAC и сравниваем его с отправленным хешем. Если это то же самое, вызов аутентифицируется.

Так зачем использовать два ключа?

Изменить: или этот ключ API используется для поиска секрета API?

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

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

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

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

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

ИЛИ

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

Как работают ключи 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библиотеке (и, возможно, в других):

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

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

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

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

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

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