We’re not IT experts or anything, but when Chase writes that “all your account information is protected by 128-bit encryption to maintain the privacy and confidentiality of your data,” shouldn’t that mean a little lock icon on the browser window, and an https address? Update: Not necessarily, according to our commenters, although the lack of an https login screen does pose other security risks.
A reader named Ben writes,
Chase.com doesn’t know how to protect their customers passwords. Their login page does not use a secure connection
(see attached). It uses http instead of https. That means that your password is not encrypted when submitted, which is pretty bad for a financial site. (However, they do care enough to include a meaningless, fake “secure” lock icon next to the login form.) I spoke with them a month ago, but they haven’t changed anything.
Once you’ve logged in, everything is encrypted, but that initial password transmission on the home page isn’t. Fortunately, if you’re a Chase customer you can change the address manually to https (just add an “s” to the end of the “http” and hit your enter key) to trigger the encryption.
Note: A couple of initial comments were lost from this post, but we thought this one from beavis88 was good to know:
As long as the target of the form is an https url (and it is), the data will be encrypted. This is bad form, no question, but they are not total and complete idiots at least.
More From Consumerist
-
Chase Won’t Stop Robocalling About My Low Account Balance: I Don’t Have An Account
-
Chase Customers: Did The Bank Ever Re-Open Your Closed Account?
-
Chase CEO Admits That His Executives “Acted Like Children” Following Huge Loss
-
Congratulations, Jamie Dimon, You’re The Sexiest CEO In America!
-
Chase Damages Woman’s Credit Report With $16,159 Error, Doesn’t Really Care
Um, submitting the form sends the data to an HTTPS page. The home page isn’t encrypted, nor does it need to be.
Great and I have a Chase credit card…. which they refuse to lower my APR. Bye bye Chase.
Yep, the comments were all lost, but there’s nothing techincally wrong with their form.
The form action is:
action=”https://chaseonline.chase.com/siteminderagent/forms/formpost.fcc”
The form is submitted over HTTPS, which is all that matters. The form submission is secure. There’s nothing to talk about or worry about here.
The little “lock” icon has become quite the misinterpreted little symbol. SSL encrypts in-transit, so presenting the initial form over HTTP is no problem.
Chase could have given warm fuzzies by putting the form on the SSL server, but it is not by any means less secure.
@Jbball: Reading is awesome, all the cool kids are doing it.
you can also use this URL to go directly to the logon page with https encryption: [chaseonline.chase.com]
Agreed. This story is inaccurate. Just tested and confirmed that their login is secure.
Nothing to see here, everyone move along.
Still thought the https vs http info is good for people who may have not known.
Consumerist, do your research first. The data IS submitted over HTTPS, and it IS secure.
Your username and password are definitely encrypted since the form posts to an HTTPS page. This isn’t the best way to do it, but it’s definitely secure right now.
@howie_in_az: The reason the home page *should* be an HTTPS page is that a non-HTTP page can be hijacked and altered by a third-party while in transit. For example, it could be altered so that the login form sends data to the hacker’s server instead of to Chase’s HTTPS page.
@howie_in_az: Wrong. If the login page isn’t encrypted, it makes man in the middle attacks trivially easy.
Any time that I could get between you and the Internet (say, at a cafe), I could alter the HTML of that login page to send me the password, and you’d have no way of knowing. Therefore, it’s only marginally better than sending your password in the clear.
“We’re not IT experts or anything”
Then don’t report on things you don’t know about.
Want to see something funny? Check out [secure.myspace.com] and yes you can even look at the action form there.
“We’re not IT experts or anything…” Yep, you got that right. But maybe there is someone who could have set you straight before setting of the hysterical alarm.
It’s still pretty skeevy. I also don’t want to get in the habit of submitting sensitive credentials over http. Instead of using the main page, I bookmarked [chaseonline.chase.com.] That gets you to a login page that is completely encrypted.
I already commented on this once but it’s gone so here goes again:
While it is true that the form submission is submitted via https (encrypted) it is still not as secure as it could be if the form page itself were ssl encrypted.
Reason being is that if your DNS has been poisoned you could think you were on the Chase page when really you were on the page of an evil doer. If the log on page were encrypted the ssl certificate would not match and you would (in browsers I use) get a certificate mismatch security warning.
If this bothers you as it does me you can bookmark the secure login page, here:
[chaseonline.chase.com]
Scottrade does the same thing.
@FitJulie: Ugh, and take the dot off the end of that link. [chaseonline.chase.com] should work.
This assertion that these logins are insecure is a bunch of BS.
The page itself is not encrypted, but the form is. When you type in your info and hit send, the information is encrypted. These types of logins are normally secure.
However, there is a concern of not being able to view a security certificate. In addition, it creates a risk in the case of a successful DNS Spoofing attack.
Banks are slowly transitioning away from 100% front page logins though. For instance, they often will separate the username and password entries to different pages. Some even employ user set authenticators, such as a phrase or picture to help the user ensure they are still operating on the bank’s website.
Others are just simply redirecting to an encrypted homepage, for instance, Citibank and their Citicards website. It used to be the same as the aforementioned Chase back in the day with just the encrypted form on the non-encrypted homepage.
@phripley: Well said. And anyone upstream of your connection could rewrite the login page on the fly, they wouldn’t even need to mess with DNS.
@esd2020: Yeah, and you could do that as well at the end point once the https form was decrypted. There are plenty of other ways to do a man in the middle attack at something like an internet cafe even if the https page was served up encrypted; all you’d have to do is forge a copy – it’s not too hard to set up your own SSL server and even a local DNS, and fake that certificate.
Nobody actually checks the certificate – they just look for the little lock, and that’s the problem. The lock icon means jack.
I’m sure the form submission is going to an SSL server, but this is in fact less secure, because the page where you ENTER your credentials should also be secure and signed by a SSL certificate linked to Chase.
This opens up easy phishing possibilities, because it becomes trivial for anyone to create a Chase-looking login page which users can be directed to, and you can’t check the certificate to ensure that you’re really at Chase’s site before you enter your credentials and hit “submit”.
So while your credentials are not sent clear-text, this is bad and insecure and should be fixed. If nothing else, to correct this user perception problem, but really to close an easy phishing avenue of attack as well.
Now this would be hilarious if this kind of stuff happened with Wamu. Those stupid commercials infuriate me, “guaranteed protection thingy or something.” YARGH!
@tcp100: Uh, no you couldn’t. There’s no way to see inside a https form while it’s in transit. The only “endpoints” where it is decrypted are in your computer and on Chase’s server.
You also can’t just “set up your own SSL server” — who’s going to sign for the certificate? If it isn’t signed by a well root authority then it’s going to throw a big warning in your browser.
It doesn’t matter if people check the certificates. When they don’t match, a large warning is displayed.
@fargle: And the user perception problem is key.
As shown by this article, people are just trained to look for little icons and such. Nobody ever actually goes and checks a certificate on a site.
I’ve seen banks that use SSL servers outside their primary domain.. It looked suspcious when I looked at the cert, but it was actually legit.
SSL serves two purposes – authentication and encryption. Very few average joe users know about the authentication part. Even if you served up the page in HTTPS, spoofing or faking out an average user really wouldn’t be that tough, I contend.
It’s definitely a user perception issue.
@beavis88: It’s not bad form at all. Encryption is damn slow, so it’s actually good form to make sure that encryption is performed only on what needs to be confidential. Encrypting the home page doesn’t provide any security for the processing resources that it takes up — everyone already knows what it looks like, and there’s no valuable confidential information.
@thelushie: +1
The real WTF, as another site may put it, is that they put a little lock icon next to the form so people can say “ooh, it’s got a lock, it’s safe” instead of looking for the more-appropriate lock icon within their browser application.
@esd2020: I’m talking about something installed on the user’s local machine.
You could easily install a made up CA cert on a browser at an internet cafe.
To be fair to the consumerist editors, the title of the post does include a question mark – so they’re asking if it’s true that chase doesn’t encrypt, not saying that they don’t…. right?
@tcp100: Well, yeah. I meant using WiFi at a cafe from your own computer. Obviously, if you have access to the computer, you could just install a keylogger. Duh.
Let me be clear: Let’s say I’m using the neighbor’s wifi. Because Chase’s login page isn’t encrypted, the neighbors could alter the page to steal my passwords and I’d have no way of knowing. However, if Chase’s login page was HTTPS like it should be, that would be impossible.
This is absolutely a security issue.
@neworiginals: Encryption isn’t THAT slow. SSL only uses public key encryption to pass shared secrets — after that, all encryption is done symmetrically, which is much faster. I don’t think plaintext log-on pages are the end of the world, but they aren’t a best practice and shouldn’t be thrown out for some extremely minimal performance gains.
@esd2020: True on that. But again we’re talking Joe Schmoe here.
I’d say that half the folks you could just pop up a new window with a fake IE status bar that shows the lock. They’ll see that, and blindly click away. The fact that people have been trained to think “little yellow lock = safe” is a problem to me.
If banks really want security, they have to move to 2FA.
@ratnerstar: Or, you could have a problem like BoA, where they have to redirect the user by the state their account is in. Granted, they only ask for the user ID, not the password at that point, which would suffice.
If load balancing is an issue, they could ask for the user ID first, then redirect to a secure page.
I’m going to guess though that maybe this has something to do with branding – several re-branded logins (maybe for ‘affinity’ cards) use the same login post. You’re right though, in today’s day and age, the cost of SSL as far as processing goes is pretty minimal.
@tcp100: We are going off topic. Just because there are many other ways in which passwords can be stolen, doesn’t excuse the fact that Chase is in the wrong here.
So maybe everyone will stop piling on the Consumerist editors now? The headline/description might not be 100% precise, but this is an issue.
Bank of America used to have a form like that on their homepage and it wasn’t encrypted either.
@neworiginals: It’s bad form because it generates panic stories like this one (and calls from co-workers), and because it exposes you to possible (however improbable) attacks, as others have pointed out in this thread.
As for “slow” encryption – what is this, 1999? It’s a red herring and a cop-out these days – there are much better ways to save money.
@Applekid: Agreed – that little lock icon only makes it easier for phishers to employ social engineering to unwitting victims.
As a developer experienced with secure web design this is a major problem on Chase’s part. SSL encryption is done for two reasons, site authentication, and data privacy.
By not using SSL on the home page they render the first purpose unused. This actually defeats the purpose of certificates entirely, as it could redirect to chase.mywebsite.com and I could have a certificate for *.mywebsite.com. This would prevent you from ever getting a certificate warning.
Internet Explorer 7 and Firefox 3 have gone to great lengths to make self signed “snakeoil” certificates harder to ignore to help combat the ever expanding phishing threat.
All that said, I’m not THAT alarmed by Chase’s actions. Anyone checking to see that they are on a secure site can insert https themselves. If I am going to a secure site I will put https on the URL myself. Otherwise I could be redirected to the wrong website, and if I’m not paying attention, could have the same problems.
Orchard bank (division of HSBC) had the same problem, but WOULDN’T even let you specify https. I started clicking login without providing any credentials to get to the HSBC secure sign on page with a login error. They have since fixed their site to at least allow https.
These companies need to upgrade their front end servers to handle the larger encryption load, and make sure their site designers never forget about the phishing threat.
Why was my comment deleted? It turns out I was correct. Eat it.
On the topic of Chase’s web banking, I recently started using a password database that can generate random passwords for you. I changed my password to a totally random one 50 characters long, and it accepted it no problem. I tried to log in again and the new password wasn’t accepted. I double and triple checked the new password, and it wasn’t taking it. I look at their password requirements, and it has to be like 12 characters or something. This gave me an idea, so I put the password in, modifying it slightly. Sure enough, I got in. It turns out that they silently truncated the changed password to 12 characters.
I should hope that a banking website would have better than Cracker Jack box levels of security, since, you know, there are hundreds of thousands of dollars that go through these things. Even World of Warcraft has better security – they recently started offering those OTP-like keychain passcode generators.
I keep my computer buried in the backyard with my two Rotty’s! And it’s unplugged!! Ha, you dummies! Beat that!!
Very good way to do it. This way your servers aren’t encrypting the home page for people who don’t have accounts. Encrypting the page for no reason just adds ever server overhead.
The Consumerist may not be IT experts but I am.
You’re going to tell me that when I post the form up to the webserver the data is encrypted immediately? Really?
The Microsoft Developer’s Network wrote about this once before. [blogs.msdn.com] Read that. Even if they’ve “plugged” this “hole” it’s still a problem.
I do this for a living. And I’m outraged at the nonchalant willingness to criticize the Consumerist blog for bringing this up, especially since Microsoft, the people who *make* the browser most of you used to write your comments, say that this is bad form. You accuse them of not doing their research…but you’re just as bad.
@esd2020: Your description isn’t the only way Man in the Middle attacks happen. That’s what makes them so beautiful, and why banks are scared of em’
Example:
You, like an idiot click a random link and go to a skeev web page.
That webpage requests all the data from the legit page and displays it, altering the form tag to include an AJAX request in the onSubmit that copies all the data from the form to an external database, then returns true, allowing the form to submit to the correct address, in this case the https website chase is using.
Regardless of whether you’re on http or https for the main form page has little effect on this type of attack. The only thing to save the user is being vigilant and checking URLs.
This is the real danger of a man in the middle attack, not someone intercepting shit at a cafe.
Phishing in a barrel.
The other half of encryption is authentication – how do you know you are talking to Chase? That is what certificates are about as someone explained above.
So if you are misdirected to a Phishing site, it could easily use a plain [] URL (completely unencrypted), grab the password, and then redirect to the https: site, maybe transparently.
The alternative is to check the target URL for the submit button (firefox has extensions for this), but with javascript, a lot of things can be sent without your asking.
But it’s OK because Chase will refuse to allow you to access your account online unless you have a magic cookie installed, and everybody knows that browser cookies are at the very forefront of internet security. It’s all part of their new program designed to keep people safe while simultaneously preventing them from paying their bills on time when they happen to be away from their home computer.
@floydianslip6: I should probably clarify that it’s not even necessary for this man in the middle scheme to FUNCTION, IE logging the user into the https pages. Simply an unsuccessful login error on the real page back to the user is enough to make the casual computer user just think “oh I typed something wrong”.
Not everyone is a computer ninja, that’s why the shits so easy.
Wachovia is set up the same way. HTTP form that points to HTTPS.
Wow, what a load of crap. This isn’t even news worthy.
Next up, Consumerist.com Doesn’t Encrypt Your Login Credentials?
Just wow… wow everyone, really… wow…
@tedyc03: Being an “IT expert”, it might be a good idea for you to do some research. Specifically, you said:
“You’re going to tell me that when I post the form up to the webserver the data is encrypted immediately? Really?”
That is a completely nonsensical understanding of SSL. The data is encrypted before it ever leaves your computer. Let me break it down:
1. You get the HTTP (unsecure) login form that posts to an HTTPS (secure) page.
2. You type in your credentials and hit the button to submit the form.
3. Your browser negotiates a secure connection with the HTTPS (secure) server.
4. Your browser encrypts your username and password and sends them to the HTTPS server.
Please do your research before claiming to be an expert.
What the ferk! I use Chase and thought my data was protected. However, after reading some comments it looks like it may be safe after all – who is right? So far no account breaches. But you never know.