Major Security Holes Found In Mobile Bank Apps 107
NeverVotedBush writes with this excerpt from CNet:
"A security firm disclosed holes today in mobile apps from Bank of America, USAA, Chase, Wells Fargo and TD Ameritrade, prompting a scramble by most of the companies to update the apps. ... Specifically, viaForensics concluded that: the USAA's Android app stored copies of Web pages a user visited on the phone; TD Ameritrade's iPhone and Android apps were storing the user name in plain text on the phone; Wells Fargo's Android app stored user name, password, and account data in plain text on the phone; Bank of America's Android app saves a security question (used if a user was accessing the site from an unrecognized device) in plain text on the phone; and Chase's iPhone app stores the username on a phone if the user chose that option, according to the report. Meanwhile, the iPhone apps from USAA, Bank of America, Wells Fargo, and Vanguard and PayPal's Android app all passed the security tests and were found to be handling data securely."
Re:iPhone win? (Score:5, Insightful)
This is not a platform battle. The banks clearly take shortcuts or hire developers unfit for the task.
Maybe the iPhone developers also developed the Android apps and were not properly educated on Android development (just a thought).
Standard Banking Client (Score:3, Insightful)
I wouldn't trust those banking apps to not rip me off or expose me, since they're made by the banks. The banks are untrustworthy.
What we need is a standard for consumer banking transactions with any bank server. Then a single client could connect to multiple banks, or to a single one even when it changes its style and services. I would install the banking client app that I trusted and preferred. One view of all my finances, including my IRA, insurance, mortgage, savings, checking, stock market, even perhaps debts owed to/from individual people. In fact I'd like such a client to keep a database of all my financial transactions, including all bills. I'd like it to keep records of every "automatic withdrawal". I'd like it to use my phone to alert me to deposits and withdrawals if I wish, including "OK/Cancel" per transaction. I'd like it to lock each payment with a one time password it generates and sends, instead of using my credit card number in the clear all the time.
Some desktop apps, like Quicken, already do some things like this. But it's time that all my finances are handled by an app I trust that doesn't come from the server that has an interest conflict with me in reporting transactions, that is simple enough without lots of "financial planning" baggage necessarily coming with it. This has been true for email and websites for decades, as well as every other successful kind of info transaction over networks for even longer. It's long past time to leave the consumer side of the banking to businesses actually in the business of serving consumers. Banks are not in that business, haven't been in a long time, and show less and less real interest or reliability in returning to it.
Re:This is an Android App Security Story (Score:3, Insightful)
Apparently you can't read, since there at least two iPhone apps in the insecure list (granted, there were four Android apps in the list, and only one Android app that passed vs 4 iPhone apps).
It seems more likely that, for whatever reason, iOS financial app developers tend to be more diligent than Android financial app developers.
It's still bad for Android, but not the same kind of bad. And it certainly doesn't warrant changing the summary title given the fact that iPhone apps are insecure as well, and the problems are related to how the Apps were developed, not the OS's themselves.
OH! OH! I know! Pick Me ! (Score:5, Insightful)
... for the same reason that there isn't a little box to write your PIN number in on ATM cards. If you offer people a less secure but simpler alternative then many of them will use it out of shear, if understandable, ignorance of the implications. Since leaving your username information "laying around" is a security concern, the only way to keep the mass of people from making things less secure is to not offer the option in the first place. It is the responsibility of the banks, who have security experts, to make things more secure. It cannot sit on the shoulders of the masses, as you suggest it should, because it is a known fact that most people using the app are not security experts.
Indeed, by offering the option, they are implying that there is no issue with using it.
HTH
Re:+1 Insightful (Score:3, Insightful)
You've over-simplified the problem and created a false dichotomy. There are many solutions that are more secure than plain-text. It's not a binary decision. You are correct in that you can't get perfect security, but that doesn't mean you can't do better than plain-text. Perfect is the enemy of good.
First, while you cannot achieve true security through obfuscation, you can certainly improve your odds. If I steal a computer and scan cookies and documents looking for passwords, I'm more likely to find and use passwords stored in plaintext than I am to find passwords stored with some kind of reversible encryption. Sure, anybody who knows the details of my app will be able to get the passwords, but that doesn't mean I have to make it obvious and advertise the password data -- make it hard for them, and you'll probably stop 99% of the attacks.
Second, there are often operating system features for storing secure data. The data can be encrypted using the user's password, which is stored in kernel memory on the running system, but is not directly stored on the hard disk (the hard disk stores a hash, not the password itself). Your application can ask the OS to store a secret value, and later you can ask for that value back again. The OS will only be able to give you back the original value if the user is logged on with a correct password. (The OS handles re-encrypting the necessary keys each time the user's password changes.) In Windows, you use the CryptProtectData function. I'm not as familiar with other OS APIs, but I'm sure there are similar APIs on other systems. Not available in restricted scenarios (hard to do this from JavaScript running in the browser), but you should take advantage of the facility if you can.
Finally, if you own both ends of the system (client and server), you can provide challenge/response security that can be pretty strong by using hashes and public/private keys. This is harder, but you can get good security this way. Even in JavaScript.
Re:Totally biased article (Score:3, Insightful)
I seriously question your ability to read, as the first two of your examples are refuted in your quote from the article.
You'll also have to turn in your 'geek' card for not understanding how CNet's automatic link generation works.