On the current web it is a matter of fact that a banking site should be developed under assumption that a substantial number of users use infected computers with some of them would attempt to perform a banking fraud.
A real experience shows that a substantial number of those fraud attempts comes from computers where malware installs own root certificate and then install either real or transparent proxy. The access to the proxy is then sold to third parties that can do with it whatever they want with decrypted traffic. Sometimes the initial infection comes through a real exploit, but often it is social engineering that works best when a user installs some cool browser extension promising dancing pigs, faster Internet connection etc. Depending on the browser or OS a user could be tricked to install malicious root certificate themselves. As even rather restrictive OS like Chromebook or IPhone allows to install extra certificates, a banking site must be prepared to deal with this on most platforms. Currently the only feasible (and rather weak) protection against this threat is to implement RSA or similar public cryptography in JavaScript and then use that to encrypt important data such as banking password or payment details before they hit the network. The code must be heavily obfuscated to prevent automatic extraction of the public key and algorithm form the JS source in the proxy. This stops lazy thieves that capture the password or one-time-codes for later use while modifying original ones so a banking site would reply with a password error page. This way the thieves do not need to develop any fake pages etc. However, this is useless against more sophisticated attacks that either replace the original banking page entirely or patch its elements to minimize the work to emulate the page design and then capture the passwords. To fight with this issue a help from the browser is essential. One possibility is to replace HTTPS with SRP (srp.stanford.edu) or J-PAKE like protocol that allows for the user and the server *mutually* verify each other without leaking a password. However, this is very drastic as it require to switch the whole site to the new protocol. What is essential is to allow a gradual switch where a site can quickly protect few important pages without significant changes in the current setup. Here is what would be very desirable for a banking site: 1. Browser provides a secure GUI that cannot be spoofed from a web page code or even an extension. The GUI implements SRP/J-PAKE handshake. The GUI should support a form of 2 factor authentication where the user first enters one-time code that she gets from an SMS or a hardware token. Then, after the browser confirms that the server knows the code, a user is presented with a picture or a phrase that she can recognize (this is to make spoofing attempts ineffective) and then proceed to enter the password. 2. The same GUI should allow to sign important action like payment to a new account or password/phone change. In this case the GUI should show to the user a text about what is about to happen that it will receive from the server. 3. Both SRP and J-PAKE as their result, beside a mutual authentication, also provide an encryption key. This key is used to receive the fingerprint for the correct SSL certificate. If it does not match the current one, farther connection is stopped. With that in place the schema could be expanded later to perhaps to specify that for particular pages the browser should replace an ordinary SSL session key with one derived from the new SRP/J-PAKE key so more traffic could be protected. Now the question is if something is missed here? _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
