Querystring шифрование на сервере SQL

Question

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

Маркер не должен быть уязвим к атакам типа "грубая сила".

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

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

Я попытался сгенерировать хеш-код sha1 на основе двух ключей, а затем URL-адреса безопасным base64, кодирующим результат, но поскольку это односторонняя операция, поиск на конце веб-сайта недопустимо медленен.

Я думаю, что шифрование с симметричным ключом было бы целесообразным, если шифрование происходило в базе данных, а расшифровка происходила на веб-сайте перед поиском.

На этом этапе я склоняюсь к созданию функции CLR для заполнения сгенерированного столбца в представлении.

Answer 1

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

Я использовал эту страницу как основу для тройного кода DES: http://www.dotnetspark.com/kb/1279-triple-des-encryption-and-decryption-using.aspx

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

Answer 2

Таким образом, вы хотите, чтобы база данных генерировала «токен», передавала это значение приложению (через Интернет / Интернет), и позже пользователь вернет этот токен, и база данных будет использовать его по существу как значение поиска / первичного ключа. ? И вы хотите, чтобы сгенерированные значения были такими, чтобы хакер [наш друг Мэллори] не мог (а) угадать токен для конкретной учетной записи и / или (б) угадать любой действительный токен для учетной записи?

Почему бы просто не сделать это случайным числом? Значение 4 байта дает вам 4 миллиарда значений, 8 байтов - 4 петабайта значений (2 ^ 64), и оно продолжает расти. По общему признанию, у вас есть давняя проблема генерации действительно случайного числа ( Может быть, попробуйте этих парней? ), и вам нужно измерить соотношение возможных токенов к действительным токенам в зависимости от того, сколько времени потребуется атака грубой силы угадать их, но вы получите это с любым видом безопасности.

Мой вопрос: зачем беспокоиться о хешах и шифровании, если передаваемые вами данные являются просто ключом поиска?