Thanks for the report. I am removing security flags because this isn't a vulnerability (we are talking about exposure on an already exploited system), but I am also leaving the bug open for consideration as a possible security enhancement.

I suspect the exposure is too wide for us to really mitigate, in most cases. Once a client has been compromised, POST data is a convenient target but login credentials are usually saved locally anyway, making them similarly available for extraction. Also, we have to keep the session cookie available which is almost as valuable. Further, being able to extract data from memory would typically mean you could monitor the process and network stack going forward, stealing passwords the next time they are entered or used.  It seems questionable whether clearing specific data from memory would be worth the effort.

Thank you for the reply.

If you don't mind me asking, what is the use case for remembering post parameters up to an hour (or longer) following the login? Is that data ever used internally? Why does it float around?

I respect your decision to label this issue as not a security issue, however I will add a few extra resources, the first being the Verizon breach report (https://regmedia.co.uk/2016/05/12/dbir_2016.pdf) showing 63% of confirmed data breaches involved weak, default or stolen passwords. The issue isn't just with the web services, it's with a more systemic problem of password reuse, which makes the passwords far more valuable than session tokens.

I'll also point to the Mimikatz tool (https://github.com/gentilkiwi/mimikatz) which dumps cleartext windows passwords, and also requires system level access, however is widely used by criminals and nation state actors alike over other means you mentioned such as network monitoring, keylogging, and token stealing. The ultimate response from Microsoft was to no longer persist login credentials in memory for operating systems >=8.1 

All of this is likely information you already know, however I'm including it for any other onlookers now that the issue is open to the public.

I would also like to add I just tested this on an incognito window, and data remains in memory following the closing of the incognito window.

It's not that there is necessarily a use case for retaining data in memory, it is more likely that the memory is being freed without also being re-allocated + overwritten for some time. The concern is simply that it would be a lot of effort to try to find every place where memory scrubbing before free() would make sense, with marginal benefit to users since the same data can be obtained in different ways in the event of a system compromise.