Either you employ some sort of malware detection on your login page. Modern trojans mostly inject stuff into web pages, so things like Trusteer Pinpoint will scan the DOM and report back anomalies. Based on those reports you block the user from logging in or send them to a safe sandbox so they can't do any damage to their accounts.

Alternatively, you can work with your clients' ISPs. Most malware still exhibits visible communication patterns, either by getting in touch with other bots or by contacting command-and-control servers. Once you get ISPs to notice that sort of behaviour, they can sandbox their clients and have them clean up their systems before they reach the Internet (and disclose all of their data).

802.1x at the ISP? That'd be a very interesting proposition.

As a webserver: You don't. If the client is owned, that's not the server's problem.

Related: https://paragonie.com/blog/2016/03/client-authenticity-is-no...

That's not really the point, it is more of a comment on that there's no point in assisting it.

Isn't this what Intel's SGX system is supposed to do? Create a trusted, isolated execution environment, that's certified by Intel (or whomever manages your PC platform) not to mess with your data in malicious ways?

IIRC can't it communicate directly to the keyboard,screen and the network?

Besides DRM, this is probably the next best killer feature for the system if it's as secure as they claim.

iSGX utilizes iME's DAL interface to access to a very limited subset of iME features that explicitly pertain to cryptography (primitives), time and calculations. iSGX is dependent on a skylake processor (due to the MEE[the hardware being iSGX] being attached/combined into the MC) and BIOS/UEFI support for iSGX.

Features such as PAVP via Intel Insider are not accessible in the current implementation (version 2) of Intel Software Guard Extensions. Access to PAVP and other powerful features of iME such as iAMT has been restricted to Intel and Intel Partners (M$, DoD) through obscurity and no available documentation. However, that being said, there are several white papers authored/co-authored by Intel employees who do make use of these immensely powerful features.

iSGX (nor any current technology that is known to the public) is capable of ensuring input CIA properties (without utilizing Intel Insider/PAVP to display a digital keyboard, transmitted via direct bus to NIC/eth.)

Other security technologies, specifically Sanctum does provide different coverage than iSGX but there is no "unified" security technology that is a one-size-fits-all solution.

iSGX's main PoF is poor security implementation by ISV's/enclave writer's. That being said it is better than TrustZone, TXT, XOM, Bastion, Aegis and Phantom in regards to the ratio of return:implementation cost.

edit: additional information

In practice no, it's not useful for this because it has to take over everything. This makes it basically impossible to support for anything complex like a web browser. You end up having to put way too much stuff in the trusted environment. It might have worked way back in the text terminal days when it was slightly realistic for someone to build basically an entire trusted OS to run instead of your normal OS, but today that's just not going to happen.

HAVEN (DrawBridge/MOAT) demonstrated the possibility of enclosing a stripped down OS within an enclave.

Hoekstra and fellows at Intel have created a PoC secure browser plugin that utilizes an enclave.

Use of middleboxes that are hardened and have iSGX support can be used as a proxy as well to limit exposure.

I wouldn't. The point was more that this mitigation for password entry amounts to saying "if a client infected with malware logs in to the banking site, at least we can be sure that the malware won't be able to determine the user's password - they will only be able to steal all of the user's money".

Only permit logins from a client access device that you also manage and/or control.

Like a Bloomberg terminal.