How long do HTML password fields (sent to the server as postdata) remain in memory?

Question

In any major server-side web framework, there is usually a mechanism to read HTML form input, e.g. in ASP, for an HTML element, <input type="text" name="the_field" />, it is Request.Form("the_field"), where Request.Form is a dictionary-type object where the values are parsed from the POST data into key/value pairs.

There are also various recommendations for only keeping passwords in memory for minimal time, up to and including using a mutable character array instead of an immutable string, pinning it so it cannot be paged or copied, and zeroing each array element when done (or using something like .NET's SecureString, which does the same).

Given these, what mechanisms might exist for telling the web server that it needs to treat the posted form data as secure, and to do the pinning/clearing for, say, an HTML <input type="password" /> field?

One might reasonably expect the browser to go the extra mile for password fields (although I expect they don't), because they can infer from the markup that such protections are necessary.

The transport layer is covered by HTTPS, and is not in question.

But nothing I have seen provides the web server with the semantics of post data, so it can choose to apply in-memory protections.

I've had a couple of ideas how such a thing might be handled in a web server if designed by scratch (note that I am not designing a web server from scratch!):

1. Apply in-memory protections to all requests: This seems like it might be the most straight-forward, but may negatively impact performance for pages that are not strictly sensitive but are served under SSL (e.g. all-SSL sites or 'My Account' pages that don't have 'New Password' fields). Might be configurable at an 'all requests' / 'HTTPS only'

2. Standardise an HTTP header that defines the fields to be protected: Mitigates the all-SSL issue, but would provide an obvious starting point for inspection (although I'm sure txtUser=foo&txtPassword=bar is already a good-enough indicator). Would take x years for the W3C to agree on a standard, and another y years for browsers to implement it.

3. Register secure post fields in server config (or through language integration): The server's request stream parser would be responsible for reading each post key, checking against the internal list and apply in-memory protections to the subsequent post value. Maybe even excluding it from the normal Request.Form in lieu of a Request.Passwords object with a fit-for-purpose data structure, or substituing the Request.Form value with an object reference to the SecureString.

So are there any web servers that already do this (or something like it), or allow you low-enough level access to implement these protections manually? I thought maybe IIS7's integrated pipeline, but I can't see an event that runs early enough.

Are such protections even necessary, or is this just a solution looking for a problem? If so, what makes this unnecessary where a desktop app's in-memory password handling is not?

Answer 1

Whether traditional "protections" for sensitive data in desktop RAM (e.g. SecureString) are really needed or not, is debatable. When attackers can read the RAM contents, they already have a lot of control on the machine. We can still justify some proactive measures in the following sense:

• RAM in a machine may leak to disk, through virtual memory.
• The hibernation mechanism on laptops is also prone to copy RAM contents to disk.
• Desktop machines may be infected by malware (through the user's gullibility) which might run with limited privileges but still be able to explore the RAM contents of other process running for the same user.
• Physical security of desktop computers (and especially laptops) cannot be ensured at all times; the attacker may grab the machine and run away.

For these reasons, it is best if the passwords and other sensitive data are "protected", i.e. prevented in some way from leaking to disk, and forcibly removed from RAM immediately after usage, thereby reducing the vulnerability window.

None of these reasons apply to servers (even the bit about "virtual memory": if your server hits swap space, then it does not have enough RAM; RAM is cheap nowadays; good servers don't use swap space at all). Therefore, it can be argued that servers don't need to apply the traditional in-RAM protections for passwords.