Is there anything inherently wrong with the idea of temporarily saving user passwords inside the ServletContext?

Question

Here is the premise, I am not allowed to use JavaScript or Cookies for this website.

However I do not wish to ask the user for their password for every essential task that requires their password for at least 15-30 minutes.

I also don't like the idea of saving their password to a temp file in case the program dies and is not able to erase it as scheduled.

So my plan is upon first contact, assign the user a unique randomly generated secure id/hash and attach it inside their generated HTML. And server side match their password to their id inside the ServletContext. This way for all their incoming requests I can match them without asking for password across all classes.

Also I will make sure to automatically erase their info from the ServletContext when their 15-30 minute expires.

So far it seems like to me this method avoids both JS and Cookies, also all the external storage methods that are at risk when the program dies. Yes the ServletContext is supposed to be global, but without their unique temporary id/hash no one will be able to impersonate them.

I am asking this question because I couldn't find anyone else asking the same question so I needed to make sure there isn't anything wrong with this method.

Answer 1

Given the following restrictions:

1. No cookies allowed.
2. No JS allowed.
3. Caching credentials at client-side is not an option.

The proposed approach seems ok at first glance. However, I would suggest that you follow this guidelines:

1. Make sure replay attacks aren't possible. Since you can't hash and sign request at client-side, invalidate and refresh the tokens frequently (preferably with each request) at the back-end.
2. CSRF counter-measures should be in place.
3. SSL should be enforced.