Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security The Almighty Buck Cellphones Iphone

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."
This discussion has been archived. No new comments can be posted.

Major Security Holes Found In Mobile Bank Apps

Comments Filter:
  • But how is Chase's App on iPhone "insecure" when it is the user's responsibility to not leave their username laying around ?

    • by Zero__Kelvin ( 151819 ) on Friday November 05, 2010 @06:50PM (#34143276) Homepage

      "But how is Chase's App on iPhone "insecure" when it is the user's responsibility to not leave their username laying around ?"

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

  • iPhone win? (Score:1, Troll)

    by iamhassi ( 659463 )
    Sounds like a win for the iPhone
    • by Kenja ( 541830 )
      Then clearly you didn't read the article or even the summary.
      • by TheRaven64 ( 641858 ) on Friday November 05, 2010 @05:24PM (#34142602) Journal
        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.
      • Sorry .. I think its YOU that did not read the summary ..

        Or perhaps you failed math ..

        4 mentions of iphone app 'doing it right'

        1 mention of a android being OK ( even tho the one they mention is NOT A BANK !!! )

        4 about android failing

        2 iphone apps being broken ..

        whats that .. android -3 Iphone 2 .. Where is that NOT a win ??

    • Re:iPhone win? (Score:5, Insightful)

      by Anonymous Coward on Friday November 05, 2010 @05:35PM (#34142700)

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

      • by js3 ( 319268 )

        I think because the iPhone apps have to be reviewed by Apple is why they are much better in that regard

        • by t2t10 ( 1909766 )

          You mean the same review process that keeps letting apps through that clearly violate Apple's policies (WiFi sharing, emulators, etc.), only to have them pulled within a day when Apple finally hears about it from users?

          Apple is clearly incapable of determining reliably what the major function of an application is, so you're incredibly naive if you think they are able to figure out something like whether an app stores a password somewhere.

  • Institutions (Score:4, Informative)

    by Oxford_Comma_Lover ( 1679530 ) on Friday November 05, 2010 @05:19PM (#34142560)

    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.

    • by blair1q ( 305137 )

      Most institutions are concerned with whether they are legally covered and covered adequately for insurance purposes.

      I have to say I don't know of a single insurance company that knows enough to require software quality.

      Maybe they do, but while I've been in several situations where government authorities mandated the use of quality standards, I've never seen that on any non-government-regulated software system.

  • Let's not get so excited about the future that we forget the mistakes of the past folks....
  • These apps have the ability to remember the users credentials. The program can either store it in plain text or in a reversibly encrypted manner. There is only marginal benefit to encryption as someone can quickly figure out how to reverse it. The solution is to not store the username or password, but then people would simply ask for that feature. Any bet the apps transmit the username/password in cleartext as well?

    • by Rich0 ( 548339 )

      Agreed - it drives me nuts when app makers deny me the ability to cache passwords/etc. It drives me nuts that chromium stopped caching passwords at the request of the requesting pages a few months ago.

      If I want it to remember my password, I'll tell it to. If I don't want it to remember my password, I'll tell it not to. Either way my password gets recorded in a safe place - I can't set and remember 487 unique passwords for all the sites I visit. I just don't want app writers dictating that choice for me.

      • ...Either way my password gets recorded in a safe place...

        The whole point is that the password may not be getting recorded in a safe place. Plaintext is obviously a poor choice, but it's also a common practice.

        • by Rich0 ( 548339 )

          What practical alternative do you offer, beyond making the user type it every time? At best you can encrypt it using a different password, which you have to type every time (at least that is only one password to remember, but only if the phone provides some kind of central support for this).

          Plaintext or encrypted makes no difference - if the key is stored on the phone anyway. What passes for "encrypted" in most applications is really just obfuscation.

          • by Lehk228 ( 705449 )
            if the site accepted a cryptographic certificate from the device the first time you log in and select "remember me" then future logins are done with your saved user name and the cryptographic identity of your device, so an attacker would have to have a real time rootkit on your device, or take your crypto chip out of your device without you noticing it being destroyed
            • by Rich0 ( 548339 )

              Not a bad idea. Also, I'd have to insist that all devices get delivered without keys, so that there is no way to know if a key is the original one or one that was later generated. Also, as the owner of the device I should be able to choose whether the device generates a key that never leaves the device, or one that it provides a copy to me for safe keeping. The device should never remember disclose which option was chosen.

              This is necessary to defeat trusted computing approaches. If the device locks up k

              • by Lehk228 ( 705449 )
                chip should have the following functions. loadKey, wipeKey, signData, cipherData. you give the device any key you want, but it will never under any circumstance output a plaintext key, this should be enforced in silicon such that the chip cannot read the key store for output.
                • by Rich0 ( 548339 )

                  I'd add generateKey as well - for secure key generation (without any way to distinguish which way the key got there). However, what you suggest seems fine.

                  I'd also arrange that by law devices come without any key and that they are generated when the consumer first uses the device. The wipekey function would need to be easily accessible by an end-user as well. Again, the purpose for this is to make this very useful for security purposes, and useless for trusted computing purposes.

    • Re:So what? (Score:5, Informative)

      by GCsoftware ( 68281 ) on Friday November 05, 2010 @05:36PM (#34142716) Homepage
      I take it you've never heard of the OS-level security feature called Keychain, present on both OS X and iOS - basically, it's a way of storing data in an encrypted form, using the user's login password (or PIN) as the seed for the encryption key. Not unbreakable, but surely a hell of a lot better than plaintext.

      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 [apple.com]
      http://en.wikipedia.org/wiki/Keychain_(Mac_OS) [wikipedia.org]

      • Isn't that the "reversable encryption" he mentioned?

        Or am I wrong on that?

        And no reversible encryption is unbreakable, they are simply unbreakable given a certain amount of time and resources. Good encryption takes thousands of years to break with current technology.

        • The encryption bit of the keychain is AES, which is effectively unbreakable as far as current tech goes. However, as I mentioned it uses the user's login password (by default) as the seed to the session key, which might reduce the keyspace quite a bit, if the user has a weak password.

          So no, not quite the same. In case a device is stolen, the attacker would need to have access to the user's password or PIN (I think the iPhone encrypts the device's whole storage anyway if it is PIN-protected, so you can't j

          • by Sancho ( 17056 ) *

            The iPhone encrypts the storage so that it can wipe by merely overwriting the key instead of the whole storage. It's not really encryption for most intents.

            • I'll be honest and say I don't really know much about the details of iPhone encryption, but would it be fair to say that without the PIN code, it is not possible to get access to the Keychain database on the phone?

              And trying to bruteforce the PIN code would cause the device to get wiped / locked?

              I'm asking, because if this is not the case, then bruteforcing the Keychain might be trivial assuming most people use 4-5 number PINs...

              • by Sancho ( 17056 ) *

                The PIN seems to be irrelevant, actually.

                In iOS, an application always has access to its own keychain items and does not have access to any other application’s items. The system generates its own password for the keychain, and stores the key on the device in such a way that it is not accessible to any application. When a user backs up iPhone data, the keychain data is backed up but the secrets in the keychain remain encrypted in the backup. The keychain password is not included in the backup. Therefore, passwords and other secrets stored in the keychain on the iPhone cannot be used by someone who gains access to an iPhone backup. For this reason, it is important to use the keychain on iPhone to store passwords and other data (such as cookies) that can be used to log into secure web sites.

                -- http://developer.apple.com/library/ios/#documentation/Security/Conceptual/keychainServConcepts/02concepts/concepts.html#//apple_ref/doc/uid/TP30000897-CH204-TP9 [apple.com]

                I'm not sure where the password is stored. I'd be curious to know if it is on the filesystem (and thus accessible when jailbroken) or if it is perhaps stored in silicon somewhere, and whether this password survives system restores.

      • I take it you've never heard of the OS-level security feature called Keychain, present on both OS X and iOS - basically, it's a way of storing data in an encrypted form, using the user's login password (or PIN) as the seed for the encryption key. Not unbreakable, but surely a hell of a lot better than plaintext.

        Considering this ships as default with the OS, it's inexcusable to not use it. Morons.

        Keychain in iOS has limitations, for example it's always unlocked and the user doesn't have to authentication for the apps to get their keys back out. Still I agree that apps should use the built-in key services when possible.

        Also on an iPod Touch you should lock it when not it use. Otherwise if it's stolen the thief doesn't have automatic access to your bank account.

        • How is this different from the Mac? I thought the initial authentication upon login opens up the Keychain?

          I thought if your iPhone was PIN-code protected it would use that to lock the Keychain, no?

          • How is this different from the Mac? I thought the initial authentication upon login opens up the Keychain?

            I thought if your iPhone was PIN-code protected it would use that to lock the Keychain, no?

            The details are in the links provided above.

    • +1 Insightful (Score:3, Interesting)

      by brunes69 ( 86786 )

      I have to deal with this BS at work all the time

      "...But that password is plain text!"
      "Well, the program has to read it. I can encrypt it, but then the app will just have to decrypt it, which means there will be a decryption key in plain text"
      "Then encrypt the key!"
      "...errr...."

      etc etc.

      Either you allow the user to save their login and password every time, and store it REVERSIBLY, or you don't allow it. If the decryption is reversible then it is totally irrelevant and might as well be plain text, since the "e

      • by js3 ( 319268 )

        No, if you know anything about programming the decryption key does not have to be in plaintext.

        • No, if you know anything about programming the decryption key does not have to be in plaintext.

          You could always XOR it and store it in the registry. (Bonus points to those getting this reference). My point is that the decryption method or key is a known quantity and only a mild impediment to getting the password.

      • by kwark ( 512736 )

        Take a look at http digest authentication:
        http://en.wikipedia.org/wiki/Digest_access_authentication#Advantages [wikipedia.org]
        "Advantages

        HTTP digest authentication is designed to be more secure than traditional digest authentication schemes; e.g., "significantly stronger than (e.g.) CRAM-MD5 ..." (RFC2617).

        Some of the security strengths of HTTP digest authentication are:

        * The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). This allows some implementat

      • Re: (Score:3, Insightful)

        by cookd ( 72933 )

        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

        • by brunes69 ( 86786 )

          As for your first paragraph - this is just obfuscation and no better than ROT-13. It doesn't make anything "harder", it just provides a very very false sense of security that is trivially defeated. Such things are better off NOT DONE so at least the user realizes how insecure it is to store their passwords on the device.

          As for the second, Do you know how many cell phone users have their phone password protected at screen on? I would venture it is close to 0, as it is horrifically inconvenient to do so. So t

      • There is a third option. On a successful login, store a token that is unique to that device. If you don't store the password, it's impossible to obtain it. I believe steam uses an approach like this now, after lots of malware was written to steal users passwords.
    • "Any bet the apps transmit the username/password in cleartext as well?"

      Ignoring for the moment that such a phenomenally stupid move would have not only made the article, but also surely have been the focus of the article title, it is absurd to suggest that they aren't using https, as they have been doing properly for years.

    • by cookd ( 72933 )

      Part of the security for an application can be attributed to the underlying platfom. It is very difficult to write a secure application on a operating system that doesn't require a user to log-on to access all files on the system. On such a system, anybody who can access a terminal can compromise any unencrypted data from any application, and the application developer must work that much harder to secure the data. On the other hand, on an operating system that has log-in and protects files from access by un

  • All?! [wikipedia.org]
    I mean, seriously, what else can you get away with today?
    • All?! [wikipedia.org]
      I mean, seriously, what else can you get away with today?

      I'm not suggesting that poor security is unacceptable but when is it time for individuals to take some responsibility concerning the security of your own information? It is precisely because of "chicken with their head cut off" people like you that we have this stupid SOX compliance to deal with in public corporations. SOX should have a narrow focus because ENRON was the result of bad accounting practices, not IT policies.

      • > I'm not suggesting that poor security is unacceptable

        You are suggesting that poor security is acceptable.

        > time for individuals to take some responsibility

        Yes, but corporations need to take responsibilities, too - and be liable. Additionally, think of Joe Sixpack instead of /. geeks: online banking (and the tools used) need not be fool-proof - since someone only needs to build a better fool - but Joe would expect reasonable dilligence (if he cared, which he doesn't unless things go wrong).

        I'm
      • by Sancho ( 17056 ) *

        The "no liability" disclaimers from developers is BS. If you provide me a banking app, and through the normal, intended use of that app, my account is compromised, then you should be liable.

  • I read this story immediately since I use one of the listed apps but it wasn't until the end that I saw that it was only the apps running on Android. Should have had the modifier "Android" in the title.

    Are Apple's policies or requirements for their app store responsible for this not being an iPhone problem?

    • by loconet ( 415875 )

      How is this only an Android problem? The summary clearly states it relates to both Android and iPhone apps. Should the title have a brand modifier based on the number of times said brand appears in the summary? Ridiculous.

    • by basotl ( 808388 )
      Well there were other apps listed for iphone just not huge vulnerabilities IMHO. The worst seemed to be the Wells Fargo Android App.
    • Re: (Score:3, Insightful)

      by Bigjeff5 ( 1143585 )

      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

  • by Doc Ruby ( 173196 ) on Friday November 05, 2010 @06:13PM (#34143028) Homepage Journal

    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.

    • "The banks are untrustworthy"


      Big banks to have insecure apps? And you are expecting that? For me it is a shocker.
      • How long have you been banking?

        Forget that: how long have you been reading the news? How could you think that banks are either trustworthy or reliable? If it weren't for the public (FDIC, FSLIC, Federal Reserve, Treasury) bailing them out every 10 years, they'd have lost more money than ever existed. It doesn't get more untrustworthy than that.

    • by kcitren ( 72383 )

      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.

      Then if I were you, I would find another place to store my money. If I didn't trust my bank to make an app for me to manage my account and not rip me off [assuming I believe them to be competent developers], why the hell would I let them hold my money? Other then that, I agree with the rest of your post.

      • Because by carefully tracking my money, I stop them when they rip me off. That's why I'd like a simple, comprehensive tool to do so.

  • Chase's iPhone app stores the username on a phone if the user chose that option,

    who would have thunk?

  • I use the Chase iphone app and am perfectly happy with its security. I did not opt to store my username on the phone and therefor my security was never in a perilous state. People who chose to store their username on the phone have a SLIGHTLY less secure system, but probably chose to do so because their password is very secure or they just don't care. I think this is more about people than systems.

  • by Anonymous Coward

    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.

    This article is attempting to make iPhone look less problematic then Android based phones.

    Examples:
    - why don't they list the uneffected Android apps as they do for iPhone?
    - why don't they mention that the Android paypal app is uneffected unlike how it effects the iPhone?
    - why would they provide a link to "Google Android" and not "iPhone iOS" other then to highlight "Android" in bright blue along with the title of this article?

    Question: where does C-net disclose its conflict of intere

    • by Wovel ( 964431 )

      There may not be any (seriously) . Far fewer apps exist for Android. Reporting reality != bias..

    • Re: (Score:3, Insightful)

      by jeff4747 ( 256583 )

      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.

  • US Bank's Android and iPhone apps are what interest me.
  • by Anonymous Coward

    Young and foolish developers are mostly the ones who have had time to really move onto mobile platforms. Whaddya expect from whipper snappers that haven't lived through the wars?

  • start issuing keyfobs and be done with it.

  • by Wovel ( 964431 ) on Friday November 05, 2010 @09:16PM (#34144666) Homepage

    I suppose no one would have read a story titled "Minor (If we really stretch medium)" security holes found in bank apps.

    • Tell me about it. I wouldn't even consider these "holes" as they aren't (immediately) remotely exploitable. If that were the case, firefox has the same "major security hole", as it remembers my bank username and passords. I'm not even sure if the iphone apps are locally exploitable with out the os level jailbreak first? It's simply the loudest "researcher" that gets the most headlines and generates the most noise.
  • I've had numerous discussions with my credit union about their inadequate response to computer security.

    For instance, their customer service messaging is handled through a third party, so e-mails will reference a third party URL that seemingly has nothing to do with the credit union. I've tried to explain phishing attacks to the credit union to no avail.

    At the same time, their customers are pressuring them to support transactions via the phone. What a disaster. The sad part is, as a credit union me
    • by Lehk228 ( 705449 )
      scanning as in fingerprint scanning? all i can say to that is "L.O.L."

      fingerprint scanning is james bond shit that has nothing to do with and no place in real security.
  • A hole can be fixed. An app that saves data, plain-text or not, is just that. The real issue is WHERE these apps are running: on mobile devices which, if not properly secured, serve as an easy target when stolen or lost. Is a non-secured iPhone filled with holes since all of your contacts, e-mail, etc. is stored in plain-text?
  • Because I use the BoA app and it NEVER remembers my device, but apparently knows the answer to my question ahead of time =/
  • Really, I mean come on, after 20 years of online banking, they would come back to these junior level mistakes.
    Someone should lose their job for lack of competence...and I am not talking about the junior programmers!
    Quality control is management level responsibility, and if you have no nunit testing tools, or diagnostics tools, you hire a firm that does, especially when dealing with banking info like this.

    Thanks to the company that did the research , we nipped it in the bud, how many more problems like this

Some people manage by the book, even though they don't know who wrote the book or even what book.

Working...