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
-
Airbnb Cancels Reservation Because You Don’t Want To Post A Video Of Yourself
-
Bank Of America Jumps On The Simple Checking Fee Disclosure Form Bandwagaon
-
Blogger: Virgin Mobile Accounts Are Vulnerable To Hack; No One Seems To Care
-
Chase Customers: Did The Bank Ever Re-Open Your Closed Account?
-
Chase Won't Stop Calling For My Dead Mom Every Day At 4 A.M.
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.
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.
@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.
@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?
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.
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.
Your password and login is encrypted as stated above. Just view the page source, it’s being sent over SSL.
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.
@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.
@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.
@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.
What would be the problem with just forcing the site into secure mode from the homepage or any other page directly accessed?
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.
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]
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.
@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.
Discover does this too.
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?
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.
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.
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.
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.
s/sites do/sites that do/
s/scren/screen/
Yeesh.
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.
@rdude: even an HTTPS page can information injected to it on your local PC. HTTPS doesn’t mean it’s completely secure at all.
@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.
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?
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)
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.
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.
[www.chase.com] forwards me back to the insecure http page. High five.
@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!
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.