12.07.06
Another reason to use SSL correctly
This is yet another flame to the online banking systems in Chile (and elsewhere).
The problem is as follows: apparently to make the system faster for visitors (requiring only one click), many banks make their login form available on a non-secured page. When everything works as intended, the form directs the request to an SSL-enabled page, so the transmission is effectively encrypted before your browser begins to send any data. But what happens when you get to a web-page that seems exactly like the original but that doesn’t redirect you to that SSL-enabled page? Your data goes unencrypted, probably right to the hands of someone you should not trust. You might notice this if you pay attention, but it would probably be too late and there are many ways of how to make it look as if you really did go to the bank’s web after giving away your login credentials to some unknown server on the internet.
So, how are the odds of getting to a fake bank page? Not very high, unless you get some phishing e-mail or somebody plays with the DNS resolver you use, both very simple and common activities nowadays.
Many banks are using marketing strategies to show how secure they are by giving (actually, selling) tokens for enabling 2-factor authentication. This is good for avoiding your fixed password to be captured by some keylogger (either a software or hardware keylogger). But it does not protect you from a man-in-the-middle attack like the one published on Washington Post.
Ironically, to get to the login page of my bank (Banco de Chile), you have to make an extra click. I can understand that, since not everybody who connects to the main page of the bank needs authentication or encryption, the main page is not secured. Probably most customers would not care to make one extra click (or store a bookmark so they won’t have to) in order to get to the secure login page. But in my case, even when I have to click on the link to get to a second page, that second page is also not secured by SSL, even when the most common use for that page is for logging into the customers bank account. There is not even the alternative for a security-aware customer to go to a, maybe slower but secure, login page. The only way to log in securely is to first enter a valid ID and a fake password, verify the authenticity of the server, go back to the non-secure page and assume that the second time you will also connect to the right server (which is not necessarily true). Or, you may have come across a dark and upublished way to access the server and obtain the login form.
