HTTPS Sensitive Information and Caching

Question

I have a website where I need to share a sensitive key with the user. Of course, I'm using HTTPS on the page. The key is put into the HTML server-side in ASP.NET. My concern is, if the user's computer was compromised, could the contents of the user's cache be read and the key found in the browser cache? Is HTTPS cached content encrypted on disk? Is it even cached?

Update

I just wanted to clarify my question. One of the posters said that if the user's computer has malware that the game is over. First, I was referring to a laptop that's stolen rather than malware. I have in mind those incidents you hear on those news of "lost" laptops that have credit card info, SSNs, etc on them.

The key that the user is accessing over HTTPS is used with a program that I am confident is secure against attack of the data at rest. Even if the computer itself was compromised, the data the key protects is secure. I just want to cover all of the bases.

What is cross-browser standard practice when you have sensitive information that you're trying to protect with HTTPS that you don't want cached?

Answer 1

My concern is, if the user's computer was compromised,

Then user loses, sorry.

If the computer is compromised, anything the user sees can be picked my malware; anything the user is allowed to do can be done by malware (and any CAPTCHA you could send at the malware, the malware can intercept and submit it to the end-user).

OTOH you could ask confirmation for sensitive commands:

Launch nuke 
[ Yes ] [ No ]

(clicks yes)

An SMS confirm code has been sent; 
please enter confirmation code:

Of course:

• the SMS must be clearly labeled to describe the meaning of the confirmation code, and what copying the code implies;
• a smart phone can be compromised too; in theory access to SMS is restricted to some apps, but when the system is compromised...
• if you require confirmation code often, this can become annoying; user will complain about the unfriendliness and can even decide to use a less secure system (security features that are ignored are not very useful in practice);
• users can go in auto-confirm mode: they turn off their mind and copy any confirmation code they receive via SMS in the confirmation form (because the computer is compromised, the confirmation form will read: Please enter confirmation code to send .01 $ to a charity but at the same time the SMS will read Nuke confirmation code has been requested; only enter to confirm code to launch nuke; code is xxxx-xxxx-xxxx)
• of course, someone might steal the phone (that someone can even be the person who installed the malware).

Is HTTPS cached content encrypted on disk?

HTTPS can be cachable or not, depending on the cache-control HTTP header (like HTTP content).

Is it even cached?

HTTPS cached resources cannot be stored encrypted on disk anymore than HTTP cached resources, or normal file can be stored encrypted: the web browser needs to be able to read and decrypt the file, so the key needs to be stored somewhere.

You can do whole disk encryption, but given your assumption that the client computer has a malware, how could it possibly help? Either you do not enter the passphrase, and keep the disk encrypted, and the disk is a useless box, or you enter the passphrase, and the OS decrypts the disk, and all installed softwares can access the files in clear-text, limited by OS access controls as usual.

Re: UPDATE

First, I was referring to a laptop that's stolen rather than malware.

I misread the word "compromised".

First, if a computer is stolen, be careful if it is ever returned to you to completely check or wipe-out anything that might hold malware. It could be "comprised" as in "infiltrated by installation of malware".

Full computer protection

In which state was the computer when it was stolen?

Full disk encryption is a strong defense if a computer is stolen when not running.

Web-browser level protection

As I wrote previously, caching can be controlled with the Cache-Control HTTP header:

• Cache-Control: no-cache will only prevent HTTP clients from reusing cached resources without revalidation;

• Cache-Control: no-store should prevent storage of

14.9.2 What May be Stored by Caches

no-store
The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example, on backup tapes). The no-store directive applies to the entire message, and MAY be sent either in a response or in a request. If sent in a request, a cache MUST NOT store any part of either this request or any response to it. If sent in a response, a cache MUST NOT store any part of either this response or the request that elicited it. This directive applies to both non- shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. Even when this directive is associated with a response, users might explicitly store such a response outside of the caching system (e.g., with a "Save As" dialog). History buffers MAY store such responses as part of their normal operation. The purpose of this directive is to meet the stated requirements of certain users and service authors who are concerned about accidental releases of information via unanticipated accesses to cache data structures. While the use of this directive might improve privacy in some cases, we caution that it is NOT in any way a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.

As the caution indicates, for privacy this header should be used together with HTTPS to avoid eavesdropping.

Answer 2

HTTPS content can be cached by the browser, and apparently will be cached, unless explicitly instructed otherwise by the server. See this answer for details and links.