Разница между шифрованием и хэшированием - PullRequest
9 голосов
/ 21 июня 2010

В нашем проекте есть несколько мест, где мы могли бы избежать хэширования. Например, мы храним зашифрованную ссылку между лицензией и лицензированным объектом в базе данных вместе с незашифрованной ссылкой. Это сделано для того, чтобы пользователь не мог изменить объект, на который он получил лицензию, путем взлома базы данных.

Основная причина, по которой мы используем шифрование везде, в том, что у нас уже была хорошая библиотека шифрования и системный ключ. Похоже, что на самом деле не стоило тратить время на разработку библиотеки хеширования.

Существует ли какая-либо угроза безопасности, которую мы создаем, используя шифрование вместо хеширования?

Ответы [ 6 ]

7 голосов
/ 21 июня 2010

Сохраняя обычный текст вместе с зашифрованным текстом, вы создаете хороший репозиторий тестовых строк, если кто-то захочет узнать ваш ключ.Поскольку вы, очевидно, используете указанный ключ для шифрования всего , я бы сказал, что - это риск.

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

4 голосов
/ 21 июня 2010

Если вы используете симметричный шифр, и система развернута в «враждебной» среде, то вопрос времени, когда мотивированный человек сможет изолировать ключ и подписать свои (или другие) данные лицензии .

В этих случаях вам нужен ассиметричный шифр, чтобы «подписать» лицензию вашим закрытым ключом, который надежно хранится на компьютере в хранилище и не имеет связи с внешним миром. Хорошо, небольшое преувеличение, но в безопасной обстановке.

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

1 голос
/ 21 июня 2010

Из того, что я понимаю, вы хотите добиться целостности ваших данных (т.е. вы хотите добиться того, чтобы никто не мог изменить ваши данные незамеченными). Это может быть достигнуто путем использования цифровой подписи (например, RSA, DSA) или MAC (код аутентификации сообщения). Mac - это симметричный эквивалент цифровой подписи, которая обычно является асимметричной схемой.

Так что в вашем случае MAC (как, например, HMAC) должен быть хорошим выбором!

1 голос
/ 21 июня 2010

Любые данные, которые могут быть зашифрованы, также могут быть расшифрованы.

Хеширование - это односторонний процесс, особенно если вы используете новые методы SHA2.

1 голос
/ 21 июня 2010

Ну, шифрование - это двусторонний процесс.Предполагая, что вы используете шифрование на основе ключей, вы в безопасности, если ключ шифрования безопасен и вы используете современный алгоритм (например, AES).Хеширование, напротив, является односторонним процессом, когда практически невозможно восстановить входные данные хеш-функции из хешированного значения.Поэтому, не имея ключа, хеширование можно считать более безопасным.Он также может быть менее требовательным к вычислительным ресурсам.

0 голосов
/ 21 июня 2010

Вы ввели секретность ключа как слабое место, я бы сказал, что это риск, хотя для оценки степени серьезности потребуется больше деталей.

С другой стороны, хеширование будет зависеть исключительно от сложности обнаружения коллизий, что, вероятно, является более безопасным сценарием, чем сохранение этого ключа в секрете.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...