Безопасность авторизации проверки подлинности форм ASP.NET

Файлы cookie зашифрованы, поэтому шансы на это довольно малы. Но все равно.

Более чем один подход к свойствам

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

Подход с токеном безопасности входа

Вы можете использовать альтернативный подход, описанный в этом сценарии:

1. Пользователь входит в систему.
2. Создайте случайный токен входа в систему безопасности, который может иметь произвольную длину с определенной минимальной длиной, и сохраните его для пользователя в хранилище данных. Это, вероятно, не проблема, хотя довольно часто при входе в систему сохраняются и другие данные, такие как LastLogonDate информация.
3. Используйте этот токен и сохраните его в файле cookie вместо имен пользователей или другой информации.
4. Если пользователь выходит из системы, удалите маркер безопасности входа в систему из хранилища данных.
5. Пользователь снова входит в систему... вернитесь к 1 и снова создайте новый токен и используйте его в этом сеансе.

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

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

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

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

Нет, это невозможно (ну, теоретически возможно, но на практике это невозможно). Значение файла cookie аутентификации зашифровано, поэтому пользователь не может его изменить. Рекомендуется хранить (уникальное) имя входа в файле cookie аутентификации, потому что при восстановлении объекта IIdentity (HttpContext.Current.User) значение, которое вы передали SetAuthCookie, используется для свойства Name объекта IIdentity. Свойство Name будет отображаться, если вы используете, например, LoginStatusControl, поэтому рекомендуется, чтобы значение свойства Name имело смысл для пользователя.