homepage Welcome to WebmasterWorld Guest from 54.161.147.106
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / WebmasterWorld / Ecommerce
Forum Library, Charter, Moderators: buckworks

Ecommerce Forum

    
Online banking with JavaScript?
Trusting a bank that uses JavaScript for account login.
RWSteele




msg:643588
 7:24 pm on May 15, 2006 (gmt 0)

I came across something today on my bank's website that made me a little nervous and I wanted to get some opinions.

My bank has a login form on their home page, which is a non-secure (HTTP). The form submits to a secure page (HTTPS) page, but uses JavaScript to submit the form. They have a link to a page which states: "To provide the fastest access...we have made signing in to Online Services secure without making the entire page secure....be assured that your ID and password are secure."

Now, I've been around long enough to know that JavaScript can do some pretty amazing stuff, which includes encryption to some degree, but why does it bother me that someone got paid more in a week than I do in one month to decide that two clicks was one too many and a secure connection could be tossed out the window?

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.

Was this a marketing move? Did that second click to a secure page cause stress or finger cramps during testing? Do I need to brush up on my JavaScript?

I guess I'll either learn something new about "real world" JavaScript or I'll be switching banks soon.

 

webdoctor




msg:643589
 6:41 am on May 17, 2006 (gmt 0)

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?

badass101




msg:643590
 8:48 am on May 17, 2006 (gmt 0)

Most likely the JavaScript is calling the submit method of the form, which means that if it's posting to an https address then the details are secure.
Absolutely nothing to worry about, and not 'out of the norm' nowadays.

lorax




msg:643591
 12:30 pm on May 17, 2006 (gmt 0)

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

graeme_p




msg:643592
 12:30 pm on May 17, 2006 (gmt 0)

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.

LifeinAsia




msg:643593
 3:43 pm on May 17, 2006 (gmt 0)

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.

RWSteele




msg:643594
 6:17 pm on May 17, 2006 (gmt 0)

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.
[cs.nyu.edu ]

webdoctor




msg:643595
 9:02 pm on May 17, 2006 (gmt 0)

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.

webdoctor




msg:643596
 9:06 pm on May 17, 2006 (gmt 0)

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

webdoctor




msg:643597
 9:12 pm on May 17, 2006 (gmt 0)

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?

graeme_p




msg:643598
 1:07 pm on May 18, 2006 (gmt 0)

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.

RWSteele




msg:643599
 4:12 pm on May 18, 2006 (gmt 0)

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.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Ecommerce
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved