Topic: Store password in the session?

I'm working on a web app that has a login system.  On the page that allows you to edit your account information, I have both a password field and a password confirmation field; obviously, filling these in should allow the user to change his password. 

As a security measure, I'd like to force the user to fill in the password confirmation field each time he changes any piece of his account information, not only when he's updating his password.  The password field (not the password confirmation, just the normal password field) should be pre-populated (as a form password field) with the user's current password when the "My Account" page loads.  This way, the user changes both fields to change his password, and only the confirmation field if he's just trying to edit some other setting related to his account. 

I'm using restful_authentication as the login system.  The non-hashed password is not stored in the database; only the hashed one is.  This makes sense to me -- even folks with admin database access should not have access to the user's non-hashed password.  The question, then, is this: how do I pre-populate the password field on the "My Account" page?

What I've done is store the user's non-hashed password in the session when he logs in.  That way, when he visits the "My Account" page, the session can be used to prepopulate the password field.

Are there security implications to this approach?  Is it unwise to store a user's non-hashed password in the session?  If it is unwise, can someone recommend another approach to solving this problem?

Thank for your time.

Brad

Re: Store password in the session?

Brad, I think you have run into a typical problem of "convenience" vs "security", you can always try to have wonderful security and make it convenient for customers, but sometimes you have to compromise. I would say the simplest secure thing to do is to move the change password feature to its own dialog box or screen. I dont know your domain, but if your serious enough to make them type the password when changing info then you probably don't want to keep it in the session.

You could also move to storing passwords encrypted in the db, this way you could decrypt them for this screen using the app, but most people dont like this either. Hashing is definitely more secure.

If security is paramount you should never store or write the unhashed password anywhere, and never serve it back to the customer except maybe in the case of validation where the 2 didnt match and you are just shooting it back to them (assuming your using https)