How can I redirect to logon.jsp with unencrypted password in the HTTPSession?

Question

I have a j2ee web app that is using JAAS form based authentication. However, due to some unusual requirements, I cannot have the user enter their username and password directly into the logon.jsp form and have them submit it. Instead, I must gather the data on a separate page, and then later redirect to logon.jsp to log them in.

What I am thinking of doing is storing the username/password unencrypted in the HTTPSession. When I am ready to authenticate, I use a response.redirect to route to logon.jsp. In logon.jsp, I take the username and password out of the Session, populate the standard 'j-security-check' form, and then use javascript to submit the form.

How much of a security hole is this? I'm uncomfortable routing the request to go to logon.jsp via the browser (thats what a redirect does) because someone might get access to the session, and therefore the unencrypted password. If I am using HTTPS / SSL, is this a likely situation? How would it be exploited?

I looked into invoking the login servlet directly in a JSP without using the form, but that doesn't seem to be a viable option, particularly because I lose my insulation from differing J2EE containers/application servers.

Anyone got any idea how I can limit this security hole? Would using forward as opposed to redirect be better, because it doesnt go back to the browser?

How bad is this?

Answer 1

It sounds like you're sending the password back to the user so that the user can re-submit the form to the real login.jsp. That sounds Battlefield Earth horrific to me. Assuming the user types in the password after he types in the username, can the password form not simply submit directly to the login handler?

Answer 2

Oh god. First rule of password security is never transmit a password in plaintext, ever. If you're storing it in the session in plaintext, that means you're probably having the password sent from the user to your server in plaintext (unless you're using SSL which I strongly suggest). This means any packet sniffer can find the password. As for storing them in the session in plaintext, that means you're vulnerable to session hijacking.

In other words. It is horrific. Do not do this.

Answer 3

It seems that its very easy to describe this kind of practice as horrific, but a lot more difficult to explain why it is horrific, or how it might be exploited in a situation where SSL is used. We place our sensitive information in the hands of HTTPS / SSL all the time, I dont see how this is any different.

Best practice would be to avoid interactions with the browser when unnecessary. You have to manage the pay off between security and usibility, asses your applications requirements and sensitivity, and act accordingly.

In any eventuality, using a forward as opposed to a redirect will prevent the browser participation, as a forward is performed internally on the web tier.