Timeline for Is the data between a keyboard and a web browser secure from local computer applications?
Current License: CC BY-SA 4.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 30, 2019 at 19:35 | vote | accept | Devil07 | ||
| Jan 17, 2019 at 1:58 | review | Suggested edits | |||
| Jan 17, 2019 at 8:13 | |||||
| Jan 16, 2019 at 21:30 | comment | added | Matija Nalis | @GiacomoAlzetta by the time you get to trusted device (could be weeks if you are traveling - if you don't have a trusted device for only a few minutes or even hours, you could very well waited and not used the vulnerable public device in the first place!) attacker might have used that account to compromise your other accounts, get sensitive data, impersonate you etc. Also even the big players (like google, paypal, ebay, ...) do not require different 2FA for changing 2FA settings, and using the same 2FA is vulnerable for many attacks - saying it's "designed incorrectly" isn't helping really | |
| Jan 16, 2019 at 8:10 | comment | added | Giacomo Alzetta | @MatijaNalis Not really. Obviously after logging into an untrusted system you should check the active sessions from a trusted device which means even if they do that their session wont last long... Changing recovery settings etc should not be possible without having to redo the 2FA step with a different token (if that's not the case it is designed incorrectly). | |
| Jan 15, 2019 at 21:24 | comment | added | nardnob | @sleske Okay I have a solution, but it's going to require a screwdriver and a replacement motherboard | |
| Jan 15, 2019 at 21:22 | comment | added | sleske | @nardnob: One word: hardware keylogger (ok, two words). | |
| Jan 15, 2019 at 21:19 | comment | added | nardnob | You coooouuulld restart the PC and boot from a thumb drive... lol | |
| Jan 15, 2019 at 15:14 | comment | added | David Mulder | @sleske Doesn't need to be off-line, any secondary communication channel for transcation (or any edit really) authorization will do. SMS - the most typically used one - will do that just as well as an offline TAN generator (although the latter does have other strong security advantages). | |
| Jan 15, 2019 at 7:53 | comment | added | sleske | @Will: Just to nitpick - HSTS does not work if the browser is untrusted, because the browser needs to enforce it. If you can manipulate the certificate list, you can also patch the browser to ignore HSTS (or just log all HTTPS traffic) :-) . Of course this boils down to: Untrusted is untrusted. | |
| Jan 15, 2019 at 7:51 | comment | added | sleske | @mgarciaisaia: Even MFA provides only very limited protection. It prevents others from re-using your credentials, but they still control the session you opened - so while they cannot login as you onto your online banking, they can drain your account while you're online. The only meaningful protection I know of on an untrusted computer is off-line transaction authorization, as provided by e.g. off-line smart TAN generators, which let you see and confirm each transaction. | |
| Jan 15, 2019 at 6:35 | comment | added | Will | @bashCypher TLS stripping is only a tangent (and prevented on many major sites with HSTS). The real issue with using someone's else browser, is that they can have it configured to accept their own custom Certificate Authority, issuing its own certs for seamless TLS MITM. | |
| Jan 15, 2019 at 2:46 | comment | added | Matija Nalis | @mgarciaisaia it depends on the nature of compromise. If it was simple keylogger, than yes, you might be protected by 2FA (although some of them allow fall back to less secure settings!). However, if the malware on public kiosk is little smarter, it could do a lot of damage. For example, when you click "logout" it might show you fake screen saying you are logged out, while in reality it did not log you out and is in the background doing stuff in your account, like setting up forwarding of all emails somewhere, changing recovery settings etc. | |
| Jan 15, 2019 at 2:00 | comment | added | GrandOpener | Some services (example: WeChat) offer authentication methods precisely for this use case. When you attempt to access the service on a public terminal, it displays a QR code. You scan the code with your phone (which presumably is using trusted connection) and the authentication path happens though your phone. Once you verify (using your phone) that you want the session to be granted access, the public terminal session gets a notification and you can access your account there. A malicious terminal could read all your messages, but at least it doesn't compromise your account. | |
| Jan 15, 2019 at 1:58 | comment | added | mgarciaisaia | Your password gets compromised, yes - but your account doesn't. | |
| Jan 15, 2019 at 1:58 | comment | added | mgarciaisaia | If you use a 3rd-party computer to log into your e-mail, the ultimate line of defense against someone else loging into your account is using MFA. Even if they key-log your MFA token, it should be useless for them to access your account. | |
| Jan 15, 2019 at 1:04 | comment | added | bashCypher | @mgarciaisaia on a public kiosk? I guess we could talk about the kiosk being secured and the app security on it... but I think the point is we can't trust the kiosk. So the question is:can you use the web browser securely, if not, is there anything you can do? In that case I don't think "set up multifactor with the kiosk owners and have that apply to all the apps to avoid un-registered applications (key logger)" is reasonable? Is that fair? | |
| Jan 15, 2019 at 1:01 | comment | added | mgarciaisaia | Multi-factor authentication is the mitigation for that, isn't it? | |
| Jan 14, 2019 at 23:50 | history | edited | bashCypher | CC BY-SA 4.0 |
added 368 characters in body
|
| Jan 14, 2019 at 23:47 | comment | added | bashCypher | @z0r MITM using TLS stripping is a concern across the entire world. Always be careful in public, right? MITM is a little different than your describing, but you're point is valid and I didn't discuss the "interception" part. I'll update. | |
| Jan 14, 2019 at 23:44 | comment | added | z0r | It's worse than that: on any computer that you don't control, the CA certificates used to verify the identities of the servers may have been compromised. So you might not be talking to the web site you think you are - even if you're using HTTPS. Don't trust public computers. | |
| Jan 14, 2019 at 19:45 | history | answered | bashCypher | CC BY-SA 4.0 |