Як працюють ключі API та секретні ключі? Чи буде це безпечно, якщо я повинен передати свій API та секретні ключі до іншої програми?


136

Я тільки починаю думати про те, як працюють ключі api та секретні ключі. Буквально 2 дні тому я зареєструвався на Amazon S3 і встановив плагін S3Fox . Вони попросили мене як ключ доступу, так і секретний ключ доступу, обидва з яких вимагають від мене входу для доступу.

Тож мені цікаво, якщо вони запитують у мене секретний ключ, вони повинні зберігати його десь правильно? Хіба це не те саме, що запитати мене про номери моїх кредитних карт або пароль і зберігати їх у власній базі даних?

Як повинні працювати секретні ключі та клавіші api? Наскільки секретними вони повинні бути? Ці програми, які використовують секретні ключі, зберігають його якось?

Відповіді:


90

В основному, детальніше описуючи те, що тут викладено .

Ось як це працює: скажімо, у нас є функція, яка приймає число від нуля до дев'яти, додає три і, якщо результат більший за десять, віднімає десять. Тож f (2) = 5, f (8) = 1 і т. Д. Тепер ми можемо зробити ще одну функцію, назвемо її f ', яка йде назад, додавши сім замість трьох. f '(5) = 2, f' (1) = 8 і т.д.

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

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

Функція HMAC будується на встановлених хеш-функціях, щоб використовувати відомий ключ для аутентифікації рядка тексту. Це працює так:

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

Різниця між цим та PKI полягає в тому, що цей метод є RESTful , що дозволяє мінімальну кількість обмінів між вашою системою та серверами Amazon.

Хіба це не те саме, що запитати мене про номери моїх кредитних карт або пароль і зберігати їх у власній базі даних?

Так, хоча шкода, яку хтось може завдати S3, здається, обмежується виведенням вашого рахунку.

Наскільки секретними вони повинні бути? Ці програми, які використовують секретні ключі, зберігають його якось?

У якийсь момент вам доведеться завантажити секретний ключ, і в більшості систем на базі Unix, якщо зловмисник може отримати root-доступ, він може отримати ключ. Якщо ви шифруєте ключ, у вас повинен бути код, щоб розшифрувати його, і в якийсь момент код розшифровки повинен бути простим текстом, щоб його можна було виконати. Це та сама проблема, якою володіє DRM, за винятком того, що ви володієте комп'ютером.

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


14
"Введення та застосування односторонньої функції називається" хешуванняванням "вводу, а те, що Amazon зберігає у їхній системі, є" хеш "вашого секретного ключа" - Якщо Amazon зберігає HASH вашого секретного ключа, як це Чи можливо Амазонці ЗМОВИТИ текст, надісланий їм?
Франклін

21
Спочатку ви говорите, "що Amazon зберігає у їхній системі, це" хеш "вашого секретного ключа", а потім "Amazon шукає свою копію секретного ключа". Вони ніби суперечать один одному. Я вважаю, що перше твердження є неправильним.
Шон

3
Ця URL-адреса розповідає більше подробиць про реалізацію програми Amazon S3 Auth - docs.aws.amazon.com/AmazonS3/latest/dev/S3_Authentication2.html
asyncwait

10
"Теоретично будь-які математичні функції, які відображають одне на інше, можуть бути повернені" - Це неправда, приклад хеш-функцій. це дуже легко показати. Скажімо, у нас є функція, яка перетворює слова в цифри на основі суми значень (a = 1, b = 2, c = 3 тощо). Наприклад, "ТАК" було б 18 + 14 = 32. Отже, ми змінили SO на 32, але якщо я розкрию цю функцію комусь і дам йому число 32, то немає ніякого способу він знати, чи було основним нашим словом "SO" або "ZF" (26 + 6) або одна з десятків інших можливостей
Лев

1
Згідно з документом, з яким пов'язується @asyncwait, Amazon безумовно зберігає ваш секретний ключ, а не лише його хеш. Насправді, схоже, що єдине хешування відбувається - це все, що відбувається всередині функції HMAC
1818

7

Криптографія відкритого ключа використовується для захисту від дуже специфічних атак, деякі з яких є загальними. Коротше кажучи, це складна математика, яка дозволяє перевірити, що у людини є пара "Публічний та приватний ключі", знаючи лише відкритий ключ. Це дуже відрізняється від кредитної картки або статичного пароля. Наприклад, якщо ви автентифікуєтесь із сервером OpenSSH, сервер не потребує приватного ключа .

В ідеалі, якщо в базі даних API Amazon, де можна поставити під загрозу, зловмисник матиме список відкритих ключів і не зможе отримати доступ до API користувача, використовуючи цю інформацію. Однак ідеальні системи не завжди застосовуються на практиці, і я точно не знаю, чи захищає Amazon від цього вектора нападу, але вони повинні бути.

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


2
не потрібен закритий ключ посилання зламана в даний час.
сетзамора

@Joset оновив посилання, вказуючи на копію в Інтернет-зворотній машині з 2008 року
oligofren

1

AWS розробила власний власний алгоритм аутентифікації. v4 було випущено в 2014 році. Деталі викладені тут: Запити на аутентифікацію (AWS Signature Version 4) . Важливим моментом є те, що запит підписується не самим секретом, а ключем підпису, який генерується за допомогою секрету. Він також використовує HMAC-SHA256 для підписання.

Генерація підписів

Використання асиметричних ключів було б більш безпечним, оскільки AWS зберігатиме відкритий ключ замість секретного, який зберігається і користувачем, і AWS.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.