app security

Showing 1-10 of 10 messages
app security jacek 12/30/10 1:20 PM
Apps that integrate with various web services and APIs, such as
Twitter,
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
is distributed via Javascript (versus being run on the Web server) can
have this problem.

> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-d...@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

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 Dec 30, 1:47 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> 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
> is distributed via Javascript (versus being run on the Web server) can
> have this problem.
>
>
>
> On Thu, Dec 30, 2010 at 4:20 PM, jacek <jacek.ambroz...@gmail.com> wrote:
> > Apps that integrate with various web services and APIs, such as
> > Twitter,
> > 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?
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to android-d...@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscribe@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
>
> --
> 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
basic script-kiddie.
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.


--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-d...@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en



--
Dianne Hackborn
Android framework engineer
hac...@android.com

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,
I wouldn't worry about that, since there are no real barriers for
anyone else to get their own Twitter API key.

--

Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

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 Dec 31, 6:24 am, Mark Murphy <mmur...@commonsware.com> wrote:
> 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,
> I wouldn't worry about that, since there are no real barriers for
> anyone else to get their own Twitter API key.
>
>
>
> On Fri, Dec 31, 2010 at 5:47 AM, Dianne Hackborn <hack...@android.com> wrote:
> > 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.
>
> > On Fri, Dec 31, 2010 at 2:36 AM, Samuh <samuh.va...@gmail.com> wrote:
>
> >> 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?
>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Android Developers" group.
> >> To post to this group, send email to android-d...@googlegroups.com
> >> To unsubscribe from this group, send email to
> >> android-developers+unsubscribe@googlegroups.com
> >> For more options, visit this group at
> >>http://groups.google.com/group/android-developers?hl=en
>
> > --
> > Dianne Hackborn
> > Android framework engineer
> > hack...@android.com
>
> > 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.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to android-d...@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscribe@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
>
> --
> 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)
and hiding in AccountManager's Account?

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.

--
Dianne Hackborn
Android framework engineer
hac...@android.com
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
recipient.

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

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: