觉得 Google Authenticator 的安全性好像有问题，

This topic created in 4303 days ago, the information mentioned may be changed or developed.

最近看到了各种手机动态口令，于是研究了下流程原理都没有问题，最后在安全性上发现了一点不明白的地方：
首先，这玩意的算法公开了。
最后的令牌依靠2个东西密钥当前的unix时间

当前的unix时间这个很花获取（一般允许有几分钟左右的误差）

密钥的获取（可通过反编译APK 或者中间人的办法来得到）
有的APK的会把密钥跟 DeviceId IME等作拼接，但是这也可以通过反编译来得到

然后就觉得这两个可控制的变量都有途径获取到。那它的安全性还有保障吗求讨论

安全性

编译

Unix

24 replies • 2014-10-28 04:37:38 +08:00

aliuwr

Oct 27, 2014

密钥是绑定的时候随机生成，然后存储在服务器和客户端。
并不会预置在什么地方。

20150517

Oct 27, 2014 via Android

密钥随机，不会通过网络传输的，估计就是当private key传过去，服务端用public key解，检查是不是同一时间戳？

mornlight

Oct 27, 2014

我觉得，如果已经到了可以接触到用户的App和控制信道的程度，大概没有什么验证手段是安全的了。发短信验证码都能被窃取呢。

nilai

Oct 27, 2014

@aliuwr 首先生成密钥的时候，如果是服务端生成的密钥，不管怎么样，最后的结果是服务端要通过网络把这密钥传给客户端，这时我HOOK网络是不是可以得到密钥的具体内容
其实再假如客户端生成密钥，不管怎么样，最后客户端也要通过网络把密钥上传给服务器，这时我HOOK网络一样可以得到密钥的具体内容

nilai

Oct 27, 2014

@20150517 你可以好好了解一下这个算法先。两边密钥得保证一样。这个不是RSA的非对称加密。

jerryjhou

Oct 27, 2014 via Android

密钥是服务器端随机生成的，客户端根据密钥生成Code（不联网）。
这个东西的目的就是解决短信验证码的到达率和延迟问题
短信验证码安全性并不比这个高（发送网关、基站、甚至SIM卡都不安全），如果可以入侵手机，连反编译都省了（不过APK里应该没有密钥，暂且当他可行吧）

iptux

Oct 27, 2014

我的理解是：密钥的传输只有在初始化的时候进行一次，之后都是直接验证算出来的验证码

evlos

Oct 27, 2014

@nilai 不是都会显示一个二维码然后我们拿手机一扫嘛，哪里过网络传了

zyxfsky

Oct 27, 2014

我只想说LZ的头像让我看了很纠结

jerryjhou

Oct 27, 2014 via Android

@nilai 你想的太复杂了，这个密钥是静态的。只有时间一个变量。
开启服务的时候服务器生成一个密钥，用户扫描二维码或手动输入密钥到客户端。然后服务器和客户端根据时间生成验证码，如果对上了就验证成功。

nilai

Oct 27, 2014

@evlos 二维码的话就更简单了。二维码的内容大概是这样子的 otpauth://totp/[email protected]?secret=DGH95HCHBHJH6GH7 DGH95HCHBHJH6GH7 这个就是密钥

47jm9ozp

Oct 27, 2014

原本只要获取一个东西（密码）就能登录变成要获取两个（密码，key）才能登陆，安全性已经大大增强了

key只在初始化的时候通过网络传输一次

当然你要考虑有心人能监听你的所有网络流量，能访问你的手机，社工出你密码，啥都防不住……

aliuwr

Oct 27, 2014

@nilai 你说的没错。不过，安全本身就是一件符合木桶定律的事情。
就算你的密码足够复杂，有 4096 个字符，但是通过 http 明文传输的话，一样会被人知道。
这个算法只是在密钥没有被泄露的前提下，提供一种便捷安全的额外认证因素。

现在短信一般通过 GSM 网络传输，淘宝上几十块就能买个监听周围所有短信的设备。
你觉得这两者相比，哪个更安全便捷？

aliuwr

Oct 27, 2014

@evlos 通过网络将密钥从服务器传输到你的浏览器。

47jm9ozp

Oct 27, 2014

我重新回复一下

这玩意用与两步验证，不是单独使用的，一般流程是输入密码->输入两步验证码->登陆

主要防范有人社工出你密码后试图登陆的情况

别人同时有你的密码和key的概率比只有密码的概率小很多，于是安全

nilai

Oct 27, 2014

@jerryjhou 我没有想得太复杂，举个例子比如现在的什么宝令，游戏账户的手机令牌等软件，事先接触到装有APK的手机，提取密钥（提取方法理论可行）现在知道算法了，时间变量这个很方便取（前面也说过了）现在比如要转某人对应的什么游戏币，就可以通过自己写程序来生成TOKEN去验证？

nilai

Oct 27, 2014

@ooxxcc 这东西的概率的确要小很多，不过我觉得我这方法至少理论上是可行的。。

wzxjohn

Oct 27, 2014 via iPhone

@nilai 你说的那些什么理论可行都没错，但是你的前提错了。如果你能得到别人的二维码，那基本上要么是你事先控制了电脑，这种情况下讨论你这个问题没意义，要么是你直接在他扫描的时候偷偷自己也扫一下，这种情况下他要是没发现那真是有点捉急了。
至于你说的什么宝令，没错，密钥显然是本地存的，但是你都能接触到他手机干这么多事，那么基本上其余的任何方法都不是安全的，谈这个问题还是没有意义。
综上，你的大前提(能随意使用别人手机)这一条已经几乎打趴下了所有安全手段，这个前提下继续讨论意义不大。基本没有安全可谈。

jybox

Oct 27, 2014

https://tools.ietf.org/html/rfc6238
这项技术是有标准的，虽然没细看过，但想必应该没啥大问题

wzxjohn

Oct 27, 2014 via iPhone

@jybox 本来就没问题，楼主的大前提错了，导致这东西看起来好像很不安全。。。

aliuwr

Oct 27, 2014

我重复下重点，
1. 物理接触：绝大多数的安全机制是不考虑物理接触的情况，比如短信验证码。
2. 木桶定律：一套安全机制具体有多安全是看最薄弱的环节，比如简单的密码。

jerryjhou

Oct 27, 2014 via Android

@nilai 在手机上安装spy组件，可以直接获取短信验证码。验证器起码还要提取。
这种验证器从一开始就是为了方便用户(短信到达延迟)而设计的，本来就不是为了增加安全性。

damajia

Oct 27, 2014

Salt+SHA256 楼主破个试试

Time(30秒一变)+secret，同上

evlos

Oct 28, 2014

@nilai 这里用 https 传输完全不用担心啊。。