Навіщо використовувати ключ та секрет API?

Я натрапив на багато API, які надають користувачеві як ключ API, так і a секрет . Але моє запитання: яка різниця між ними?

На мій погляд, одного ключа може бути достатньо. Скажімо, у мене є ключ, і це знаю лише я та сервер. Я створюю хеш 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

І це виставляється в hmaclib (і, можливо, інших):

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

Тут слід зауважити одне, що я не думаю, що такий вид атаки буде працювати на значення, які хешуються або шифруються перед пошуком, оскільки значення, які порівнюються, змінюються випадковим чином щоразу, коли змінюється символ у вхідному рядку. Я знайшов гарне пояснення цього тут .

Тоді рішеннями для зберігання ключів API будуть:

1. Використовуйте окремий ключ і секрет, використовуйте ключ, щоб шукати запис, і використовуйте безпечне порівняння часу, щоб перевірити секрет. Це дозволяє вам знову показати користувачеві ключ і секрет для користувача.
2. Використовуйте окремий ключ і секрет, використовуйте симетричне, детерміноване шифрування секрету та виконуйте звичайне порівняння зашифрованих секретів. Це дозволяє вам знову показати користувачеві ключ і секрет, і це може позбавити вас від необхідності впроваджувати порівняння, безпечне за часом.
3. Використовуйте окремий ключ і секрет, відображайте секрет, хеш і зберігайте його, а потім виконайте звичайне порівняння хешованого секрету. Це позбавляє від необхідності використовувати двостороннє шифрування та додає додаткову перевагу збереження вашої таємниці в безпеці, якщо система порушена. Він має мінус у тому, що ви не можете повторно показати секрет користувачеві.
4. Використовуйте один ключ , один раз покажіть його користувачеві, хеш, а потім виконайте звичайний пошук хешованого або зашифрованого ключа. Тут використовується один ключ, але він не може бути показаний користувачеві знову. Має перевагу захищати ключі, якщо система порушена.
5. Використовуйте один ключ , один раз покажіть його користувачеві, зашифруйте його та виконайте звичайний пошук зашифрованого секрету. Може бути показаний користувачеві ще раз, але ціною того, що ключі є вразливими, якщо їх система порушена.

З них, я вважаю, що 3 - найкращий баланс безпеки та зручності. Я бачив це на багатьох веб-сайтах під час отримання ключів.

Крім того, я запрошую будь-яких фактичних експертів з питань безпеки критикувати цю відповідь. Я просто хотів винести це там як черговий пункт обговорення.