In theory this is true..

> I firmly believe that secrets can be sufficiently obfuscated 

> in code delivered in binary format without the benefit of a 

> symbol table, so as to be sufficiently resistant todiscovery 

> via disassembly by attackers you'd expect to encounter in a

> typical commercial environment.

In practice there are an extremely small number of cases where this is actually 
done right, and legions of cases where it's done wrong.  Industry just doesn't 
get this right often enough to rely on it.

-bill



________________________________
From: Dave Nelson <dnel...@elbrys.com>
To: Skylar Woodward <sky...@kiva.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Sent: Wednesday, June 1, 2011 12:43 PM
Subject: Re: [OAUTH-WG] Text for Native Applications

> The group is operating under the assumption that most
> native apps are publicly deployed or that copies of the
> app bundle/binary can at least be obtained by a malicious
> party.

Agreed.

> ... its always possible for the attacker to disassemble the
> program and obtain the secret.

Always possible?  In theory, perhaps.  As with any threat analysis, it
depends on the resources available to the attacker and the motivations
for mounting the attack.  I firmly believe that secrets can be
sufficiently obfuscated in code delivered in binary format without the
benefit of a symbol table, so as to be sufficiently resistant to
discovery via disassembly by attackers you'd expect to encounter in a
typical commercial environment.  I'm not talking about printable
strings stored in contiguous memory.

I think it's important, for a number of use cases, some of them of
particular interest to me, for an application to be able to use this
form of identification, when sufficient care has been taken to
mitigate the threat model for the intended use.  I'd rather see the
risks inherent in providing secure storage of application credentials
thoroughly discussed in the Security Considerations section, rather
than discouraging it's use altogether in the normative protocol
definition sections of the draft.  I agree that there are many
deployment scenarios in which secrets or passwords would not be an
appropriate method of client identification, but I see some in which
is clearly would be appropriate.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to