Asp.net сохраняет сеанс в файле cookie, таким образом, не нужно беспокоиться о сеансах на стороне сервера (обычно сеансы хранятся в базе данных, и поиск выполняется через идентификатор сеанса, который обычно является строкой, подобной Guid).
В моем предыдущем вопросе я спрашивал о том, как приложение Spring хранит / создает сеансы и т. Д .: Аутентификация Spring, использует ли оно зашифрованные файлы cookie?
Клетус отметил, что сохранение имени пользователя / идентификатора в cookie-файле, хотя и зашифрованное, является проблемой безопасности, поскольку потенциальный хакер имеет как зашифрованный текст, так и хакер знает, что такое зашифрованный текст, то есть userId или имя пользователя.
Что вы думаете об этом?Я уверен, что StackOverflow также использует этот механизм, как и ** 99,9% веб-приложений asp.net, которые используют формы аутентификации таким образом.Сам MSDN-сайт Microsoft заполнен примерами, такими как:
FormsAuthentication.RedirectFromLoginPage(UsernameTextbox.Text, NotPublicCheckBox.Checked);
В приведенном выше коде значение имени пользователя хранится в зашифрованном файле cookie. На самом деле, я вспоминаю, что сайт asp.net был взломан, потому что в web.config не было тега Protection = All в теге аутентификации форм. Так это реальная проблема?Повторим, с чем связывают клему: на случай, если вам интересно, что такое «кроватка».см .: http://www.faqs.org/faqs/cryptography-faq/part03/
Криптоаналитические методы включают в себя то, что известно как практический криптоанализ '': врагу не нужно просто смотреть на ваш зашифрованный текст, пока он не выяснит открытый текст.Например, он мог бы предположить, что у подписчиков есть '' - отрезки вероятного открытого текста.Если шпаргалка верна, он может вывести ключ и расшифровать оставшуюся часть сообщения.Или он может использовать `` isologs '' - тот же открытый текст, зашифрованный в нескольких криптосистемах или нескольких ключах.Таким образом, он может получить решения, даже если криптоаналитическая теория говорит, что у него нет шансов. **