Подписывание http-запросов

Question

[ChemAli]

Есть некое API для мобильных приложений, которое нужно защитить. Хочется подписывать запросы чтобы при обращении к бэкенду отбрасывать неподписанные запросы или запросы от заблокированных клиентов.

Есть ли готовые практики, кейсы для таких задач?

Сейчас вырисовывается следующая схема, но мне в силу особенностей мышления сложно оценить ее достаточность:

Приложение при первом обращении к бэкенду получает api-key. Кроме того, в приложение зашита строка secret, которую знает только клиент и бэкенд и которая не передается между ними.

После получения api-key приложение подписывает каждый запрос строкой, сгенерированной на основе api-key + secret + что-то еще.

sign = hmac-sha1( api-key + secret + md5(request data) )

То есть в запросе передается api-key (по нему идентифицируется устройство/юзер) и sign. Бэкенд, зная sign и secret, может проверить подпись на валидность.

Этого достаточно или полный фуфел? Может, достаточно просто устанавливать соединение по HTTPS и всё?

Answer 1

[stnw]

Я у себя использовал похожее решение, только добавил еще дату создания:
ApiKey=«iphone_key», Signature=«a048d4fb029cc191874ebb787893e708», Created=«2013-08-28T17:43:09+04:00»
По дате создания можно отсекать устаревшие запросы (например, которые были созданы раньше чем 5 минут назад). Иначе, перехватив запрос его можно использовать хоть через год.
Ну и все важные операции (биллинг, пароли) конечно через https.

Comments

[Павел Тысляцкий]

Я еще в качестве basestring беру сжатую JSON строку запроса с отсортированными и используемыми для подписи ключами (sign не входит), тк я не беру изначально хеш от данных и есть вероятность, что для param_1 и param_2 существует такие param_3 и param_4, при которых param_1 + param_2 == param_3 + param_4, а у меня видимо паранойя. В PayU, например берутся подписываемые параметры и собираются как len(param_1) + param_1 + len(param_2) + param_2 + ....

JSON, тк данные изначально у меня передаются как JSON ввиду их сложной структуры. К тому же это хорошо ложится на json-schema для валидации.

[stnw]

tbicr, я думаю, что автор это делает здесь: md5(request data)

Answer 2

[deadkrolik]

Защиты не существует. Всегда можно взломать apk или ipa и подсмотреть что там к чему. Мы тоже сделали подписывания и https, но это скорее от тех, кто захочет нас раскусить за пять минут. Кому надо — вскроет. Мы к этому готовы.

OAuth тут вообще ни о чем.

Answer 3

[Sergey Belov]

Соль слева - дело плохо :)
Могу подписать любой запрос, не зная ключа с помощью length extension attack.

Answer 4

[Назар Мокринский]

Можете почитать стандарт OAuth 2.0 RFC 6749.
Там, к стати, написано, что секрет хранить на клиенте нельзя, он используется для северного взаимодействия.

Answer 5

[KEKSOV]

Было у меня похожее решение — все AJAX запросы шифровались blowfish при помощи пароля пользователя, который он указывал при логине

Answer 6

[Sergey]

Если нет противопоказаний против HTTPS с взаимной аутентификацией, то это самый правильный вариант.
Когда любители (с точки зрения криптографии) начинают изобретать велосипед — к добру это обычно не приводит.