Don't believe me?
https://www.chase.com
In fact, quite a few local banks with 'web access' don't use SSL either.
-
Follow
Oops, something didn't work.
Sign In to be begin to follow this thread
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.Getting "follow" information
Start following this thread
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.Removing your "follow"
Setting up your "follow"
Did you know you can
sign up for email notifications?
-
ScanIAm
This is an...
-
Maurits
AKA Matthew van Eerde
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 -
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 -
ScanIAm
This is an...
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.
-
DCMonkey
What?!?
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...
-
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? -
ScanIAm
This is an...
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.
-
Sven Groot
Don't worry... I'm a doctor.
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. -
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
-
ScanIAm
This is an...
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. -
Sven Groot
Don't worry... I'm a doctor.
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:
- Check if the internet address starts with https://mijn.postbank.nl/...
- Enter your username and password to login
- For safety, check again if the internet address starts with https://mijn.postbank.nl/...
Why check only twice? Isn't third time the charm?
-
Maurits
AKA Matthew van Eerde
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.
-
ScanIAm
This is an...
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:
- Check if the internet address starts with https://mijn.postbank.nl/...
- Enter your username and password to login
- For safety, check again if the internet address starts with https://mijn.postbank.nl/...
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
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.
-
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!
-
Sven Groot
Don't worry... I'm a doctor.
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.
-
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. -
Maurits
AKA Matthew van Eerde
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.
-
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.
Thread Closed
This thread is kinda stale and has been closed but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.