I came across something today on my bank's website that made me a little nervous and I wanted to get some opinions.
In their defense, users can login via secure page, but it requires three clicks. Yes, three. Ohhh the pain.
Did I miss something? I visited 3 other banking sites and NOT one offered account login via the home page.
|which is a non-secure (HTTP). The form submits to a secure page (HTTPS) page |
|and a secure connection could be tossed out the window |
I think you've misunderstand their setup.
There's ZERO benefit in securing the empty form on its way to your browser (no need for SSL), only the SUBMIT needs to be secured.
Someone sniffing network traffic could intercept the empty form - but what good does that do them?
Absolutely nothing to worry about, and not 'out of the norm' nowadays.
>> There's ZERO benefit in securing the empty form
Except to keep questions like this from happening. ;)
The perception is that the form is NOT secure. The POST may be secured but how would the common Joe know this? Every security bulletin I've read that's been fed to Joe tells him to look for the HTTPS or the lock symbol. It's bad design IMO. There's little cost in providing a sense of security to the user by securing the empty form.
webdoctor, I think I can see a possible man in the middle attack.
If anyone thinks I am wrong please explain.
1) An attacker cracks a DNS server (most likely your ISP's) and send you to a copy they operate of the bank's non-secure site.
2) The login form LOOKS the same but submits to their server.
3) You go to the insecure login form, everything looks OK. Lets assume you do not check the submit url by looking at the source!
4) You enter you login and submit.
5) At this point you will either have the wrong URL in the browser bar or have a warning about a cert - but the attacker already has your login.
This is why SSL provides both encryption AND authenticates the cert. If all we needed was encryption we could all just use self signed certs.
|To provide the fastest access...we have made signing in to Online Services secure without making the entire page secure |
Unless the page is overloaded with graphics or other objects (which is stupid anyway for a signon page), the difference in speed should be negligible.
Considering the number of newbies using online banking, I think that was a stupid move.
Thanks everyone for the input.
|The perception is that the form is NOT secure.... It's bad design IMO. There's little cost in providing a sense of security to the user by securing the empty form. |
I agree, a bad design move and possibly a move that could loose some trust. I'm around this stuff more than the average Joe and I still question it.
|I think I can see a possible man in the middle attack. |
When it comes to HTTPS, I thought that the transaction wasn't secure until the page you were submitting data from was HTTPS?
Maybe I don't understand, but I thought there was some "handshaking" that went on between the client and server and to authenticate keys/certificates?
Feel free to tell me if I need to brush up my protocols.
|...the difference in speed should be negligible. |
I don't have much experience working in "secure environments", but how much overhead can this possibly add? Is it the reduction in traffic to the server or what?
I found this paper from 1999. Except for servers being a "little" faster, the entire process should still the same.
|I thought there was some "handshaking" that went on between the client and server and to authenticate keys/certificates |
But the empty form coming from the site to your browser, ready to be filled in, has no sensitive information in it, and so there's no actual need to secure it.
You only need to secure the POSTed (or GETed) response on its way from your browser back to the server, since this contains the sensitive information.
Remember, the empty form could have come from a completely different source - it could even be stored locally on your hard drive. You could enter the values and them SUBMIT them to a server over SSL. This is why you always validate user input on the server not on the client - it's too easy to get round validation if it's client-side.
I should point out that it's pretty odd not to secure the initial form, but there *is* a significant load associated with setting up a SSL connection.
|the difference in speed should be negligible. |
Almost all cryptography is computationally expensive.
If your server CPU is maxed out, then reducing the number of SSL connections will definitely help. This is why many sites have SSL-secured login (to protect username/password), which then sets a cookie but returns the user to a non-SSL connection while they fill their shopping basket with products. You'd be surprised how many check-out routines aren't SSL secured either - only the credit card payment warrants SSL...
|I think I can see a possible man in the middle attack. |
I'm no crypto expert, but I don't think you've actually described a MITM attack. You are just describing one site impersonating another. Essentailly this is "just" the approach used in phishing.
I'm not really sure that SSL protects users as much as we'd like to think - what's to stop me buying a cheap automatically-issued SSL certificate for my phishing site?
Also - how many people double click the padlock to check the properties of the SSL certificate?
You are right in that my description of this as MITM is wrong.
However there is a crucial difference between this and a phishing attack: this would work even if you enter the url by hand in your browser.
|cheap automatically-issued SSL certificate for my phishing site? |
Its not that easy. For one thing even the cheap cert issuers do some checking - AFAIK they check that you actually own and control the domain. For another, you have to pay for them and that may make you traceable.
It may be possible for someone to get a cert for a domain they do not own by impersonating the domain owner.
I can not recall ever coming across a phishing site that has an SSL cert (I often follow phishing links and add some junk to their DB).
SSL may not be perfect for checking a site is what it says it is, but it is certainly far better than not checking the sites ID is what it ways it is - which is what the bank in question is forcing its users to do.
My guess is that this probably came down to usability, performance, and security. And unfortunately it looks like usability and performance won over security, which seems to always be the case. With all of the concerns about phishing and scams, a bank wouldn't think of taking chances like this. For the record, this isn't your local city bank.
It just seems they're out of touch with their customers and cutting corners is more important than making customers feel secure. That's not worth the risk in my opinion, especially in the banking industry.
It was mentioned that users have been told over an over again to look for the padlock. Even it's just "smoke and mirrors", the perception of being secure could be the difference between keeping a customer or loosing them to another bank. Paranoid isn't a bad thing sometimes.
I'm thinking about sending them an email just to see what they say, if anything.
Thanks again for all the input.