4 ms·

How would you prevent a client from logging in from an infected system?

by ianferrel 10y ago

Natanael_L 10y ago
That's not really the point, it is more of a comment on that there's no point in assisting it.
- tacatabro 10y ago
  Yeah, but according to the reaction, usability outweighs minimal security in this case. Although keyloggers cannot be used anymore, RAM-scraping is still possible. Simply scan the browser's memory for URL query strings and POST bodies and you're done - even works with HTTPS pages.
phlo 10y ago
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).
- zhengyi13 10y ago
  802.1x at the ISP? That'd be a very interesting proposition.
CiPHPerCoder 10y ago
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-not-server-s-problem https://paragonie.com/blog/2016/03/client-authenticity-is-no...
fl0wenol 10y ago
Only permit logins from a client access device that you also manage and/or control. Like a Bloomberg terminal.
jasonjayr 10y ago
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.
- rollingincache 10y ago
  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
- jandrese 10y ago
  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.
jameshart 10y ago
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".

How would you prevent a client from logging in from an infected system?

Natanael_L 10y ago

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

tacatabro 10y ago
Yeah, but according to the reaction, usability outweighs minimal security in this case. Although keyloggers cannot be used anymore, RAM-scraping is still possible. Simply scan the browser's memory for URL query strings and POST bodies and you're done - even works with HTTPS pages.

phlo 10y ago

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).

zhengyi13 10y ago
802.1x at the ISP? That'd be a very interesting proposition.

CiPHPerCoder 10y ago

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-not-server-s-problem https://paragonie.com/blog/2016/03/client-authenticity-is-no...

fl0wenol 10y ago

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

jasonjayr 10y ago

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.

rollingincache 10y ago
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
jandrese 10y ago
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.

jameshart 10y ago

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".