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:
[ Yes ] [ No ]
An SMS confirm code has been sent;
please enter confirmation code:
- 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.
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:
14.9.2 What May be Stored by Caches
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
As the caution indicates, for privacy this header should be used together with HTTPS to avoid eavesdropping.