|app security||jacek||12/30/10 1:20 PM|
Apps that integrate with various web services and APIs, such as
need to use service provisioned API keys and shared secrets
which are Java Strings.
Such Strings should be retrievable by anyone who decompiles an .apk
(I must try this myself against my own apk)
In the next step the malicious developer will be able to impersonate
the decompiled app...
Am I missing something, or do we have a problem?
|Re: [android-developers] app security||Mark Murphy||12/30/10 1:47 PM|
Who is "we"? This problem exists for all software ever written, where
the software is distributed. Desktop applications and mobile
applications are equally susceptible. Even Web apps, where this data
have this problem.
Android Training in Atlanta: http://bignerdranch.com/classes/android
|Re: app security||Indicator Veritatis||12/30/10 3:31 PM|
Well, yes, it exists for all software ever written, but you are
comparing oranges and apples when you call the problem the same.
After all, the obvious conspicuous difference is that when the
software is written in C or C++ and distributed in binary form
(whether executable or linkable), there is far, far less incentive to
decompile and copy the code. But with Java, whether Sun's or
Android's, the incentive to decompile the code is greater, because the
decompiled code is much more readable.
Of course, it is still not as readable as the original source
(assuming the author used inline comments to throw light on what he
was doing instead of obscure the code as some have done); but it is
readable enough to steal the code. That is why people use obfuscators.
But they don't help much, so yes, we do have a problem. People should
think about this problem when choosing a business model, choosing it
in such a manner that the incentive to stick with legal software is
clear to the customer. The subscription model is one such example,
there are others.
> On Thu, Dec 30, 2010 at 4:20 PM, jacek <jacek.ambroz...@gmail.com> wrote:> Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
|Re: app security||MarcoAndroid||12/31/10 12:55 AM|
Yes Houston "we" have got a problem :)
Strings are in general very easy to extract from binaries, even from C/
C++ programs via the "strings" *nix command for example. You don't
need to decompile anything!
What you could do is manually obfuscate your strings some more:
- split the key-string in multiple strings, concatenate only where you
need them (or at a totally unrelated place)
- store the key-string encoded in your code (e.g Base64), decode it
only when you need them (or at a totally unrelated place)
Of course not super-strong protection but might protect you from the
|Re: app security||Samuh||12/31/10 2:36 AM|
This post [http://digital-identity.dk/2010/12/protecting-ip-in-android-
applications/] suggests that apart from obfuscation, we can try
implementing a portion of (sensitive) code natively. And then to
ensure that the native code is used/called by our application only, we
can match the digital keys used to sign the application.
How effective will this prove to be?
|Re: [android-developers] Re: app security||Dianne Hackborn||12/31/10 2:47 AM|
Ultimately there is no good answer here. No matter what you do, you can't totally protect anything in your application. Your entire application is out in the world, where anyone can get at its contents, and with sufficient effort learn every deepest darkest secret it contains.
The question you have to ask yourself is, how difficult does it need to be for someone to get at whatever you are concerned about? You can't make it impossible. You can make it easy or various levels of harder. Moving to native code gives you more tools for making it harder, but is never going to be a panacea. How much time are you willing to spend on this vs. how much harder you will make it? You are quickly going to find yourself reaching a point of diminishing returns where a large amount of effort moves the "harder to extract" needle only a little bit.
Android framework engineer
Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
|Re: [android-developers] Re: app security||Mark Murphy||12/31/10 3:24 AM|
Moreover, you also have to ask yourself how much effort is needed for
a given item.
For example, the OP was concerned about a Twitter API key. Personally,
Mark Murphy (a Commons Guy)
Warescription: Three Android Books, Plus Updates, One Low Price!
|Re: app security||jacek||12/31/10 6:15 AM|
I know that everybody can get their Twitter etc. api_key (+ secret).
The same goes for Google Storage, Amazon S3 credentials, etc.
My issue is that I do not want *my* credentials stolen
and the bad guy pretending to be me
with all the dire consequences.
So -- how about getting credentials from the Cloud (over SSL)
and hiding in AccountManager's Account?
> On Fri, Dec 31, 2010 at 5:47 AM, Dianne Hackborn <hack...@android.com> wrote:
> > On Fri, Dec 31, 2010 at 2:36 AM, Samuh <samuh.va...@gmail.com> wrote:> > hack...@android.com
>> Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
|Re: [android-developers] Re: app security||Dianne Hackborn||12/31/10 10:58 AM|
On Fri, Dec 31, 2010 at 6:15 AM, jacek <jacek.a...@gmail.com> wrote:
So -- how about getting credentials from the Cloud (over SSL)
Though again, this hasn't protected you, just made it harder. Your data is still there on the device, for someone with root access to find and retrieve.
|Re: app security||Bob Kerns||12/31/10 6:44 PM|
This isn't really an Android issue. Anyone who gives out credentials
for any purpose needs to consider that they may be compromised.
The usual ways of dealing with it are to time-limit them, and to allow
them to be revoked.
But what I think REALLY should be done, is to issue credentials with
two components, one revocable by the issuer, and one revocable by the
So, on losing your phone, you go to a website, and invalidate all the
credentials that were associated with the phone.
This wouldn't deny you access, just force you to go through the re-
credentialing process for each affected entity, using a reissued
You could see extending this to three components, so a company with
accounts with Salesforce.com and similar things, could revoke access
for a terminated employee, for example. In this case, the access token
would not be reissued.
On Dec 31, 10:58 am, Dianne Hackborn <hack...@android.com> wrote: