【发布时间】:2013-01-11 20:34:58
【问题描述】:
当 Android oauth 2.0 客户端应用程序具有硬编码的凭据(客户端 ID 和客户端密钥)时,反编译应用程序和检索凭据非常容易。
暴露 client ID 和 Secret 会有什么后果?
【问题讨论】:
标签: android security oauth-2.0
当 Android oauth 2.0 客户端应用程序具有硬编码的凭据(客户端 ID 和客户端密钥)时,反编译应用程序和检索凭据非常容易。
暴露 client ID 和 Secret 会有什么后果?
【问题讨论】:
标签: android security oauth-2.0
我知道这不是一个好的 StackOverflow 答案,但我觉得无法比威胁模型和安全注意事项 (RFC 6819) 更好地解释它。所以这里是关于获取Client Secret 及其相关后果的段落。
请注意,Android 应用是公共客户端(更具体地说是原生应用),因此,正如您所说,无法对其凭据保密,但仍能够保护令牌和授权代码。
您的案例也很有趣,还有一个关于 smartphones 的示例。
我知道 RFC 并不是最有趣的读物,但它们非常清楚。
【讨论】:
据此,这是一个安全问题: http://software-security.sans.org/blog/2011/03/07/oauth-authorization-attacks-secure-implementation
如果链接停止工作,下面是它所说的:
OAuth 对基于浏览器的授权的依赖性为默认情况下不在用户浏览器中运行的移动或桌面应用程序带来了继承实现问题。此外,从纯粹的安全角度来看,主要关注的是实现者何时在客户端应用程序本身中存储和混淆密钥/秘密组合。这使得密钥轮换几乎不可能,并允许未经授权访问存储消费者机密的反编译源代码或二进制文件。例如,要破坏 Android 上 Twitter 客户端的客户端凭据,攻击者可以简单地使用 Android 反汇编工具 dexdump 反汇编 classes.dex:
dexdump - d classes.dex
以上内容更详细,读起来非常棒。
【讨论】:
请注意:客户端 ID 并非设计为机密,因此实际上没有必要保护它。
参见section 2.2 in RFC 6749(“OAuth 2.0 授权框架”):
客户端标识符不是秘密;它向资源所有者公开,不得单独用于客户端身份验证。
【讨论】: