Что-то не так с идеей временного сохранения пользовательских паролей внутри ServletContext?

Question

Вот предпосылка, я не могу использовать JavaScript или файлы cookie для этого сайта.

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

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

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

Также я позабочусь об автоматическом удалении их информации из ServletContext по истечении 15-30 минут.

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

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

Answer 1

Учитывая следующие ограничения:

1. Печенье не разрешено.
2. JS не допускается.
3. Кэширование учетных данных на стороне клиента не вариант.

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

1. Убедитесь, что повторные атаки невозможны. Поскольку вы не можете хэшировать и подписывать запрос на стороне клиента, аннулируйте и обновляйте токены часто (желательно с каждым запросом) на стороне сервера.
2. Должны быть приняты контрмеры CSRF.
3. Необходимо применять SSL.