Slashdot Mirror
Major Security Holes Found In Mobile Bank Apps
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."
Most institutions are concerned with whether they are legally covered and covered adequately for insurance purposes. Merely being covered to prevent customers from having money stolen is much, much less important. The concern of the higher-ups will be "did they sign our agreement that says we're protected" more than "Are our customers actually protected?"
IT systems are a tool, like an axe or a chainsaw. The problem is you may not realize you want steel-toed boots until your foot protests strenuously at being attacked.
-- IANAL, this isn't legal advice, and definitely isn't legal advice for you. Also, Squee!
He means that, after buying an iPhone and the associated contract, there won't be anything left in your bank account to steal, so iPhone users are not vulnerable to this problem.
I am TheRaven on Soylent News
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).
Considering this ships as default with the OS, it's inexcusable to not use it. Morons.
See below for more details:
http://developer.apple.com/library/ios/#documentation/Security/Conceptual/keychainServConcepts/iPhoneTasks/iPhoneTasks.html
http://en.wikipedia.org/wiki/Keychain_(Mac_OS)
That may be true but I keep my cash stuffed in my mattress.
And thanks to the facebook leak, google maps and the average persons willingness to announce their plans on twitter, it is even easier to steal it from your mattress.
Tequila: It's not just for breakfast anymore!
... 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
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
Time flies like an arrow. Fruit flies like a banana.