Chase Doesn't Encrypt Your Login Credentials?

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.

Comments

Edit Your Comment

  1. howie_in_az says:

    Um, submitting the form sends the data to an HTTPS page. The home page isn’t encrypted, nor does it need to be.

  2. Jbball says:

    Great and I have a Chase credit card…. which they refuse to lower my APR. Bye bye Chase.

  3. tcp100 says:

    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.

  4. tcp100 says:

    @Jbball: Reading is awesome, all the cool kids are doing it.

  5. festivus802 says:

    you can also use this URL to go directly to the logon page with https encryption: [chaseonline.chase.com]

  6. admiralguy says:

    Agreed. This story is inaccurate. Just tested and confirmed that their login is secure.

  7. Wormfather is Wormfather says:

    Nothing to see here, everyone move along.

    Still thought the https vs http info is good for people who may have not known.

  8. ChrisC1234 says:

    Consumerist, do your research first. The data IS submitted over HTTPS, and it IS secure.

  9. rdude says:

    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.

  10. esd2020 says:

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

  11. bradanomics says:

    “We’re not IT experts or anything”

    Then don’t report on things you don’t know about.

  12. IamTCM says:

    Want to see something funny? Check out [secure.myspace.com] and yes you can even look at the action form there.

  13. thelushie says:

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

  14. Juliekins says:

    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.

  15. phripley says:

    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]

  16. zigziggityzoo says:

    Scottrade does the same thing.

  17. Juliekins says:

    @FitJulie: Ugh, and take the dot off the end of that link. [chaseonline.chase.com] should work.

  18. Jesse says:

    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.

  19. esd2020 says:

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

  20. tcp100 says:

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

  21. fargle says:

    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.

  22. Angryrider says:

    Now this would be hilarious if this kind of stuff happened with Wamu. Those stupid commercials infuriate me, “guaranteed protection thingy or something.” YARGH!

  23. esd2020 says:

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

  24. tcp100 says:

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

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

  26. Applekid ┬──┬ ノ( ゜-゜ノ) says:

    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.

  27. tcp100 says:

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

  28. hills says:

    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?

  29. esd2020 says:

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

  30. ratnerstar says:

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

  31. tcp100 says:

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

  32. tcp100 says:

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

  33. esd2020 says:

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

  34. Mozoltov, motherfucker says:

    Bank of America used to have a form like that on their homepage and it wasn’t encrypted either.

  35. beavis88 says:

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

  36. selectman says:

    @Applekid: Agreed – that little lock icon only makes it easier for phishers to employ social engineering to unwitting victims.

  37. AustinTXProgrammer says:

    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.

  38. Dobernala says:

    Why was my comment deleted? It turns out I was correct. Eat it.

  39. Mr_D says:

    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.

  40. Juggernaut says:

    I keep my computer buried in the backyard with my two Rotty’s! And it’s unplugged!! Ha, you dummies! Beat that!!

  41. Concerned_Citizen says:

    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.

  42. tedyc03 says:

    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.

  43. floydianslip6 says:

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

  44. tz says:

    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.

  45. khiltd says:

    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.

  46. floydianslip6 says:

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

  47. asynja says:

    Wachovia is set up the same way. HTTP form that points to HTTPS.

  48. pragakhan says:

    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…

  49. rdude says:

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

  50. andys2i says:

    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.

  51. bigosmallm says:

    I think people are missing the main point here. A normal user does not know what happens under the covers. Yes, this website might be encrypting the form data, but what if it didnt?

    This is what I do when I visit these online banking sites. In the main page login, I ALWAYS deliberately enter a wrong user id and password. The form will get submitted and will get redirected to another page with an error message. I check if the new page contains “https” in its address. This way I am reasonably sure that my login information will get encrypted when I enter it in the form.

    I started doing this to avoid phishing websites taking advantage of my misspelling of a bank website’s url. But it turns out to be a good way to find out if a site is encrypting the login credentials or not.

  52. mannyv says:

    All those people complain that the site isn’t secure are full of shit.

    Sure, you -might- get a man in the middle attack. But you might also have been hacked and the hacker installed a keystroke logger and is grabbing all your typed information. BFD.

    A big block of blue ice -might- smack you in the head one of these days, so be sure to wear your hard hat around when you’re outdoors and inside wood buildings.

  53. esd2020 says:

    @floydianslip6: Yes, I know that. The solution there is not to be an idiot and click random links that claim to take you to your bank.

  54. esd2020 says:

    @mannyv: Yes. There are many ways in which bad guys can attack you. But how does that excuse Chase from adhering to some pretty basic best practices?

  55. AndyDuncan says:

    Lets say Chase did force HTTPS via a redirect. If my DNS is compromised, when I type in “www.chase.com” I’m never going to have a chance to be redirected to “https://www.chase.com”, I’ll be sent directly to the phishing server. So the fact that the real chase server is redirecting to the secure version automatically is irrelevant.

    However it would, I suppose, prevent a true Man-in-the-middle attack where the content of the page alone is modified in transit. But not a man-in-the-middle DNS attack, which would be just as easy to do anyway.

    To those who are saying that SSL is a lot of overhead: Chase is big enough that they are likely using Load Balancers that could do the SSL with little-to-no added overhead.

  56. keith4298 says:

    You obviously don’t have a chase account. Having my user name and password won’t help you much. When you log in from a machine that you have never used before, it comes up with a screen asking you where you want your authentication code to go. It offers you a choice of a txt message to your cell, an e-mail or a phone call (that they already have on file and give you the last 4 digits of each to choose from).

    They then provide you with the code to enter in order to get on their site.

    While I find it annoying (espcially since I have to do it EVERY DAMN TIME on my iPhone), having my user name and password wouldn’t be of much use to you without also having my cell phone or e-mail account.

    Nevertheless, I’m not as insane as that guy that plastered his SS# on the internet….I don’t don’t trust Chase THAT much.

  57. CharlieInSeattle says:

    Your password and login is encrypted as stated above. Just view the page source, it’s being sent over SSL.

  58. CharlieInSeattle says:

    Look if you don’t believe it’s encrypted when posted to the server. Go download wireshark, and do a packet trace. Now can you read anything in that transaction? Nope.

  59. scottywz says:

    @Mr_D: “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.”

    A bit off topic, but these length requirements on passwords are stupid at best. Longer passwords are better because they’re harder to crack. Having symbols in your password is even better for the same reason. The fact that major banks don’t realize this is scary.

    For example, BoA has a 20-character limit and doesn’t allow symbols. When I saw that, I had a 23-character password with $’s and @’s and it wasn’t accepted. My current bank is even worse: 8 CHARACTERS MAXIMUM!!! What the hell?! Well, at least their login form is encrypted, even if it’s just (weak) 128-bit encryption.

  60. howie_in_az says:

    @scottywz: Some variations of Unix (specifically the ‘crypt()’ function) don’t honor passwords over 8-12 chars. I think I’ve encountered at least one Java library that silently truncated passwords (pre-salted) over 8 chars. It all depends on which cryptography library they’ve decided to use, and usually that’s out of the developer’s hands because someone higher-up will say “we bought a license for this, you will use it”.

    I’m not totally sold that a 14-char password of “quickbrownfox” is better than an 8-char password of “W@w!k00L”. I’d also imagine that if one insisted on 14-char minimums on passwords, one would be dealing with a lot more “I forgot my password” calls/emails.

    As for ‘weak’ 128-bit encryption, to the best of my knowledge no one has cracked a 128-bit key.

  61. tedyc03 says:

    @rdude: Did you happen to bother reading the supporting documentation I provided from Microsoft? Redirecting of the post by an attacker would allow them to see the contents. Not secure. You want to ask a few hundred more experts they’ll say the same.

  62. What would be the problem with just forcing the site into secure mode from the homepage or any other page directly accessed?

  63. rimclean says:

    it is the same at wamu.com when I emailed them they told me the front page doesn’t need to be encrypted because it is a public page. I replied and said that as a general rule people are taught not to enter personal data into a page that is not encrypted (as indicated by the browser). They told me to go to online.wamu.com instead which is encrypted.

  64. hallam says:

    I just checked the chase homepage and it now seems to have a redirect to an https URL.

    This is in line with the best practices recommendations of the Anti Phishing Working Group for login pages.

    The security objective behind the certificate is not merely to encrypt the password on the wire, it is to make sure that the user only supplies it to the bank. So using an SSL certificate on the page where the password is solicited is just as important as on the form target page.

    ObDisclaimer: I am a security specialist and my employer sells SSL certificates. I also have a book on stopping Internet crime – [dotcrimemanifesto.com]

  65. hallam says:

    Correction – I went to the chaseonline page, not the chase.com page.

    I know the chase director of security and will raise the issue with him.

  66. rdude says:

    @tedyc03: I’ve read that many times. If you look at my previous comment, I talk about how this allows a man-in-the-middle attack. Regardless, your original statement that was quoted in my previous reply still makes no sense.

  67. krom says:

    Discover does this too.

  68. CharlieInSeattle says:

    When is consumerist going to change the totally mis-leading title of this article? As the title stands it factually inaccurate. Or does consumerist have lots of money and expensive lawyers to fight libel suits?

  69. Quatre707 says:

    If you ever visit a website which should be secure, but isn’t, simply type in a random username and password and submit. You should be redirected to a properly secured page with an encrypted connection.

    I’ve seen this happen with Chase’s homepage, Amazon’s transactions page, and several others in the past. It doesn’t neccessarily mean the data you send is in the clear though.

    Web sites can be setup so the form data (in this case the username and password) are not submitted in the initial connection, and instead are left sitting in the user’s computer memory until the request for a secure connection is sent back from the web server.

    I disagree with doing this as it makes the user feel insecure, and they really do not know what is encrypted unless they sniff their own outgoing traffic, but perhaps there is a positive reason on the web site administrations part.

  70. digitalgimpus says:

    The form is technically secure, so your data likely won’t be intercepted.

    I still prefer to have the actual page served over SSL, since that helps prevent man-in-the-middle attacks since you can check the SSL cert before sending data.

    [chaseonline.chase.com]

    That url works correctly, and is the one I use, and recommend others use.

  71. bwcbwc says:

    Several financial sites I deal with do this (GMAC Mortgage for example). Because of the (small but still possible) risk of the hijacking, DNS poisoning and man in the middle attacks mentioned earlier, I only bookmark the HTTPS login pages. I’ve found that if I hit the login button with blank information, it will usually take me to the fully secured login screen/form, and a login failed mesage. That’s what I then bookmark for future use.

  72. bwcbwc says:

    BTW, I think the sites do this on their home pages are trying to have it both ways. They don’t want to do a full encrypted connection unless the user actually logs in, due to the overhead of handling SSL traffic, but they want to provide a convenient direct login from their homepage for their customers. They probably should just have a big button on the home page that says “Access my Accounts” that takes you to the SSL login scren. Most people will probably bookmark the login screen anyway, so there is only the one extra mouse click the first time someone logs in.

  73. bwcbwc says:

    s/sites do/sites that do/
    s/scren/screen/
    Yeesh.

  74. Rectilinear Propagation says:

    Boy, nothing brings out the arrogant snark like a tech post. Yeesh.

    @asynja: I saw that too a while back. It may only be warm & fuzzies but I also do what FitJulie does and have the ‘https’ address bookmarked.

  75. digitalhen says:

    @rdude: even an HTTPS page can information injected to it on your local PC. HTTPS doesn’t mean it’s completely secure at all.

  76. digitalhen says:

    @digitalhen: and this was with the real certificate, and no apparent hacking attempt. it was only spotted because my dad saw extra fields in the form.

  77. tundey says:

    There’s nothing wrong with the chase site. Unless you want them to use HTTPS exclusively for their entire site or to remove the login form from the main page, there’s nothing they can do when a use goes to “http://www.chase.com”.

    In any case, as long as the forms posts to an HTTPS site, there’s no security risk. In fact, one could say the greater risk if they had reversed their implementation i.e. host the form on an HTTPS site but post to an HTTP site. Then you’ll have your padlock and still be insecure.

    BTW, doesn’t Internet Explorer alert the user when a form is posting to an unsecured location?

  78. Chune says:

    Blame Gomez (www.gomez.com)

    This is a classic example of ‘you get what you inspect, not what you expect’. Gomez provides performance statistics for the download time of many (most?) financial service institutions.

    Forcing the encryption of the main page causes a very slight performance hit but few people have figured out how to explain to senior business leaders that the reason why their website is “slower” is because it is more “secure”.

    Business leaders are managing their Gomez performance times and have had to sacrafice secure home pages as the result. The flip side is that this is much less secure (as others have stated) because while the contents are being submitted securely, you don’t have any indication on the main page whether or not the domain name is correct for the company you are trying to connect. ie: chase.com vs. checkyourchasemortgage.com won’t present a Green/Red SSL prompt in IE. By the time you submit your login credtials, it’s too late to notice that they went to the wrong site, or weren’t going to be submitted securely.

    (That Green/Red thing is a separate hot topic of mine, in as much as it is a scam for verisign to sell “super expensive” SSL certificates but I’ll save my diatribe on that for another day)

  79. stre says:

    if you want to feel super secure, just don’t fill anything out and click “Log In”, which will take you to a “https” page and ask for your credentials. not being a hypertext transfer protocol wizard myself, it’s what i’ve been doing. you know, just to be on the safe side.

  80. compulsiveshouter says:

    Someone tell me why I can’t use special characters in my chase account password. This smacks of sloppy programming.

    Chase credit card accounts have to have simple alphanumeric passwords and there’s no good excuse.

  81. thefastest says:

    [www.chase.com] forwards me back to the insecure http page. High five.

  82. coren says:

    @CharlieInSeattle: How are you misled by Consumerist asking if Chase doesn’t encrypt credentials? Are they not asking a question? Does it not, on the surface, appear otherwise?

    @bradanomics: That’d make for a pretty small blog – there shouldn’t be an expectation of expertise on every subject matter.

    @Dobernala: It was inadvertent – see the post itself.

    @thelushie: Yeah, making a page highly vulnerable to mitm attacks sounds like nothing to be concerned about!

  83. pbwelch says:

    Chase Credit Card…My experience with someone logging on to my account…Last week I was hospitalized and was nowhere near my computer. That evening when I logged onto my Chase account I noticed that the last login had been at 2:30 that morning…while I was away from home. After much haggling with them I learned that indeed a card had been requested on that date. They wouldn’t tell me anything else, but immediately closed the account and are issuing me new cards with a new number. I did not receive the card that was requested on the date my account was compromised, so I can only assume the individual had it sent to another address.