Шифрование Querystring в sql-сервере

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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