В нашем проекте есть несколько мест, где мы могли бы уйти с хешированием. Например, мы храним зашифрованную ссылку между лицензией и лицензированным объектом в базе данных вместе с незашифрованной ссылкой. Это делается для того, чтобы пользователь не мог изменить объект, который они лицензировали, удалив базу данных.
Основная причина, по которой мы везде используем шифрование, - это то, что у нас уже была хорошая библиотека шифрования и системный ключ. На самом деле, похоже, не стоит разрабатывать хеширующую библиотеку.
Есть ли риск безопасности, который мы создаем, используя шифрование вместо хеширования?
Сохраняя простой текст вместе с зашифрованным текстом, вы создаете хороший репозиторий тестовых строк, если кто-то захочет узнать ваш ключ. Поскольку вы, очевидно, используете указанный ключ для шифрования всего, что я бы сказал, это риск.
Помните, что хорошая информация о центральных базах данных заключается в том, что когда-нибудь кто-то получит данные. Если история - это какой-то урок, по крайней мере.
Если это симметричный шифр, который вы используете, а система развернута в "агрессивной" среде, то это вопрос времени, прежде чем мотивированный человек может изолировать ключ и подписать свои (или другие) данные лицензии.
В этих случаях вам понадобится ассиметричный шифр, чтобы "подписать" лицензию своим личным ключом, который безопасно хранится на компьютере в хранилище и не связан с внешним миром. Хорошо, небольшое преувеличение, но в безопасной среде.
Простой хэш не поможет в этом случае, потому что их можно использовать для подписи поддельных лицензий. Если вы хотите быть уверенным, что только вы можете одобрить изменения лицензии, то использование асимметричного шифра для шифрования лицензии (или хеша лицензии) является самым простым способом.
Ну, шифрование - это двусторонний процесс. Предполагая, что вы используете шифрование на основе ключа, вы в безопасности, если ключ шифрования безопасен, и вы используете современный алгоритм (скажем, AES). Хеширование, наоборот, является односторонним процессом, что практически невозможно восстановить хеш-вход из хешированного значения. Таким образом, не имея ключа, хеширование может считаться более безопасным. Он также может быть менее голодным.
Любые данные, которые могут быть зашифрованы, также могут быть дешифрованы.
Хеширование - это односторонний процесс, особенно если вы используете новые методы SHA2.
Насколько я понимаю, вы хотите добиться целостности ваших данных (т.е. вы хотите достичь того, что никто не может изменить, вы незаметны). Это может быть достигнуто за счет использования цифровой подписи (например, RSA, DSA) или MAC (код аутентификации сообщения). Мак является симметричным эквивалентом цифровой подписи, которая обычно является асимметричной схемой.
Итак, в вашем случае MAC (например, HMAC) должен быть хорошим выбором!
Вы ввели секретность ключа как слабый момент, я бы сказал, что это риск, хотя измерение серьезности потребует больше деталей.
Хеширование, с другой стороны, будет полагаться исключительно на трудность нахождения коллизий, что, вероятно, является более безопасным сценарием, чем сохранение этого секретного ключа.