[Owasp-leaders] OWASP Mobile Top 10 - potential conflict of interest in M10

Jason Haddix jason.haddix at owasp.org
Tue Nov 4 21:54:55 UTC 2014

This was posted from Brad Hill (Sec Engineer at Facebook) to our MTT
mailing list, pasted verbatim:

"I won't be able to make the call, but wanted to provide some documented
feedback on the topic.

As currently written, multiple experts have expressed serious concerns that
M10 actually presents a sound security practice and reasonable goals.
Obfuscation systems that are practical to deploy for current mobile app
platforms can at best marginally increase the cost of attacking an
application.  At worst, they create a false sense of security.  For
sufficiently valuable secrets, determined attackers will find ways to
bypass any obfuscation possible with current techniques.  Encouraging the
idea that these are meaningful and effective protections therefore
propagates mistaken software architectures that promise things to users
they cannot deliver.  The recent attack against users of the Snapchat
service where malicious or insecure clients used API keys extracted from
the obfuscated genuine app is a great example of the kind of risks this bad
advice presents.

For client-server architectures that distribute identical binaries to all
clients, we have known the appropriate security practice for decades: do
not put secrets in the source code or binary.  (whether those secrets are
cryptographic keys or algorithms)  It is true that this makes distributed
systems with properties that many developers want either difficult or
impossible to build. (e.g. API endpoints that can remotely determine that
they are being called by "authorized" or "genuine" client software only)
 But if these are serious problems, they deserve serious solutions - we
shouldn't reduce the necessary market pressure on mobile platform and app
store vendors to provide provisioning methods with different security
properties by selling snake oil to developers who may not know better.

I think there are two salvageable categories that can be matched to the

1) Missing Anti-exploit Protections.  These are measures like ASLR that
increase the cost of exploitation from outside of the application's
security boundaries.
2) Embedded Shared Secrets.  Yes, the data will show that many apps are
vulnerable because of this.  The answer is simple: don't embed secrets in a
shared distribution.

This anti-jailbreak, anti-debug, anti-RE, secret obfuscation stuff has to

On Tue, Nov 4, 2014 at 12:08 PM, Jonathan Carter <jonathan.carter at owasp.org>

> Trusted execution environments are one potential solution to this.  The
> huge problem we've seen with the TEE approach is that no real widespread
> adoption because of the hardware aspect.  There's a lot of bureaucracy that
> has kept everyone from playing in the space.  Hence, things like Android's
> Kitkat release introducing HCE as a viable alternative that frees you from
> the hardware implications.
> On Tue, Nov 4, 2014 at 12:03 PM, Andre Gironda <andreg at gmail.com> wrote:
>> On Nov 4, 2014 10:53 AM, "Jonathan Carter" <jonathan.carter at owasp.org>
>> wrote:
>> >
>> > Things have changed significantly over the past few years within
>> mobile.  There are now a number of new design factors that force
>> organizations to store, transmit, or process things that are extremely
>> sensitive within mobile apps now. In more and more situations, sensitive
>> code must exist within the mobile code. Here are some examples (off the top
>> of my head) where sensitive code must exist on the mobile device: offline
>> availability requirements, HCE, IoT interfaces, mobile banking, medical
>> device interfaces, etc.
>> These can also be implemented using FOSS trusted environments, such as
>> Open-TEE.
>> My suggestion would be to move the M10 language towards trusted execution
>> environments.
>> dre
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders

Jason Haddix
OWASP Mobile Top Ten Project Leader
Mobile Security Researcher
(805) 698 2885
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20141104/9c8d5e4f/attachment-0001.html>

More information about the OWASP-Leaders mailing list