Я реализую сторону поставщика двухстороннего протокола OAuth для аутентификации API. Мы предоставим потребителю ключ и секрет потребителя, которые они будут использовать для подписания запросов. Двусторонняя OAuth продиктована стандартом взаимодействия и, следовательно, требованием.
Секрет в некотором роде похож на пароль, и я никогда не буду хранить пароль в виде простого текста (bCrypt или аналогичный мой обычный выбор). Но поскольку моему провайдеру необходим доступ к секретному тексту для проверки подписи, он должен быть в некотором текстовом или обратимом виде.
Я рассмотрел следующие варианты:
Хранить секрет в виде простого текста
Это наиболее очевидное решение, но если база данных каким-то образом скомпрометирована, то все секреты придется изменить. Для меня это решение не является идеальным, потому что оно имеет все проблемы хранения пароля в виде простого текста.
Применение обратимого шифрования (например, AES) с ключом шифрования, хранящимся в другом месте
Это обеспечит некоторую безопасность, потому что, если база данных взломана, секреты все равно будут в безопасности. Но для обратимого шифрования требуется ключ шифрования, и ключ должен храниться на сервере. Это означает, что если злоумышленник скомпрометирует компьютер, шифрование можно обойти.
Есть что-то, о чем я не подумал?
Разъяснение Эффективно используется двухсторонний Oauth в качестве системы единого входа. «Потребитель» создает запрос, включающий ключ потребителя, одноразовый номер и несколько других параметров. Затем весь запрос подписывается путем вычисления HMAC-SHA1 с секретом потребителя. Когда запрос достигает нашей системы провайдера, процесс повторяется, и если подписи совпадают, тогда обработка запроса продолжается. Поэтому нам необходим секрет в виде простого текста для вычисления подписи HMAC-SHA1 и на нашей стороне. К сожалению, этот механизм продиктован стандартным протоколом, который мы должны соблюдать.