Slashdot Mirror
IE Devs Criticize Bank Security Vulnerabilities
mrcaseyj writes "A post on the IE blog criticizes some banks for no longer using secure connections for entire login pages and only encrypting the password as it goes back to the bank. This prevents simple password sniffing but doesn't prevent a man in the middle attack from replacing the unsecured login page with one that has disabled encryption. This is especially a problem if you are using an unencrypted wireless connection such as at a coffee shop, because hackers can easily use the airpwn package to intercept the login page and steal your password. An easy remedy for when a secure page isn't available is to enter a bad username and password which usually brings up a secure page telling you to try again. But can you really trust your money to a bank that doesn't even offer the option of a secure login page?"
"But can you really trust your money to a bank that doesn't even offer the option of a secure login page?""
But can you really trust your money to a web browser and operating system that are the most hijacked in the world?"
There, fixed it for you.
Links goes to some 2 year old blog entry.
I always send a false username to get them to give me a secure page. I thought people were supposed to get smarter on security rather than stupider. Guess evolution is a pipe-dream...
Hotmail does the same thing.
The entire session should be secured. Bank account numbers, credit card numbers, transaction histories, information about billers and automatic withdraw dates etc. are easily sniffed.
Just because they can't get your password doesn't mean they can't get useful information about you. Sniffing out an online banking session could be a big jackpot for an identity thief.
"This is especially a problem if you are using an unencrypted wireless connection such as at a coffee shop"
Surely anyone who logs onto their bank site from a wireless connection in a coffee shop is just asking to get owned?
Personally, I wouldn't trust any bank whose security system relies on user supplied credentials. Any bank that does not supply its customers with an electronic hardware-based security token is not trustworthy enough to handle my savings.
Football Odds
I petitioned my credit union to force SSL on the entire bank website, complete with a few dozen signers (several of them with very large accounts). Shortly after the entire website is accessible via SSL only, with any HTTP page redirecting you to the homepage (SSL). Sometimes banking with a small credit union has its advantages.
I suggest everyone do the same.
Damn! This is like Rosie O' Donnell calling you fat and obnoxious.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
This same annoying tendency of banks has another artifact (it's probably not intentional). It typically prevents the user's password management scheme (like Keychain on Mac OS X and analogous 3rd party password managers for Windows) from working properly. Without a tool like this to support the effort, most people wind up using the same password for all their web logins, which exposes them to dramatically increased risk. (Bad guys can exploit this common human behavior by plucking username / password combinations from any arbitrary p0wn3d web site, and then testing them at all the banks.
If you mod me down, I shall become more powerful than you could possibly imagine.
... all of their http pages redirect to https pages.
Published Wednesday, April 20, 2005 6:44 PM by ieblog
Two thousand and five.
City bank used to dump paperwork (including statements) into the garbage. It did not take long before the mafia grabbed the garbage contract to use it as a gold mine.
Not encrypting full pages of login and transaction for financial transactions is cutting corners, which will hunt financial institutions big time.
I'm still waiting on my $2000 like new BMW.
Bush was President, we were at war in Iraq and Afghanistan, and Slashdot editors sucked.
Why should I really worry about security anyway they've either thrown away my information in a dumpster or were compromised...
Scott Trade
Verizon
Bank of America
Choicepoint
Mastercard
AT&T
Department of Edumacashun
Chase
Infiltrated dot Net
Ok, we NEED a new definition for irony that means like "irony^9999999" cuz I have no words to
/me heart attack
describe what I think.
Are they freaking serious? ARE THEY? ARGHH
I cringe a little whenever I visit a bank or CC site ans see .asp or .aspx at the end of the URL.
Why?
Great article, but WHICH BANKS are the problem?
I'd love to complain to my bank if it is guilty of these lapses, but how would I know?
I must admit, I was looking for the "potmeetkettle" tag. Given that it's not there, the first post mentioning something similar was good enough, I suppose
being vague is almost as cool as doing that other thing...
One of my credit cards is with a bank that uses this method of encrypting only part of the login page (URL is HTTP, login fields are claimed to be secure). I always enter one letter for my username and password the first time in order to force a login error, because the page that responds to the login error is always completely encrypted (HTTPS), and that's where I enter my actual login after I double-check that the URL didn't change to a man-in-the-middle.
One would think that banks are the cutting edge of technology.
The opposite is true. They lag behind by about 2 years in awareness, and 3 years in implementation of just about every web based thing imaginable. I got told yesterday by this cool new thing "RSS feed" (WTF a bank going to do with that on their site), oh, and they want to look at their "hits".
When faced with taking that stupid local weather bug off the home page and properly securing it to avoid phishing attacks, 80% of them choose NOT to secure to be able to show it's 68 degrees with chance of tornado in bumfark KS on the home page. (Which won't work in HTTPS mode so throws errors if the page itself is viewed in HTTPS mode.)
Lots of them also simply do not have the technical know how to do what they are doing, let alone understand stuff related to web sites. The IT is outsourced and the one college English major that once built a computer that runs the office on a daily basis is in over his head.
Big banks, they have the tools and the means and they do by en large do a good job. The small ones. Forget about it.
They're just file extensions buddy, they can't hurt you.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
Just put your money in your mattress and avoid all those newfangled bank things.
Happen not only to the money in your bank account,
but also to your personal data, for example
to using your user data to DoD the account
then you become a so called 'hacker' user trying
to break into your own money
?
I work with insurance companies on IT issues, and if it's anything like bank -- it's the same kind of business -- they suck hard at computer security.
Their password policies for acessing extranets, for instance, are in most cases completely insane. They impose so many arbitrary constraints (such as changing the password monthly) in the name of security, no less, that invariably passwords en up being "password1", "password2" and so on. Furthermore most of them block an account after three unsuccesful login attempts; apparently, those highly paid bozos have never heard of "DoS" since they upgraded to Windows 3.11.
None of the big companies I work with use PKI for authentification. I understand this could be problematic when dealing with the general public, but I'm talking extranets here.
I wonder how a MITM attack could do that..
Bank Boston are firm to give data to bigger customers than you.
I dont see any hackers breaking in such a security
but i see directives being called by some of their friends
and giving my private data...
?
While the article may be older than dirt, I'm glad the issue has been brought up, because many financial sites still haven't done anything about the problem. It always pisses me off when I go to my bank's or credit card companies' site and am confronted with a login prompt on an insecure page. To add insult to injury, they generally have put some sort of little lock icon next to the login fields. Oh, well great! That must mean it's secure!. I mean, surely no phishing site will think to put a lock icon next to the login prompt. Of course, you don't really know that it's secure or who it'll be sending your password to until after you hit the button to send your password.
Now, obviously, there are ways of dealing with this (as the blurb notes), but it's a pain in the ass. The bigger issue is that most people probably don't know it's a problem and don't know how to deal with it, and it gets people in the habit of really bad behavior, submitting a password on an insecure connection. This all seems especially crazy in view of the fact that bank sites will implement things like Sitekey and yet still use these insecure login pages. It seems that the fix is easy, why do they do this? Does it save them a lot of money to cut down on the SSL connections?
"You call it a new way of thinking; I call it regression to ignorance!" -- Operation Ivy
I have worked with computer programmers who think they know how to write secure software, but don't. They know maybe one or two basic principles, and think they have it all figured out. I call this the "well no one told me" phenomenon.
Not every IT professional wants to spend lots of his free time researching the latest means of breaking into something, and defending against the break-in. So a lot of people just don't go out of their way to find out if they really know enough to write secure software...it is easer to assume that one's current knowledge is sufficient and to let one's employer take the heat when something surprising comes up.
Furthermore, employers don't like sending their employees off to training which ultimately will not increase their bottom line, and which may not even turn out to be necessary at all (after all, he DOES believe he can write secure software...). Worse yet, employers don't want to hire people to try to hack into their site, seeing as how that costs a lot of money and time too, and there is no guarantee that the third party actually tried hard.
The end result is quite predictable: insecurity all around.
The ATM is Diebold! Jesus, I'm taking all my money out of the bank and stuffing it in my mattress!!
Reduce, reuse, cycle
Yes, I'm aware that it should be the kettle. But in this case, that wouldn't do justice to (most) banks.
For almost all successful bank frauds here, the culprit was a trojan in the IE. Banks do hire very good people to secure their online money transfer routines (at least here, cannot vouch for the US). What fails, though, is the security on the user side.
Faciliated by IEs way of treating plugins. To slip a plugin into the IE, all you have to do is set a few registry keys. It does not even need any user interaction. So it's very, very easy to infect the IE with a malicious plugin. And those plugins are quite powerful. The IE does allow them to intercept, alter, drop or fabricate content on the fly, after decryption but before display (or, in the other direction, before encryption and sending to the other side). In other words, creating a trojan that alters the entered information the bank gets from you, or the information you get from the bank, is quite trivial. To make matters worse, this trojan can use the IE to send information to its creator, with the firewall noticing the IE trying to pass, which is usually allowed.
And behold, it's been done.
What it worth if you have the best, most secure and tightly encrypted connection, when your data is already being manipulated on the machine used for the input?
To me, this sounds like a half-assed attempt to shift the blame, somehow. But ask anyone from a bank, they will tell you (if they are allowed to, NDAs can be a bitch in the financial sector) that almost all successful phishing attempts are due to infected user PCs, and the majority of those infections rely on slipping a spy into the IE.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Must be a glitch in the matrix. This content is only 10 hours old.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
You're doing it wrong--http://youredoingitwrong.mee.nu
Recently I tried to purchase some clothes from Hanes.com, a company most Americans will be very familiar with.
As it turns out, all of the forms they send to your computer are encrypted. None of the data you send them back by filling out such forms are encrypted. Account logins, billing address, shipping address, card details - they all go plain text according to Firefox. I contacted Hanes customer support twice about this, only to be told that they use "industry standard encryption". "Yes", I said, "but only on the pages you send to my browser, not on all the data my browser sends to you". Months later they still have not fixed it. I even contacted the FTC, but they obviously have done nothing.
Go to their website, and try to log into an account using any user name and password, and Firefox will instantly warn of the problem. It's ridiculous that in this day a) major companies have this problem and b) they ignore the problem when people bring it up. They deserve a class action from anyone who has ever ordered through their insecure website.
My bank, who I also happen to work for, has this problem still. You can login to their "Internet Banking" to look at your accounts from their main page (plain old HTTP). I did find that if you click on enough "Internet Banking" links from that page instead of logging in, you will eventually get to an HTTPS page where you can login to the same "Internet Banking" services. They should just only have a login link on their main non-SSL page to the HTTPS page but, then again, I'm not too surprised, being an employee of the company. Unfortunately, I work on the back end (mainframe) where security *is* tight as a drum. I couldn't possibly have any say or even make any suggestions to an area of the company like web development though. And you wouldn't believe the b.s. we go through at this company when it comes to change management *shudders*. Yeah, they make a big stink on that main non-SSL page about how your ID and password are protected with SSL "the second that you click Login" but would it be so hard to just replace that main page login with a link to the real SSL-enabled login page. Oh, and their login, of course, doesn't work with password management like Keychain or Firefox or anything since it's some chunk of JavaScript code. Just another annoyance.
Of course. One of the prefab Apache+PHP deployments uses .aspx (score one for security by obscurity).
Ignoring any issues IE, or any other browser for that matter, may or may not have with regards to security the developers make a fair remark. In many ways this is like offering a high street bank the best cameras and locks only to have them not used. Browsers offer methods of data encryption that help provide security, but if the bank doesn't use them it doesn't really matter what was provided, it does matter, and cause concern, that they don't use them.
The other issue is that public wireless networks (the ones where you don't provide a key) suffer from is the fact that over the air encryption is almost zero. The ideal solution would be a randomly generated public key/private key solution for these types of networks. Certainly this does suffer from the issue if the attacker was there when the connection was established, then they will have both keys, though this does reduce drive-by attackers.
When dealing with important data such as banking, it is important to have the right security at every level. It is the layering of security systems that make it harder for the attcker to get at you information. You leave one part out of the system and they potentially have a side-door to getting to your information.
Jumpstart the tartan drive.
You trust bankers at all? WTF? Bankers are the scum of the earth.
The banking system we have just now, the world over is the single largest scam ever created[1]. And it's backed and enforced by the various governments. Most people have no idea how our money and banking system works, they still think it's backed by gold or something. What bankers do, is take your money, invest it at a healthy rate of return and then give you marginally more than the rate of inflation, if they're feeling generous, less if they're not and they're usually not. Then they charge you for the use of your money!
Here's a hint. Avoid banks like the plague. Keep your value in some commodity other than money, have a small bank account or two with just enough cash to get by.
[1] Look up fractional reserve banking.
Deleted
the way most web sites use ssl is hardly secure.
The ssl handshake process compares the dns resolved hostname in the url against the hostname in the cn of the downloaded cert. If you can't trust the dns server provided by your gateway, i.e. because you are using the free wifi access in the airport in Tel Aviv, then it is possible, and highly likely in some locations, that your https traffic is being watched.
Secure dns, and then ssl might be secure. http://it.slashdot.org/it/05/12/07/1640224.shtml
Those banking web sites are awful also because they require JavaScript to be enabled. They force me to open up my browser to all JavaScript-based attacks.
My quick testing of a few sites that look like they allow clients to log in via non-https forms:
Wachovia.com
Chase.com
citicards.com
CitiBank.com
usbank.com
WaMu.com
hsbc.com
Banks/Entities that redirect to HTTPS:
Bank of America
Schwab
E-Trade
WellsFargo
CapitalOne
USTrust
NetBank
ebank
BBT
INGDirect
SunTrust
UBS
Key.com
Have any more to add?
And then, all the other banks did the same to keep up with the Edward Jones'.
For example, check out: http://www.gomez.com/Performance_Strategies/benchm arking/benchmark_cabanking.html
It's all shenanigans really, but it's a shenanigan that is hard to explain to MBA graduates and senior executives!
PS: Yes, the article is ancient -- I thought we had all given up on improving information security for online banking.
Banks have a much bigger problem than this. With the amount of spyware out there and the almost total lack of understanding of what vulnerabilities this exposes, probably more than 1/3 of the passwords and account details are known by Black Hats.
There are many ways to slip money out of accounts it isn't funny.
Trading accounts:
Create a series of bad trade orders. Offset these with legitimate trade orders in legitimate accounts. There are many thinly traded companies where it is easy to figure out who has the buy order and who has the sell order. All one has to do on a thinly traded company for instance is place a lowball buy order and have the victim's account buy shares at whatever price and then sell them into the lowball. This can be triggered from instance by a stop loss order. Once the shares are owned they can then be sold to another victim.
Chequing accounts: Create fraudulent transactions by paying for goods not ordered. These goods can even be shipped to create a semblance of legitimacy. By the time any of these goods arrive and the transactions are noticed the perpetrators are long gone with their loot.
Its quite easy to create a series of dummy companies to accomplish this. Of course, since this is e-commerce one would obtain valid certificates ahead of time.
This is one reason that secure communications offer limited protection. A felon in Jail can always get his lawyer to register a corporation for him and these are legitimate corporations. Its just they are run by crooks. But then Enron was run by crooks too it would seem. In fact, there are a HUGE number of companies run by crooks. Lots of people invest in them.
These really are just a few of the many many things we do to protect your data. In fact, I deleted 2 of the list items that I originally wrote about because I didn't want to give away any information that could be useful to a potential crook.
We take security very seriously for two main reasons. First, we're liable for any losses you have due to a security breach. But more importantly, we can't afford to lose the faith of our customers. If they don't trust us they'll take their money somewhere else. The actual financial loss from an attack on our system would be minor compared to the loss of trust from our customers.
Tor is for many things. If you are concerned about your ISP or local users sniffing things(i.e. you are on an unsecured network and there are local attackers), then Tor will help you. For example, you may not want people upstream to know that you are connecting to bank X. Tor can help there. You should be using SSL/TLS to your bank anyways, so using Tor doesn't hurt. The problem(the one the story is about) with the banks is that they make it hard to make this determination. The phrase "route directly" makes no sense by the way.
Every time you need to supply your credentials, you fist get presented with a regular http page. For years I've been leaving the password empty and hitting return so I can get a full SSL page. They still don't get it. Yahoo! at last made the transition to a full https login a few months ago - kudos to them.
Imagine I "root" Bob's computer and redirect it to my evil website everytime he tries to go to www.somebank.com. Now I make my evil website to look exactly like www.somebank.com and, when Bob enters his credentials, I log on from my evil site to the real bank's website. This works even if Bob's somebank is using a "secure token" generating one-time (time-based) login token (because I can immediately use Bob's token to log in the real bank).
This attacks works and has been seen in the wild, it's a fact. What's the name of such an attack? (As long as I'm "admin" on Bob's computer, I can make his browser do anything I want, including displaying shiny SSL icons / whatnots). Is this some kind of "Man In The Middle" attack? Note that I want to emphasize once more that this attack has been reported in the wild and that no amount of SSL is helping once the user's machine is compromised (and with estimates of tens of millions if not hundreds of millions of compromised machines, this is a real problem).
There are even people that only ever use read-only "Live CDs" (say from a spare computer) to connect to their bank's website. They could still theorically get rooted should their Live CD be insecure, but it's still, altough not physically impossible, very improbable that they would get rooted by someone preparing to defraud them from their bank.
Once people realize this attack is working and that we live in a world where "pwning" other people's machine is a fact (and not just for Windows OSes), the only real security measure preventing this is for the bank to mandate the use of the physical "security-token generating" device to validate the number of the account you're transferring money to. Once people are trained to always enter the account number they can't be "cheated" anymore. Some european banks use this when transferring large amounts of money. But this still doesn't tell me what the name of the attack is.
To me it is some kind of MITM and no amount of SSL prevent this kind of MITM. But a el-cheapo physical device (like the one I've got on my desk, writing you this from Europe) completely stops this attack once and for all (and it also stops many other attacks besides physically stealing the device [and its associated PIN] generating the token, or breaking crypto [*] or breaking into the bank's servers).
[*] In which case the world at large is in trouble of big chaos.
How dare you make an informative post based on real facts? This is /.!!?!
Also, I think TFA may be conflating MITM with phishing. I'd like to see how many frauds have been really been succesfully perpetrated using real MITM (with contact back to the bank for something otehr than static content, as opposed to plain old phishing), It's not hard to set up a phishing site with a "real" SSL cert from some dodgy issuer, I've seen LOTS of those.
Still I'm a little baffled why MOST sites have non-SSL login pages - it's not like the login page is more than a fraction of their total content delivered, most of the sites are butt-slow anyway, and it's actually easier to just bag the whole site in SSL than it is to do bits and pieces. There's got to be some explanation, even if it is a lame one like "That's the way BEA works out of the box" or something.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
the man in the middle can always present fake login page in HTTP, or in HTTPS from a phishing host. if you assume a man in the middle and a careless end user, there is nothing you can do. I have to admit I don't check the address bar every time I log in to my bank account. if you do, you must be a really paranoid person.
I had a fully encrypted account login page bookmarked and used it, and at some point in the future they add an encrypted login area sections to their non-encrypted front page. I ignored it because I preferred to use the old page I had bookmarked. Several months later I got a message after logging in that I was using an old version of the login page that would be going away soon, and to start logging in from the front page and change my bookmarks accordingly.
I ignored it, and now, several more months later, the old page is still there. I'm not being told its going away like I was. Seems a few other customers expressed some displeasure at the change.
Seriously, do you go to the trouble of reading the security certificate of a page every single time you log on to it and verifying that the issuing authority is someone you trust?
And even if you do, how many regular users do you think do the same?
Certification isn't completely pointless, but it's just as vulnerable as any other security mechanism to careless users and dancing pigs.
Some banks have addressed this problem by employing Extended Validation SSL. That's the new kind of SSL that causes the address bar to turn green in IE7. I understand other browsers are on the way, including Firefox 3. Not only does IE show the green address bar, but it also lists the name of the organization. So for example, if you go to ING Direct in the UK (ingdirect.co.uk) and go to the login page, it says "ING DIRECT" right in the browser's chrome. I've seen this on other banks like Fifth Third as well as a bunch of e-commerce sites like eBay and Travelocity. From what I've read the name of the organization is authenticated, meaning it would be very hard for a phisher to get a cert with this bank name on it. If every bank got green bars and everybody got an EV compatible browser (with Firefox on the way it's not such a crazy thought), then the basic "your-account-is-frozen" phish that is so prevelent today would be rendered largely ineffective.
I'm not really sure how that solves the problem I was talking about. My complaint is when a bank has the login prompt on a page served up with http, not https. The SSL connection isn't made until you hit the button to submit your password, at which point it's a little late for authentication.
What you seem to be talking about is a mechanism by which the browser makes obvious changes in appearance when it connects to certain sites via https. If they're not using SSL in the first place, I don't think this will help. If they are using SSL, then most browsers (AFAIK) have a way of visually notifying you (a yellow address bar or a lock appears in a certain spot in the browser, not as an image on the page). I do think it's a good idea, though, to make it more obvious to the end user when the connection is actually secure.
"You call it a new way of thinking; I call it regression to ignorance!" -- Operation Ivy
In Scandinavia all banks combine the username and password with some sort of third option. Examples:
1.) My own bank requires a key-file (token). I can only log on to the system from computers with access to the actual key file. I have it on my notebook and that is sufficient for me. I can't log in to the system without the key, but I guess I could bring it along on a USB stick if I really needed to. No key-file, no access.
2.) The bank my best friend uses has an SMS based system. When he wants to access the bank systems he receives an 8 digit number valid for only 5 minutes, which must be entered on the logon page along with the username and password. Without his mobile phone he can't access the bank system - but hey: that goes for all the nasty guys as well.
3.) Some banks provide their customers with a stack of "one-time-only" login keys on small paper cards. In addition to their username and password customers have to enter a bunch of matching numbers from one of the cards. No valid card, no access. Once used, the card is thrown away.
All these alternatives are relatively cheap to implement, and require no expensive/fancy electronic tokens. Why are these methods of additional security not widespread in the US?
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
How about all the sites that require Flash. Just what we need, an even bigger vulnerability than the already bad JavaScript. JavaScript was supposed to be secure and turned out not to be. Are we supposed to believe that Flash, which has even more features, will be secure? Did we not learn our lesson the hard way the first time? Does anyone else think it's crazy to let any website you visit, run programs on your computer, even if they're supposedly sandboxed? Didn't we learn the first time that the sandboxes don't work?
But it's not just Flash and JavaScript. Even Ubuntu, which likes to claim good security, comes configured to launch a movie player in your browser when you visit a site with video. Now you are exposed to vulnerabilities in you video player too. Pdf viewers are sometimes configured to launch automatically also. But pdf viewers are complex and have had vulnerabilities as well. The list goes on.
Web browsers are the biggest vulnerability for most systems. They should be configured by default to only allow a restricted subset of html to be rendered. Web designers should be strongly discouraged from implementing fancy stuff unless it's really valuable.
In addition, operating systems should include a chrooted copy of the web browser, separated from the users account and overwritten at every reboot, so that if they are compromised, the users home account won't be.
But you're comparing IIS6 to ALL versions of Apache (including 1.3.x, do you know how old that is?). This would be like comparing every version of Linux (from 0.0.1) to only Windows Vista, which isn't fair by any comparison.
Take your FUD somwhere else please.
Why, yes! I AM new here.
Ensuring the security of your personal information online is important to us. When you log in to Online Services on our home page, your User ID and Password are secure.
The moment you select "Login," we encrypt your User ID and Password using Secure Sockets Layer (SSL) technology. I don't understand. If the login page isn't SSL, how can the password be encrypted with SSL?
Nope. The initial database passwords were sniffed using a long range antenna after cracking a single Marshalls store's obsolete WEP setup. They could have done this from anywhere within 1/2 mile of the store, probably.
After the bad guys got what they needed they split, and they were long gone by the time the scope of the disaster became apparent.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"