HmacSHA1 генерирует разные подписи в разных системах, используя один и тот же секрет - PullRequest
Новая
       33

HmacSHA1 генерирует разные подписи в разных системах, используя один и тот же секрет

0 голосов
/ 17 июня 2011

У меня есть провайдер джерси oauth, который использует HmacSHA1 для подписи / проверки запросов.Это работает для моих платформ разработки и тестирования, где клиент и сервер - это разные физические системы.Однако, когда я перехожу на производственную платформу, алгоритм HmacSHA1 (на стороне поставщика) возвращает другое значение, чем алгоритм HmacSHA1 (на стороне клиента), используя те же параметры и секрет, и моя проверка oauth не выполняется.

JDK (1.6.x) является одинаковой точной версией как для провайдера, так и для клиента для всех платформ.

Когда я переключил моего oauth-провайдера и клиента на использование метода подписи PLAINTEXT (плохой)для безопасности, я знаю), это работает на всех платформах.

Когда я копаюсь в методе OAuthSignature.verify () Джерси, он вызывает функцию проверки метода подписи (HmacSHA1 или PLAINTEXT), которая просто подписывает oauthэлементы с секретом и сравнивает значение с переданной в нем подписью.

Для HmacSHA1 метод вызывает метод Base64.encode () для генерации подписи, но для PLAINTEXT кодирование не выполняется (как и ожидалось).

Что может быть причиной того, что метод Base64.encode (), использующий алгоритм подписи HmacSHA1, имел разные результаты при использовании одинаковых параметров и секрета в обеих системах?

Заранее спасибо!--TK

1 Ответ

1 голос
/ 17 июня 2011

Одно обоснованное предположение: если кодировки платформ различаются (довольно часто; некоторые платформы используют ISO-8859-1, другие UTF-8, Windows может быть CP-1250 или что-то еще, и в рассматриваемой библиотеке OAuth есть ошибки новичка, где кодировка не указанапри преобразовании между byte [] и String, AND есть символы, которые по-разному кодируются в разных кодировках (обычно все, кроме 7-битного диапазона ASCII, символы 0–127), и в результате вы получите разные подписи.

Итак, вы можете увидеть, что представляет собой кодировка платформы по умолчанию, и сначала заставить ее быть одинаковой для обоих. Если это решит проблему, я бы посчитал сообщить об этом как об ошибке автору OAuth lib (или инфраструктуре, которая его связывает)) или, по крайней мере, спросите в списках рассылки.

Я видел такие ошибки (String.getBytes ("test")) ОЧЕНЬ часто - это один из самых распространенных в мире анти-паттернов Java. Худшая частьв том, что это ошибка, которая вызывает проблемы только при определенных обстоятельствах, поэтому люди не настолько сильно кусаются, чтобы их исправить.

AnothВозможная проблема связана с кодировкой URL - обработка некоторых символов (пробел,%, +) может отличаться в разных реализациях из-за незначительных ошибок в кодировании / декодировании.Таким образом, вы можете видеть, содержит ли передаваемый контент «специальные» символы;попытайтесь выяснить, имеет ли значение их устранение (для тестирования), и ноль в том, что вызывает разницу.

...