Как создать хэш или использовать шифрование для защиты ключей в приложении asp.net mvc?

Question

РЕДАКТИРОВАТЬ 1: Я думаю, я сам не был ясен до и, следовательно, не мог сказать это лучше. Итак, я создаю систему где я предоставляю содержимое страницы другая система через IFRAMEs. Пользователь войдет в другую систему и эта система установит их apiKey и userKey в файле cookie в моей системе, так этот доступ будет предоставлен в мой система. Я хочу зашифровать эти значения так что злоумышленник не может быть предоставил доступ кому-то другому система путем изменения значения. Здесь хорошие стандарты .NET для этого типа Шифрование / безопасность? Что ты порекомендуете ли я в этом случае?

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

У меня есть пара ключей, которые являются уникальными для пользователей и передаются клиентом через iframes, и для поддержания сеанса мы создаем файлы cookie, используя для них эти значения. Итак, теперь я хочу зашифровать или сгенерировать хеш для этих значений, поскольку они видны в URL. Я не хочу, чтобы пользователи манипулировали этими значениями.

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

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

Answer 1

Боюсь, я не очень четко понимаю детали вашего сценария, но могу сказать, что в целом вы ищете "целостность" данных, которые вы передаете.

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

Не пытайтесь самостоятельно реализовать алгоритм HMAC.Библиотека .NET предоставляет несколько вариантов алгоритма.

Answer 2

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

Я бы порекомендовал вам использовать ключи машины дляшифровать / дешифровать:

Шифровать:

var ticket = new FormsAuthenticationTicket(
    1, // version
    "ticketName", // name of the ticket (it doesn't really matter here)
    DateTime.Now, // issue date
    DateTime.Now.AddMinutes(1), // validity of the ticket
    false, // should the ticket be persistent
    "key1=value1&key2=value2......" // values to encrypt, could be any string
);
string encrypted = FormsAuthentication.Encrypt(ticket);

Теперь отправьте зашифрованную строку по проводам, а с другой стороны расшифруйте.Важно выполнить это по зашифрованному каналу, используя SSL, чтобы избежать того, что человек-посредник может украсть зашифрованное значение и попытаться его перебором:

var ticket = FormsAuthentication.Decrypt(encrypted);
if (!ticket.Expired)
{
    // The ticket hasn't expired (< 1min) => use the values
    string keys = ticket.UserData;
    // TODO: Parse and issue cookie
}

Чтобы это работало, этонеобходимо иметь одинаковые машинные ключи как на стороне шифрования, так и на стороне расшифровки.

---

ОБНОВЛЕНИЕ:

Вот шаги:

1. Пользователь аутентифицирован в Системе A (Домен 1)
2. Система A решает включить в систему iframe B (Домен 2), где пользователь не аутентифицирован
3. Система A генерируетзашифрованная строка, содержащая информацию о пользователе с использованием машинных ключей
4. Система A отправляет в Систему B (через свойство src iframe) это зашифрованное значение
5. Система B считывает и дешифрует зашифрованное значение, содержащее информацию о пользователе
6. Система B выдает файл cookie аутентификации, чтобы указать, что пользователь теперь аутентифицирован в Домене 2
7. Система B показывает аутентифицированное содержимое пользователю

Вы достигли междоменного единого входа.Конечно, эта техника не ограничивается фреймами.

Answer 3

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

{ID = 1, пользователь = Боб}{ID = 2, пользователь = Боб}{ID = 3, пользователь = Фред}{ID = 4, пользователь = Боб}{ID = 5, User = Susan}

Если это так, то, по-видимому, имеет смысл не шифровать идентификатор в URL-адресе, а убедиться, что пользователь действительно имеет доступ к данным, которые он пытаетсясмотреть.Например, если Фред вошел в систему и попытается получить доступ к? Id = 2, система обнаружит, что у него нет разрешения на доступ, и вернет страницу с ошибкой.Но если Боб вошел в систему, он может получить доступ к? Id = 2 просто отлично.Это можно сделать, добавив в таблицу БД дополнительный столбец, в котором указан пользователь, которому принадлежит эта конкретная строка.В этом конкретном сценарии сам идентификатор не является конфиденциальным, поэтому вам не нужно шифровать или обфусцировать его.

Если я неправильно понимаю ваш сценарий, уточните.:)

Answer 4

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

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

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