手机支付安全解决方案演进

 手机支付安全涉及内容很多，需要从终端侧、平台侧多个维度进行解决。涉及终端安全、web安全、框架安全、数据安全、风险控制等多方面。

本文主要围绕如何在终端侧构建手机支付安全解决方案。

以支付宝为例，微信也是类似。目前的安全机制是围绕短信认证展开的。为啥就得围绕短信验证码展开呢？原因很简单：

1）总比纯粹的用户名/密码好些吧。要是纯粹的用户名/密码，一方面可能是用户名/密码被盗，另一方面也容易被钓鱼。

2）在移动终端上可以发送和接受短信。

3）其实PC上有很多安全机制，比如专用otp、u盾等等，但大家用的比较多的也是手机校验码。面向智能终端的硬件设备目前也有，比如基于耳机孔、蓝牙的U盾，OTP设备等。

4）手机校验码虽然存在很多问题，但体验好啊！安全是服务于业务的，而不是凌驾于业务之上，成为业务推广的瓶颈。做安全的切记，安全是绿叶，是要衬托业务这朵红花的，切勿本末倒置，空谈绝对安全。

1、支付宝如何围绕短信认证构建：

切勿hack这个号码，里面有近百万的巨资。支付宝里面涉及登陆密码和支付密码。

如何找回登陆密码？还是短信验证码，后来又增加了身份证。

如何找回支付密码呢？是一个webview指向的网站，还得去网页找回密码。这家伙可麻烦了，我经常会忘记密码。

我看了一下网页找回支付密码的流程，和找回登陆密码类似，增加了银行卡校验，但手机客户端非把这玩意搞到网页来修改，是何道理？产品经理何在？

2、支付宝围绕短信认证码构建存在哪些问题？

      1）看报道就知道了，丢了手机可能会找回登录密码（现在还需要身份证号码，有身份证和手机号对应的社工库吗？），找回支付密码（现在需要银行卡卡号）。

除了丢失手机，由于补办sim卡引起的漏洞，导致用户的sim卡被非法使用。 由于丢手机和补卡的风险，所以才产生了身份证、银行卡等额外的需求。

     2）目前找回密码都是通过短信认证码完成的， 登陆和支付主要靠静态密码校验，那么存在被钓鱼的风险。不过问题不大，通常支付宝客户端检测到新的账户后会要求短信检验码认证。

但如果是一个定制版的支付宝客户端，钓鱼得到了静态密码，结果会咋样？

3）不管是静态密码还是短信认证码

    都是承担认证的作用，对业务数据没有起到保护作用。所以，单纯的认证远远不能解决问题。这儿建议读者理解一下银行二代U盾和一代U盾的差异性。

  除了钓鱼等手段，要想直接获取用户输入或者篡改用户输入以及自动模拟用户完成都需要root权限，现在android root的终端很多，但这类恶意软件比较少！

他们迟早回来的，这些事情完成起来很难吗？在iOS越狱的机器上很常见，iOS的安全体系很完备，但其攻击体系也很强大！

  微博上看到一张图，其实iOS的hook、注入都是现成的工具。据我了解，一些android底下组织已经有类似的工具了。

4、手机有没有可信源啊？

     如果仅解决认证的问题，不考虑交易数据篡改、自动执行以及槽糕的用户体验（一大堆密码），基于短信构建如果设计完备的话，是可以的。      

但需要考虑交易数据篡改等威胁吗，那是肯定的。

那么在手机上有没有可信跟？真的有！手机的sim卡就是独立于AP还客观存在。网上搜一个智能终端的架构：

从图上可以看到，sim卡长期潜伏在cp侧，承担网络鉴权的任务，sim只有不多的几条api如读取imsi可以提供给AP侧供android调用。

但sim卡这么多年了长进不大，一心一意做好鉴权！只有最近的nfc出来