I guess I'll have to go source diving to know for sure, however. I'll report back here when I get the time. It is BAD news if Oxwall is storing FTP password in the database at all. A session cookie is quite bad also, but bearable if the user is security conscious and cleans cookies.

Some of the readers might be getting ready to say "but if someone has access to your DB you are in bigger trouble"... I agree, but in certain shared hosting set ups there is possibility for greater harm.

Making the user type in the username and password for their FTP details is just a minor inconvenience. If the team is concerned about situations where multiple plugins need to be updated, I suggest an "update all" function that takes FTP creds one time and runs all available updates in one go.

I also suggest that a warning dialog box should appear in the browser above the FTP creds form, asking the user to use Chrome "incognito" or IE/Firefox "private browsing" till this is implemented. This way, cookies will be removed immediately upon browser close. 30 minutes is a painfully long time for passwords to exist unencrypted in a commonly targeted area.

Ah, indeed. My bad for forgetting basic session lessons =) Okay, that eases most of my apprehensions.

We now need to worry only about the server side temp session folder being exposed to other users on the same server, but this risk is significantly smaller compared to browser cookies.

I still say this is a needless feature, storing unencrypted passwords anywhere for any amount of time, all for a minor increase in convenience for users (which can actually be achieved in a more secure way like I suggested above). But hey, I don't have access to the source so all I can do is suggest.