Как сделать секретный ключ API?

Question

[Оптимус Пьян]

Исходные данные:
API доступно только зарегистрированным пользователям.
После регистрации юзеру выдаётся id и секретный ключ на основе хэша каких-то данных.
Юзер должен сохранить ключ в тайне и не сообщать его третьим лицам, т.к. при каждом запросе со счёта списывается денежка.

Вопрос: есть ли необходимость ограничивать метод отправки ключа (например не принимать GET-запросы а отдавать только при POST-запросах)?
Или же для безопасности ограничить домен с которого могут идти запросы (можно обойти)?
Или делать двухступенчатый API как в ВК когда запрос с открытым id идёт на один адрес, а ответ приходит на другой заранее заданный в системе и с этого второго адреса уже посылается секретный ключ?

Или на всё забить и сделать по простому а юзер пусть сам бдит свой ключ?

Answer 1

[Melkij]

Сделайте ограничение по IP. С возможностью указать несколько сетей. Просто, стандартно, привычно.
Для прозрачности - давайте подробный лог, мол по вашему ключу было столько-то таких-то запросов с такого IP-адреса. По идее градации день-IP-запрошенное действие-количество запросов будет достаточно чтобы и лог не раздувать сверх меры и давать подробную статистику пользователю. Если токенов может быть несколько - то дополнительно по токену счётчик
Не забудьте дать пользователю кнопку "ааа, срочно инвалидируйте мой токен!"

Comments

[Оптимус Пьян]

1) ip бывает динамический, а хочется например оставить для людей возможность делать запросы из прикладных программ именно поэтому не хочу по варианту VK дти
2) На хостинге на одном ip может находится очень много сайтов, т.е. защита скажем прямо не ахти...

[Melkij]

1) поэтому возможность отказаться от фильтра по ip.
2) ну а по домену вы в принципе не ограничите. Нет такого поля в L3. Только в варианте с callback'ом, который весьма сложнее для реализации клиента.

Answer 2

[Дмитрий Энтелис]

Imho программа минимум:
а) принудительно использовать https
b) передавать запрос в теле POST, а не в url.
c) не передавать секретный ключ, а передавать хеш от (данные запроса + секретный ключ).
Все остальное опционально по желанию.

Comments

[Оптимус Пьян]

Можно третий пункт пояснить. Данные запроса постоянно разные, я не могу их захэшировать. Хэш-же обратной расшифровки не имеет, как я потом пойму что мне передали?

[jacksparrow]

Запрос в теле пост, а не юрл защищает от возможности скопировать ключ делясь ссылкой?

[Оптимус Пьян]

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

[Дмитрий Энтелис]

jacksparrow: запрос в теле пост при наличии https исключает возможность атаки man in the middle. Если запросы к API предполагаются с мобильных приложений например - это весьма актуально.

[Дмитрий Энтелис]

Дмитрий: Допустим есть пользователь 1 и секретный ключ со значением qwerty.
Пользователь делает запрос в апи, передавая туда явно аргументы запроса, и хеш на основе секретного ключа и аргументов. На сервере на основе user_id, аргументов и значения секретного ключа из базы - строится заново хеш и проверяется с присланным.
По факту это означает что секретный ключ не передается от клиента к API вообще никогда, так что даже в случае компрометации запроса - делать другие запросы от клиента к API не получится.
А если к формуле расчета хеша добавить еще и формулу на основе времени например - получается вообще хорошо

[Оптимус Пьян]

Дмитрий Энтелис: А да, точно я же по id узнаю оригинал ключа, захэширую, сравню. Спасибо за наводку. Люблю когда ваш ответ появляется в вопросе, это знак "к удачному решению проблемы" называется ))) Правда https у меня пока нет...