Coffeehouse Thread

21 posts

Large, National, Well Known Bank Cannot Afford SSL Certificates?

Back to Forum: Coffeehouse
  • User profile image
    ScanIAm

    Don't believe me?

    https://www.chase.com

    In fact, quite a few local banks with 'web access' don't use SSL either.

  • User profile image
    Maurits

    They must have a certificate... the initial SSL connection succeeded without a warning.

    EDIT: Yup, it's valid, and it's a Verisign certificate.

    Go here:
    Verisign Search

    ... and search for www.chase.com

    EDIT2: Or just go here

  • User profile image
    jonorossi

    Their server must be set to redirect https to http for their normal pages so lower the load on their servering having to encrypt everything.

    Maurits is right that they do have one, click "Start banking online now, get a user ID"
    https://chaseonline.chase.com/chaseonline/signup/sso_signup_filter.jsp?LOB=RBGLogon

  • User profile image
    ScanIAm

    What's funny, is that I read about it in a 2 month old magazine about money.

    Called "Money".

    I figured they just forgot to put the https in front, but nope.

    My local bank doesn't secure it either...idiots.

  • User profile image
    DCMonkey

    Our bank switched to an embedded iframe with the login form from a https URL in it. It freaked me out the first time I saw it till I noticed the form loading after the main page. I assume they do it to lower the load on the home page as well. I think it's kind of a stupid idea though. Hmm... I wonder how all that new fangled SSL stuff in IE7 will react...

  • User profile image
    Bugslayer

    What, specifically, needs to be secured on this page that is not secured?

    It is common practice to redirect an https:// request to http:// if the page does not contain sensitive data that is not secured by other means.  (This saves encryption of the non-sensitive data and leaves the CPU for grander tasks.)

    I will assume that you are referring to the UserID and password on this page.  They are both secured with an explicit https:// URL in the action of the form, as in:

    <form name="logonform" id="logonform" align="center" autocomplete="off" action="https://chaseonline.chase.com/siteminderagent/forms/formpost.fcc" method="POST">

    ... or am I missing your point?

  • User profile image
    ScanIAm

    Bugslayer wrote:
    

    What, specifically, needs to be secured on this page that is not secured?

    It is common practice to redirect an https:// request to http:// if the page does not contain sensitive data that is not secured by other means.  (This saves encryption of the non-sensitive data and leaves the CPU for grander tasks.)

    I will assume that you are referring to the UserID and password on this page.  They are both secured with an explicit https:// URL in the action of the form, as in:

    <form name="logonform" id="logonform" align="center" autocomplete="off" action="https://chaseonline.chase.com/siteminderagent/forms/formpost.fcc" method="POST">

    ... or am I missing your point?


    Yeah, I guess that was my point, and you are correct, they do, in fact, encrypt it. 

    After reading a few comments above, I checked and my bank, too, does a redirection to the correct location. 

    The problem comes from the lack of the little 'lock' symbol on the page. 

    I'm constantly telling family, friends, cow-orkers not to ever, ever enter in a passcode on a site that doesn't have the lock icon.  This may be pointless if IE won't display the lock until the entire page is encrypted.

  • User profile image
    Sven Groot

    ScanIAm wrote:
    The problem comes from the lack of the little 'lock' symbol on the page.

    Having an unsecured login page (even though the actual login request goes to a secure page) is in fact "critical mistake #1" in this blog post on https by Eric Lawrence: TLS and SSL in the real world.

  • User profile image
    AndyC

    ScanIAm wrote:
    

    I'm constantly telling family, friends, cow-orkers not to ever, ever enter in a passcode on a site that doesn't have the lock icon.  This may be pointless if IE won't display the lock until the entire page is encrypted.



    You'd be right, the banks doing this are not secure. See this post in the IE blog for common ssl mistakes web devs make.

    EDIT: tch! Beaten by Sven Smiley

  • User profile image
    ScanIAm

    Thanks for pointing that out.  I kind of thought that it would be dangerous to have secure and insecure on the same page, but that certainly points out that it is.

    I'm waiting for one of these companies to be sued over this kind of stuff.  We've had a spate of lost records and identity thefts in the US with banks, so I'm sure it's coming.

    What's interesting, ING is a virtual bank that seems to do this right.  I was annoyed at first with having to manually click my pin on a keypad, but it guarantees that even if they use a keysniffer, the letters will change each time, so they won't work the second time around.

    ING Login

    Quite secure and since they don't fill the page with useless adverts, it loads quick.

  • User profile image
    Sven Groot

    My bank (Postbank) does this correctly. While the homepage is not secured, the login page for online banking is a separate page which is secure: https://mijn.postbank.nl/internetbankieren/SesamLoginServlet

    However, I think my bank wins the prize for rediculous caution messages. You'll notice three bullet points at the top of that page. Translated to English, they read:

    Why check only twice? Isn't third time the charm?

  • User profile image
    Maurits

    Sven Groot wrote:
    ScanIAm wrote:The problem comes from the lack of the little 'lock' symbol on the page.

    Having an unsecured login page (even though the actual login request goes to a secure page) is in fact "critical mistake #1" in this blog post on https by Eric Lawrence: TLS and SSL in the real world.


    FWIW, I'm not sure if I buy Eric's argument.

  • User profile image
    ScanIAm

    Sven Groot wrote:
    

    My bank (Postbank) does this correctly. While the homepage is not secured, the login page for online banking is a separate page which is secure: https://mijn.postbank.nl/internetbankieren/SesamLoginServlet

    However, I think my bank wins the prize for rediculous caution messages. You'll notice three bullet points at the top of that page. Translated to English, they read:

    Why check only twice? Isn't third time the charm?



    That's strange, for me it says:

  • Controleer of het internetadres begint met https://mijn.postbank.nl/...
  • Vul uw gebruikersnaam en wachtwoord in om in te loggen.
  • Controleer voor de veiligheid nogmaals of het internetadres begint met https://mijn.postbank.nl/...

    None of which sounds like what you mentioned Wink

    Interesting, though, that there is an ING label at the bottom right of your link.  I thought ING was a european bank, turns out the ING direct is the US Online version.

  • User profile image
    Bugslayer

    Since IE uses the protocol designation (https://) in the address line to drive the display of the lock symbol in the status bar, I have longed for IE 7 to display the status bar if the cursor is in a text box that will post securely.  Furthermore, why not provide thestatus bar lock and a balloon on hovering over a form region (or the submit button for a form) that will post securely.  Why not provide a visual overlay on submit buttons indicating security?  The balloon could contain details from the cert used to secure the post.  IE should provide a definitive indicator to the user for secure posts -- indicating the target domain for the post and the domain of the cert (in case they don't match)

    end of brainstorm... please, just fix it for everyone!


     

  • User profile image
    Sven Groot

    ScanIAm wrote:
    Interesting, though, that there is an ING label at the bottom right of your link.  I thought ING was a european bank, turns out the ING direct is the US Online version.

    Postbank is part of the ING Group, which is one of the world's largest financial services companies, and also a Dutch company. Smiley

  • User profile image
    AndyC

    Bugslayer wrote:
    Since IE uses the protocol designation (https://) in the address line to drive the display of the lock symbol in the status bar, I have longed for IE 7 to display the status bar if the cursor is in a text box that will post securely.  Furthermore, why not provide thestatus bar lock and a balloon on hovering over a form region (or the submit button for a form) that will post securely.  Why not provide a visual overlay on submit buttons indicating security?  

     


    For one very simple reason: they are not secure

    For a webpage to be secure all of it must be secure, mixing insecure content in or using an insecure form means the site is not secure. Simple as that.

  • User profile image
    Maurits

    AndyC wrote:
    For a webpage to be secure all of it must be secure, mixing insecure content in or using an insecure form means the site is not secure. Simple as that.


    ... well... I don't know about that.  I think there's value in displaying that a form will submit to a secure location.  I even think it's worth a spot in the chrome.

  • User profile image
    AndyC

    Maurits wrote:
    
    ... well... I don't know about that.  I think there's value in displaying that a form will submit to a secure location.  I even think it's worth a spot in the chrome.


    And how do you know that it will submit to a secure location? How can you be sure that some crafty mouse down event won't change what happens at the last moment? How do you know that it's the right secure location? Something is only as secure as its weakest point. If that weak point is completely insecure then you have no security, as is the case here.

    Remember, the only thing SSL guarantees is protection from man-in-the-middle attacks. If you introduce insecure content into the site then you reintroduce a method for a MitM attack once more.

  • Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.