Жорстка відмова в withdraw-активованих API ключах: технічна глибина

Більшість торгових платформ приймають API ключи з увімкненою дозволу на виведення. Вони показують жовтий банер попередження, просять вас набрати «Я розумію» і все одно зберігають ключ. Ми цього не робимо. Якщо ваш ключ має дозвіл на виведення, ми відхиляємо його при реєстрації і ніколи його не зберігаємо. Цей пост пояснює чому, як, та яку вартість насправді має альтернатива.

Модель загрози в одному абзаці

Будь-яка система, що зберігає API ключ з увімкненою дозволою на виведення, знаходиться на відстані однієї витоку облікових даних від спорожніння рахунків користувачів. Витік не обов'язково повинен бути порушенням бази даних — це може бути скомпрометований ноутбук працівника, неправильно налаштована резервна копія, побічний канал у сторонній залежності або дамп процесної пам'яті в незашифрованому журналі. Кожне з цього траплялося компаніям більшим, ніж ми. Єдиний стійкий захист: не мати ключі до чужих коштів на першому місці.

Як працює виявлення

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

• Спеціалізований endpoint «запит інформації про API ключ», який повертає набір дозволів як структуроване поле, або
• Endpoint інформації про акаунт, де область дозволів ключа включена як частина корисного навантаження відповіді.

Ми шукаємо будь-який прапор, який надає виведення, внутрішнього перекладу, виведення з під-акаунту або універсального виведення — майданчики використовують різні назви для однієї ідеї. Якщо будь-який з них присутній, ми негайно відкидаємо секрет у пам'яті, повертаємо структуровану помилку в UI і ніколи не записуємо ключ у нашу базу даних.

Чому жорстка відмова замість попередження

Попередження натискають. Ми спостерігали за даними з цього протягом років у кількох продуктах. Базова ставка користувачів, які набирають «Я розумію» без читання хоча б одного слова вище, становить понад 80%. Попередження, яке 80% користувачів ігнорує, — це не засіб безпеки; це щит від відповідальності.

Жорстка відмова — протилежність. Вона розміщує тертя в правильному місці: користувач повертається на біржу, створює новий ключ тільки з дозволом на торгівлю, повертається назад і вставляє цей. Весь цикл коштує користувачу, можливо, дві хвилини. Це коштує зловмиснику — у гіршому сценарії витоку облікових даних — весь акаунт.

Яку вартість насправді має шлях warn-instead-of-reject

Паттерн warn-and-store виглядає дружнім до користувача, поки ви не запитаєте: що виглядає найгірше? Ви отримуєте одного ворожого працівника, один компромісний ланцюг поставок, один побічний канал у трансзитивній залежності, один неправильно визначений журнал, і відповідь полягає в тому, що withdraw-активовані ключи являють собою рівно ту ж саму загрозу, що й найслабша людина та найслабший фрагмент коду, який їх коли-либо торкався.

Жорстка відмова змінює цей розрахунок. Навіть у найгіршому випадку повного компромісу бази даних зловмисник йде з ключами read+trade. Ключі тільки для торгівлі можуть завдати шкоди — вони можуть закрити позиції, змінити комісії, скинути відкриті позиції в неліквідні пари — але вони не можуть виводити. Кошти залишаються на біржі. Це не нульовий ризик, але це ризик, на який ви погодилися, коли підключили автоматизованого торгового агента.

Від чого ми все ще не можемо захищати

Ми не претендуємо на те, що жорстка відмова — це повна безпека. Це один контроль. Повний набір задокументований на нашій сторінці безпеки: шифрування конверту KMS з ключами даних для кожного користувача, розшифровані секрети, які живуть тільки в пам'яті процесу і тільки протягом тривалості виклику API, журнал аудиту, з'єднаний хеш-ланцюгом лише для додавання, протестований в CI кросс-користувацької ізоляції та програма розкриття вразливостей. Жорстке відхилення дозволу на виведення — це просто найбільш видимий фрагмент цього стека — і найлегший для перевірки, оскільки ви можете спостерігати, як ми відхиляємо withdraw-активований ключ в реальному часі під час реєстрації.