Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Major Security Holes Found In Mobile Bank Apps

Soulskill posted more than 3 years ago | from the and-you-can-take-that-to-the-uh-nevermind dept.

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

Sorry! There are no comments related to the filter you selected.

It couldn't be... (0)

Anonymous Coward | more than 3 years ago | (#34142490)

Banks are totally secure, this is obviously propaganda

Re:It couldn't be... (1)

WrongSizeGlass (838941) | more than 3 years ago | (#34142786)

Banks are totally secure, this is obviously propaganda

That may be true but I keep my cash stuffed in my mattress. It may not have a 'mobile app', and there aren't many ATM's on the 'Mattress Network', but I'm able to work within those limitations.

Re:It couldn't be... (0)

Anonymous Coward | more than 3 years ago | (#34142988)

You know, you're not going to get women to go to bed with you with this story either.

They can tell you don't have any money by the fact that you took them to a date at a restaurant with a dollar menu.

Re:It couldn't be... (3, Funny)

Pharmboy (216950) | more than 3 years ago | (#34143024)

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.

Re:It couldn't be... (0)

Anonymous Coward | more than 3 years ago | (#34145916)

The 'Matress Network' in many large cities are riddled with bedbugs, not secure at all.

Re:It couldn't be... (0)

Anonymous Coward | more than 3 years ago | (#34143298)

.... and solvent!

Second post!!! (-1, Troll)

Anonymous Coward | more than 3 years ago | (#34142522)

2nd!!! 2nd!!!! WOoooooooooooooooo!

(if you can't win, be happy with second place)

Re:Second post!!! (0)

Anonymous Coward | more than 3 years ago | (#34143732)

you mean, like this anti android and pro iphone slashturfing? Why turfers care to try to convince the majority of iFags in here anyway, talk about preaching to the choir

THIS JUST IN! Interner Explorer 6 SAFER than Android! WWS(teve)D??

Paging steve jobs (0)

Anonymous Coward | more than 3 years ago | (#34142534)

http://cache.gawkerassets.com/assets/images/7/2010/05/500x_sjobs1.jpg

"freedom from programs that steal your private data"

I think he meant:

"freedom from programs that will notify you that other programs are stealing your private data"

Re:Paging steve jobs (0)

Anonymous Coward | more than 3 years ago | (#34142790)

"there's an app for that"

I think he meant:

"there's a security hole for that"

I can see the problems. (1)

JimB (9642) | more than 3 years ago | (#34142536)

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

I also saw the hole (-1, Troll)

Anonymous Coward | more than 3 years ago | (#34142564)

An enormous hole [goatse.fr]

OH! OH! I know! Pick Me ! (4, Insightful)

Zero__Kelvin (151819) | more than 3 years ago | (#34143276)

"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

Re:OH! OH! I know! Pick Me ! (0)

Anonymous Coward | more than 3 years ago | (#34145246)

I have a pin lock enabled on my iPhone. Why shouldn't I have this option?

Re:OH! OH! I know! Pick Me ! (0)

Anonymous Coward | more than 3 years ago | (#34145366)

If banks cared about teh fraud caused by plain text, stored usernames, then they'd fix it. Evidently its not an issue as it costs them money. Or is this another one of the "security fixes" that no one would ever use or care about. Paranoid people really irk me sometimes.

Re:OH! OH! I know! Pick Me ! (1)

Zero__Kelvin (151819) | more than 3 years ago | (#34145828)

FTS:

"...prompting a scramble by most of the companies to update the apps ... "

I guess you missed that line in the summary

iPhone win? (0, Troll)

iamhassi (659463) | more than 3 years ago | (#34142538)

Sounds like a win for the iPhone

Re:iPhone win? (1)

Kenja (541830) | more than 3 years ago | (#34142548)

Then clearly you didn't read the article or even the summary.

Re:iPhone win? (3, Funny)

TheRaven64 (641858) | more than 3 years ago | (#34142602)

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.

Re:iPhone win? (1)

Sponge Bath (413667) | more than 3 years ago | (#34142968)

If someone was foolish enough to steal from an iPhone user, they would get whacked in the head by Crazy Steve [gstatic.com] and his magic Apple TV!

Re:iPhone win? (1)

kevorkian (142533) | more than 3 years ago | (#34144310)

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? (1)

repapetilto (1219852) | more than 3 years ago | (#34146078)

I wonder how jack felt abotu forced castration...

Re:iPhone win? (1)

kmoser (1469707) | more than 3 years ago | (#34147870)

All they have to do to fix those Android apps is to rename them from "Banking Application" to "Banking Application and Honeypot". Problem solved!

Re:iPhone win? (5, Insightful)

Anonymous Coward | more than 3 years ago | (#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).

Re:iPhone win? (0)

Anonymous Coward | more than 3 years ago | (#34143336)

This is not a platform battle. The banks clearly take shortcuts or hire developers unfit for the task.

Yes, but they get the Low Price Always [TM] on software development! That's more important!

Re:iPhone win? (1)

js3 (319268) | more than 3 years ago | (#34143344)

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

Re:iPhone win? (1)

t2t10 (1909766) | more than 3 years ago | (#34144510)

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 (4, Informative)

Oxford_Comma_Lover (1679530) | more than 3 years ago | (#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.

Re:Institutions (1)

blair1q (305137) | more than 3 years ago | (#34143828)

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.

Plaintext user data storage? (2, Interesting)

TravTrav (1236742) | more than 3 years ago | (#34142596)

Let's not get so excited about the future that we forget the mistakes of the past folks....

So what? (1)

fluffy99 (870997) | more than 3 years ago | (#34142642)

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?

Re:So what? (1)

Rich0 (548339) | more than 3 years ago | (#34142682)

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.

One of these days I'll get around to patching chromium to ignore the setting that prevents it from caching credentials...

Re:So what? (1)

fluffy99 (870997) | more than 3 years ago | (#34143744)

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

Re:So what? (1)

Rich0 (548339) | more than 3 years ago | (#34145008)

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.

Re:So what? (1)

Lehk228 (705449) | more than 3 years ago | (#34146530)

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

Re:So what? (1)

Rich0 (548339) | more than 3 years ago | (#34147084)

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 keys at my whim to keep me safe, that is fine, but if the device locks up keys to keep somebody else safe from me, then I'm not buying into that.

Re:So what? (5, Informative)

GCsoftware (68281) | more than 3 years ago | (#34142716)

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]

Re:So what? (1)

Bigjeff5 (1143585) | more than 3 years ago | (#34143014)

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.

Re:So what? (1)

GCsoftware (68281) | more than 3 years ago | (#34143062)

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 just copy the keychain database off the device and try to bruteforce it).

Re:So what? (0)

Sancho (17056) | more than 3 years ago | (#34143330)

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.

Re:So what? (1)

GCsoftware (68281) | more than 3 years ago | (#34143768)

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

Re:So what? (1)

Sancho (17056) | more than 3 years ago | (#34144188)

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.

Re:So what? (1)

fluffy99 (870997) | more than 3 years ago | (#34143718)

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.

Re:So what? (1)

GCsoftware (68281) | more than 3 years ago | (#34143806)

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?

Re:So what? (1)

fluffy99 (870997) | more than 3 years ago | (#34144212)

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 (2, Interesting)

brunes69 (86786) | more than 3 years ago | (#34143002)

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 "encryption" is no better than ROT-13 if the key is right there for anyone to get.

Re:+1 Insightful (1)

js3 (319268) | more than 3 years ago | (#34143360)

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

Re:+1 Insightful (1)

fluffy99 (870997) | more than 3 years ago | (#34143596)

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.

Re:+1 Insightful (1)

kwark (512736) | more than 3 years ago | (#34143568)

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 implementations (e.g. JBoss DIGESTAuth) to store HA1 rather than the cleartext password."

Still better than storing the plaintext password, but doesn't help much when stolen (except for hiding the same password one might have used for other accounts).

Re:+1 Insightful (3, Insightful)

cookd (72933) | more than 3 years ago | (#34143640)

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:+1 Insightful (1)

brunes69 (86786) | more than 3 years ago | (#34146678)

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 this facility is DOA for cell phones for the average user. It is a nice OS feature for the security conscious people who want it, but it is useless when targeting the casual market,

As for the third, I have no idea what you are going on about as this has nothing to do with storing passwords on a device in a manner that is reversable.

Re:+1 Insightful (1)

complete loony (663508) | more than 3 years ago | (#34144034)

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.

I'll take that bet (Let's not get ridiculous) (1)

Zero__Kelvin (151819) | more than 3 years ago | (#34143328)

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

Re:So what? (1)

cookd (72933) | more than 3 years ago | (#34143394)

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 unauthorized users, an application can store per-user sensitive data in a per-user folder and the data is secure from unauthenticated access.

Of course, physical access trumps log-on access controls (if you can steal the hard drive or get the system to boot into an environment that you control, you can bypass the filesystem security). OS features such as whole-disk encryption can help in this scenario, once again making the application developer's job easier by providing a secure-by-default platform.

For Desktop PCs, such encryption is still somewhat optional. If you can provide physical security (lock your house), you don't need data security (encrypt your hard drive) quite as much.

With a mobile device such as a laptop or smartphone, this kind of encryption is very important. If the data on a smartphone can be accessed without logging in, then somebody just needs to steal your phone to access your data. Phones are stolen all the time, so plaintext data on a smartphone is a serious security problem.

Some smartphones have a nifty feature that allows you to treat the phone as a mass storage device. Unfortunately, this feature can be a serious liability if it allows somebody to access data on the phone without going through the OS's filesystem security. Phones that have this feature are more usable, but developers writing apps for this kind of phone need to do more work to ensure that their applications are secure. Applications on phones that don't allow such access are secure by default.

Some phones allow you to store data on an SD card, then remove the card and insert it into another system to read the data. Again, this is a very useful feature, but it can also be a serious security hole if there is any sensitive data on that SD card. Once again, if the phone has this feature, the application developer needs to take additional precautions to ensure that no sensitive information is stored on the SD card.

Some phones encrypt all data stored on the SD card. This renders the SD card useless as removable storage, but it means that sensitive data stored on the SD card is less likely to be revealed if the phone is stolen.

Bottom line is that the design of the smartphone platform (including the platform's limitations) have a lot to do with the security of the applications. I have no trouble believing that the same dumb developer might write the same app for two different platforms and the resulting app might be totally secure on one platform and totally insecure on the other, simply because of differences in the operating system design.

um... sue 'em? (1)

whathappenedtomonday (581634) | more than 3 years ago | (#34142656)

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

Re:um... sue 'em? (1)

aristotle-dude (626586) | more than 3 years ago | (#34142718)

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.

Re:um... sue 'em? (1)

whathappenedtomonday (581634) | more than 3 years ago | (#34142842)

> 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 amazed time and time again what you can get away with today, that's all. My bad. Not sure what SOX has to do with that, tho'.

Re:um... sue 'em? (0)

Anonymous Coward | more than 3 years ago | (#34146828)

He brought up SOX because it is a new talking point from the GOP. I'm sure he picked it up by osmosis from right-wing media, as intended.

This hasn't been announced, but judging from other references to it in the past few days, the GOP intends to kill it, along with the new requirements for the banking industry. Bidness-friendly.

Freedom! (lol)

Re:um... sue 'em? (1)

Sancho (17056) | more than 3 years ago | (#34143406)

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.

Re:um... sue 'em? (1)

Smidge207 (1278042) | more than 3 years ago | (#34142792)

Seems like I can barely remember a time when all I consumed was water, milk and food. That was a LONG time ago. Now my DAILY intake of coffee, beer, multivitamin, nicotine and Effexor is such that if I were to go cold turkey I'd be dead in a week.

Gouda? No, it's awful /cool story bro\

I must be a neoluddite (0)

Anonymous Coward | more than 3 years ago | (#34142802)

I still have a landline. To do my banking, I call my bank and enter my account number, which I have memorized. In rare instances (say, on the interstate while driving across the U.S.) I have called my bank from my cell phone, a Nokia 3589i. If people want to access their bank account from a smartphone, that's fine with me, but personally I don't want anything to do with it. It'd be nice to see the banks & telecoms held to a standard --beaten over the head, if need be-- whereby such carelessness & wrecklessness would never see the light of day.

Thank Goodness (0)

Anonymous Coward | more than 3 years ago | (#34142844)

I can really use the extra cash before Christmas.

This is an Android App Security Story (1)

RNLockwood (224353) | more than 3 years ago | (#34142858)

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?

Re:This is an Android App Security Story (1)

loconet (415875) | more than 3 years ago | (#34143022)

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.

Re:This is an Android App Security Story (1)

basotl (808388) | more than 3 years ago | (#34143038)

Well there were other apps listed for iphone just not huge vulnerabilities IMHO. The worst seemed to be the Wells Fargo Android App.

Re:This is an Android App Security Story (2, Insightful)

Bigjeff5 (1143585) | more than 3 years ago | (#34143044)

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.

Re:This is an Android App Security Story (0)

Anonymous Coward | more than 3 years ago | (#34149062)

Actually, reading farther down into the original article (two times removed from TFA), it appears the only flaw was in TD Ameritrade and JP Morgan apps on the iPhone, and their only flaw was to store the username in plain text. It did not store the password, which is why it was considered a minor flaw as it was not enough information to grant someone access to the account itself.

http://online.wsj.com/article/SB10001424052748703805704575594581203248658.html [wsj.com]

Standard Banking Client (2, Insightful)

Doc Ruby (173196) | more than 3 years ago | (#34143028)

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:Standard Banking Client (0)

Anonymous Coward | more than 3 years ago | (#34143146)

Banks untrustworthy? But wait, isn't that why we have bank regulations? But wait, the regulators, they can't be trusted either, can they? So we need people to regulate the regulators, let's call them legislators, but wait, we can't trust them either so...

Circle of Distrust drives government, who could think of it?

But seriously, you want to do the things you desire, you're probably going to have to work at it from a bureaucratic approach first. I don't personally desire these things myself, my bank doesn't know my e-mail, I've never even visited my bank's website, but if you do, you're going to need to deal with the reality of how financial institutions do things.

Re:Standard Banking Client (0, Flamebait)

Doc Ruby (173196) | more than 3 years ago | (#34143502)

I've written lots of software for banks, for a good chunk of money.

While the regulators need changing to truly protect us from banks, we just took a big step backwards this week by putting Republicans back in charge of that legislation. They are busy deregulating again, though the most they'll probably get is monkeywrenching the new regulations. The reason the legislators can't be trusted is because Americans are stupid, and vote for corrupt legislators, even when that's obviously what they're getting.

Which is why I'd like better tools to protect us from banks. That is the reality. I can tell from your comment that you're not really qualified to give advice on the reality of financial institutions.

Re:Standard Banking Client (1)

Doc Ruby (173196) | more than 3 years ago | (#34144528)

Moderation -1
    100% Flamebait

Republican Trollmod proves my point about how stupid they are.

Re:Standard Banking Client (1)

Dahan (130247) | more than 3 years ago | (#34149236)

Aww, poor baby. Why don't you cry some more?

Re:Standard Banking Client (1)

bmk67 (971394) | more than 3 years ago | (#34144862)

While the regulators need changing to truly protect us from banks, we just took a big step backwards this week by putting Republicans back in charge of that legislation. They are busy deregulating again, though the most they'll probably get is monkeywrenching the new regulations.

The Democrats control the Senate and the White House. Since any legislation has to pass both houses and be signed by the President, I think your scenario is pretty unlikely to occur. ...but don't let me get in the way of an uninformed rant. Carry on.

Re:Standard Banking Client (0)

Anonymous Coward | more than 3 years ago | (#34143192)

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.

Good business idea. Why are you still flipping burgers at the neighbourhood you know what!

Re:Standard Banking Client (1)

Doc Ruby (173196) | more than 3 years ago | (#34143468)

I'm a rich guy who's too busy to develop that app, but smart enough to know there's demand for it.

Free clue for you, Anonymous greasemonkey Coward.

Re:Standard Banking Client (1)

whiteboy86 (1930018) | more than 3 years ago | (#34143228)

"The banks are untrustworthy"


Big banks to have insecure apps? And you are expecting that? For me it is a shocker.

Re:Standard Banking Client (1)

Doc Ruby (173196) | more than 3 years ago | (#34143450)

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.

Re:Standard Banking Client (1)

kcitren (72383) | more than 3 years ago | (#34143778)

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.

Re:Standard Banking Client (1)

Doc Ruby (173196) | more than 3 years ago | (#34144514)

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.

Re:Standard Banking Client (0)

Anonymous Coward | more than 3 years ago | (#34144100)

I think you're looking for Mint.com, which does (or at least tries to do) most of the things you mentioned.

The convenience of this app/service is definitely clear. What is not clear is how secure this third party data aggregator is and will be in the future with some of the most valuable and private information about you. ("oooh... frequent purchases from adultpornsite.com!")

No way! (1)

RaySt (1089705) | more than 3 years ago | (#34143114)

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

who would have thunk?

What is the point? (0)

Anonymous Coward | more than 3 years ago | (#34143126)

I have an ipod touch laying around and it continually asks me for my password every time to do anything in the app store even if I just entered my damned password a few moments ago... This is rediculous and annoying.

WRT storing passwords in plain text on the device it is no more secure than storing a hashed password or reversably encrypted password... If whatever is stored will unlock access to your account it makes no difference what format the stored data is kept.

One app stored password from the article - all the others failed because they stored just username. oh no..OMG..this is terrible..

It just annoys people to no end to have to login again and again and again to do simple things day in and day out. What difference does it make if another app compromises your device WHILE your banking app is running or compromises it later when it is not? I'm sick of security theatre and mobile platforms that continue to not be designed to be secure by default.

Hint hint if mobile applications in an appstore need to be reviewed for malicious intent to protect the end user then the whole platform is crap from a security POV.

Chase Iphone App (1)

vortex2.71 (802986) | more than 3 years ago | (#34143594)

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.

Franklin said (0)

Anonymous Coward | more than 3 years ago | (#34143610)

Those who would choose Steve Jobs' insecurity over freedom deserve the first one. I'd rather be at risk for shit by banking on my phone (I don't even use a credit card) than to feed a megalomaniac.

Other apps installed also are of concern (0, Troll)

forrie (695122) | more than 3 years ago | (#34143680)

Just because a PayPal app might be handling data correctly doesn't mean another app isn't attaching to the keyboard TTY and sniffing your keystrokes, or accessing data through another mechanism. This is what happened to me on the iPhone with PayPal, and I got ripped off.

This is the risk we take with new technology. Everyone wants to jump on board without really understanding the inherent risks and assuming manufacturers like Apple (who was silent to my forensic evidence) does the right thing or is even capable of auditing every line of code. Early on, I am willing to bet the Apple App Store was rife with programs either inappropriately accessing or outright stealing personal data. Look at what's been going on with Android. There's a market for that stuff -- we must keep that in mind.

The bottom line for me is I will never do any "sensitive" (financial) type work on a mobile device.

Re:Other apps installed also are of concern (0, Flamebait)

Wovel (964431) | more than 3 years ago | (#34144694)

Really you got your Paypal login information stolen by a sniffer App on a non-jailbroken iPhone. Where was the news story? (I am serious). Oh right there isn't one because you are not telling the truth. Either A: You jailbroke your iPhone and installed a bunch of random crap and then decided it was a good idea to use it for financial transactions too or B. You are full of shit. I vote B...

Totally biased article (1, Interesting)

Anonymous Coward | more than 3 years ago | (#34143912)

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 interest in their articles? Provide link please.

Re:Totally biased article (1)

Wovel (964431) | more than 3 years ago | (#34144674)

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

Re:Totally biased article (2, Insightful)

jeff4747 (256583) | more than 3 years ago | (#34145220)

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.

Googles Fault (1)

pavewrld (6221) | more than 3 years ago | (#34143960)

Its a google webView 'feature' that is enabled by default and all password protected sites viewed via a custom application has the same problem.

No mention of the one bank app I care about... (1)

magnusrex1280 (1075361) | more than 3 years ago | (#34144126)

US Bank's Android and iPhone apps are what interest me.

'droid and Iphone -- a young man's game (1, Funny)

Anonymous Coward | more than 3 years ago | (#34144186)

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?

so... (1)

hitmark (640295) | more than 3 years ago | (#34144418)

start issuing keyfobs and be done with it.

Write misleading headlines much? (2, Interesting)

Wovel (964431) | more than 3 years ago | (#34144666)

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

Re:Write misleading headlines much? (1)

slashkitty (21637) | more than 3 years ago | (#34145238)

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.

wow... a phone app meant to access CAN access... (1)

MichaelKristopeit128 (1934222) | more than 3 years ago | (#34144712)

it doesn't matter if the password is stored in plain text or the password is encrypted in some form... what the phone is storing is effectively the authentication string... if the password was encrypted, then the encrypted string would be sent plain text effectively making the encrypted string the new password.

physical access = game over.

full memory and disk access = game over.

anyone that says otherwise is lying to you.... anyone continuing to point it out as if it is news is an ignorant marketeer.

My credit union pressured for phone transactions (1)

cpm99352 (939350) | more than 3 years ago | (#34145536)

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 member, I suffer, because my savings interest rates will decline due the inevitable write-offs.

Already, we've seen responsible credit unions take a massive hit -- on September 24, 2010 the National Credit Union Administration (NCUA) placed 3 corporate credit unions in conservatorship. As a result, $30-35MM in bonds will be issued by NCUA to cover the bad credit unions. The member credit unions take the hit, and my credit union lost $2MM.

From an e-mail with my credit union:

NCUA also operates the federal deposit program for credit unions. This fund is called the National Credit Union Share Insurance Fund (NCUSIF). This fund is capitalized by deposits from individual credit unions and backed by the full faith and credit of the U.S. Government. Insured credit unions deposit 1% of their insured shares into the fund on an annual basis. The fund balance must operate between 1 – 1.3% of insured deposits. Anytime the fund does not stay above the target rates established by the NCUA we must make premium payments to recapitalize the fund. In 2010 our recapitalization rate was 12 basis points or $480,000. These expenses are part of the Credit Union’s operating expenses on any given year.

At the end of the day, I suspect we either need scanning on the phones, or a secure fob that produces one time passwords that get entered into a website. I think just about everything else is open to attack.

Yes, fobs are expensive. Suck it up, banks! How much more bailout money do you need?

Re:My credit union pressured for phone transaction (1)

Lehk228 (705449) | more than 3 years ago | (#34146542)

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.

Shit, those Fishing apps are dangerous (0)

Anonymous Coward | more than 3 years ago | (#34145556)

TFA:

>You could "trick the user with a fishing fake email" Mr. Hoog said.

Hope no one likes trout!

As a USAA employee, I can assure you some ONE is looking into this on a Friday night...

cough

Holes? (1)

gfuss (700765) | more than 3 years ago | (#34146664)

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?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?