Моя команда и я работаем над системой API / Middleware, которая будет требовать, чтобы все запросы, сделанные на уровне middleware, подписывали запрос с открытым и закрытым ключом для безопасности. Большинство этих запросов будут отправляться с сервера на сервер, за исключением мобильных приложений, таких как приложения для iPhone и Android, которые будут напрямую запрашивать данные из промежуточного программного обеспечения.
Мы реализовали наши библиотеки сигнатур, которые очень близко отражают работу API Amazon Market, используя отсортированные строки запросов и хеширование HMAC 256 с открытыми и закрытыми ключами для генерации подписи, которая сравнивается при получении с использованием того же алгоритма.
К сожалению, мы только что узнали (немного поздно в игре), что для того, чтобы выпустить приложения iPhone через магазин приложений, вы должны соответствовать определенным государственным критериям для реализации криптографических библиотек (читается как ограничения на экспорт). Теперь мы вынуждены решить, следует ли нам переписать наши алгоритмы подписи, чтобы использовать гораздо более простой метод, такой как добавление закрытого ключа в строку запроса и SHA1 () для его хеширования для сравнения.
Я НЕНАВИЖУ использовать высокозащищенный метод и сводить его к простому хешированию закрытого ключа, но я недостаточно знаком с безопасностью и криптозащитой, чтобы знать, что я теряю в долгосрочной перспективе, отбрасывая HMAC 256. (Примечание: строка запроса уже содержит открытый ключ)
Например, в настоящее время мы заказываем нашу строку запроса и выполняем такую операцию, чтобы подписать ее:
$signature = base64_encode( hash_hmac( 'sha256', $querystring, $private_key, TRUE ) );
Если мы вынуждены не использовать класс crypto в наших приложениях, тогда наши подписи будут выглядеть так:
$signature = base64_encode( sha1( $querystring . $private_key ) );
Технически, мы можем соответствовать критериям для использования библиотеки в нашем приложении, но я не знаю, хочу ли я рисковать юридическими последствиями, если правительство США решит, что то, что мы делаем, не совсем соответствует их законным описание «аутентификации».
Любой совет от ваших гуру безопасности очень ценится! Что я теряю, используя второй пример кода, облегчает ли это взлом нашего промежуточного программного обеспечения?