在安全领域有两个基本的原则:
1、 没有绝对安全,安全是相对的;
2、 所有的简单、方便都是以牺牲安全程度为代价的,只是看你如何权衡罢了。
个人认为,在手机上支付,各种条件尚有欠缺,环境尚不成熟,为时过早。(钱袋、盒子支付、拉卡拉推广的卡槽式手机支付理论上属于传统的POS机支付,不属于严格意义上的手机支付,不属于这里涵盖的范围)
 
移动支付的密钥在哪儿?
简单的用户名和静态密码都是容易被破解或窃取的(无论如何组合数字和字母,多少位),已经不能满足今天电子支付的安全要求了。所以,银行目前普遍采用“用户名+密码+密钥”三合一的方式来实现用户身份的认证。“用户名和密码”就是你在银行开户时设定的,而“密钥”是你下载到U盾保存(也由银行发放)的数字证书或者银行发放的带有显示屏的六位到八位的动态令牌。

无论是数字证书还是动态令牌,都是代表你身份的唯一象征,就好比你的指纹是你的唯一标识。对于银行而言,每一个用户都具有唯一的数字证书或者动态令牌,反之亦然。
用户的“密钥”和PC机独立是电子支付的最基本的要求。如果早期使用过网银的客户一定记得,最初数字证书是备份在PC机的硬盘里的,之所以现在要备份到一个独立的U盾里,就是为了将你的“密钥”与PC分离。这样,即使有黑客能够侵入你的电脑,没有数字证书或者动态令牌显示的数字也无法完成资金的转移。
前几年有一些用户在电脑支付完忘记拔U盾而被黑客将银行账户的资金转走,所以,现在的网银在你退出的时候都会提醒你,“你的U盾还未拔掉,建议您拔掉U盾“(动态令牌不存在这个问题)。

U盾的操作系统是专有的,很少有人会破解U盾,所以,只要U盾不在PC机上,该PC也就无法与银行建立一条加密的隧道,你就有了一层很坚固的保障。

动态令牌的工作原理是简单地来说就是一种密码算法。理论上来讲,只要有足够长的时间和良好的设备,任何密码都可通过穷举法加以破解,即把所有的密码组合全试一次。但对于动态令牌的一些算法(如MD5、SHA-1),使用穷举法寻找它的冲突至少需要进行2^80次运算,这对于我们来说近乎不可能。试想我们使用一台每秒运算30亿次的计算机,运用穷举法去寻找一个冲突,到找到为止需要花费多少时间呢?大概需要1200万年以上!
目前微信使用的,据我观察(没有看到任何介绍),有点类似短信动态令牌方式,即用户方无需一个动态令牌的实体,服务器端通过短信网关将动态令牌发送下来。所谓动态令牌,就是不断变动的六位或者八位数字。数字一旦出现,永不重复,这就保证了即使黑客窃取你的密码,过了密码的存活周期后,也无法进入系统进行身份认证,所以,动态令牌有时也叫一次性口令,One Time Password,简称OTP。动态令牌的存活时间从几秒钟到几个小时可调,根据你实际的应用场景设定,一般为30-60秒更换一次。
动态令牌的显示数字是依靠某种算法运算所得。服务器端运算出来一个结果,并通过短信发送给手机端,然后用户将这六位数字录入,传递到服务器端进行对比,验证用户的身份。这里先不去考虑密码编制算法的可靠性(是否真的有MD5等那样坚固,我没有看到任何资料说微支付密码采用何种算法,不好评价),仅就短信传递密码,就存在可达性和安全性的问题。

根据目前运营商的平均水平,短信的到达率大约在95%左右,但遇到一些特殊情况,如节假日,有可能会发生延迟、丢失的现象。比方说,刚刚过去的双十一。短信一般不用于关键信息(对丢失、时延敏感)的传递,也属于“best effort”尽力而为范畴。
而且,短信虽然在传递中,报文是加密的,但依然容易被拦截且破解。这样,也会造成动态密码的泄露。所以,主流的动态令牌形式是一个独立于任何设备(无论PC还是手机)的硬件设备,也像U盾一样(很多银行、证券公司采用),只是多一个显示数字的屏幕。
动态令牌一旦激活,在使用过程中将不会再与服务器发生通讯,用户不可能通过空中截取。

动态令牌内部是靠一个小CPU按照与服务器同样的算法分别运算着。每一时刻,服务器跟动态令牌的数字都是一致的,所以,无论何时需要身份的认证,无需通讯,动态令牌跟服务器的数字也会保持正确。
无论是数字证书,还是动态令牌,移动支付的需要一个分离的“密钥”,才能称得上安全。目前我看到的多数解决方案在这方面都有欠缺,是皇帝的新装?
手机本身的安全无法保证
 
智能手机的快速普及,使今天的手机已经与昨天的手机不可同日而语。但是在带给人方便的同时,也将PC端带给大家的问题复制过来了。手机上的各种漏洞层出不穷,尤其是基于开放的安卓系统的手机,在方便的同时,也方便了别人窃取你的信息。任何一个应用,都可以采集你的诸多私密信息。苹果手机由于采用封闭系统,要略好一点,但也不是没有漏洞,只要有心可为,还是有空子可钻。在这一样环境里,完成支付,真的有点“裸奔”的感觉。
虽然现在有了手机版的360安全卫士,安全管家等等,但并没有一个真正的行业标准规定大家该如何做,只是一个建议。而多数网民对此更是一无所知,即使看到了建议也不会像PC端那样从容应对。

之前的手机应用,大多属于非关键类业务,即使有些信息泄露也无伤大雅。但如果真的用来支付等直接跟钱打交道的业务,个人认为还是为时过早。
综合上述两个方面,老李还是认为先别急着在手机上玩支付,等手机的安全体系完成再说吧。而且,从另一方面,各家移动支付的玩家们也在完善自己的解决方案,老李从运营商们的手机支付规范中,都看到了明确的“密钥”分发的环节,说明这一问题已经引起了足够的重视。假以时日,这并不是一个不可解决的问题,只是目前,尚不成熟。
手机支付的出路
前面分析了目前的手机支付存在的问题,如果单纯考虑用移动端本身来解决这一问题,个人认为必须有比较完善的密钥发放和管理机制才能算是一个完整的解决方案。
按照目前可以看见的产品(包括已经面市和在研发中),大概分为三大类。第一类是NFC近场支付,这也是个人最看好的未来的一种支付方式;第二类是通过外接设备来完成密钥的保存;第三类是将支付风险转化到PC端。
三大类中,后两类相对比较成熟,设备和支付方案都有比较严格的金融机构审核。从本质意义上来说,后两种方案其实还是传统支付方案的延续,只是换了个手机终端的形式而已。NFC方案目前还属于发展中的一个方案,由于配套的终端识别设备(POS机部署或者传统POS机改造)以及终端标准(13.56M&2.4G)的待定,尚需时日。
3.1、NFC近场支付
NFC是Near Field Communication缩写,即近距离无线通讯技术。是一种非接触式识别和互联技术,可以在移动设备、消费类电子产品、PC 和智能控件工具间进行近距离无线通信。
NFC以其快捷便利安全迅速得到大众的喜爱。在日本,DOCOMO大约在六七年前就推出了FeliCa移动支付业务,拥有NFC功能的手机用户,可以通过手机在全国的am/pm连锁店购物。

NFC目前的工作频段只要有13.56M和2.4G两种。这也是银联与中国移动之所以迟迟未能达成一致的主要原因。因为银联倾向的标准是前者,而移动倾向的标准是后者。2012年6月两家最终签订合作协议说明双方可能在这一方面达成了某种妥协。

从形式上,NFC目前主要的也可以分成拖尾式和RFID-SIM卡方式。

拖尾式就是无需更换手机,将射频功能部分集成于双界面SIM/UIM卡中,射频部分天线直接与SIM/UIM卡高速管脚相连。射频天线可以采用拖尾的方式与SIM/UIM卡相连,也可定制于手机中。
拖尾式的好处是无需更换手机,只需更换SIM卡,符合移动运营商在SIM/UIM卡加载安全及移动支付应用的要求。天线采用SIM/UIM卡拖尾方式对手机外观要求较高,不是每款手机都适合采用此方式。
RFID-SIM方案采用将射频单元(包括射频模块、天线)直接集成到有源SIM/UIM卡上的方式工作,工作频率为2.4GHz。目前,中国移动主要采用的是此方案。

无论是拖尾式,还是RFID-SIM卡模式,密钥都可以保存在独立的电子钱包存储器里。所有的SIM卡应用,必须通过一种只有SIM卡厂商才有的编译器编译方可,所以外人很难破解,里面的密钥是安全的。(老李曾经做过一款SIM应用,编译过程非常复杂,不是外界常用的系统,而且SIM卡厂商基本都不对非运营商之外的第三方提供服务。)
3.2、在外接设备中集成密钥
目前,主流的围绕手机(包括SIM卡)外接的移动支付方案也有三种。一种是以钱袋、拉卡拉、盒子支付为代表的从手机音频口外接刷卡槽方案;还有一种是在手机的SIM卡上贴片方案;第三种是在手机的SD卡中保存数字证书(银联曾考虑过此方案)。
外接卡槽式

这一种方式可以将一个外接的刷卡槽插入手机的音频接口,从而使手机变成了一个移动POS机。它只利用了手机的通讯和运算功能,而密钥可以保存在卡槽设备里。除了需要刷卡的时候插入终端外,其他时间卡槽和手机终端是分离状态的。这样就保证了密钥和手机终端分离的目的,从而达到手机支付安全的目的。
手机贴片式
这种方式主要围绕原有的SIM卡进行改造。在原来的SIM卡基础上,贴上一个小贴片,贴片与SIM卡可以合二为一,插入原来的SIM卡槽。手机贴片模式的支付完成,是通过SIM卡应用菜单实现的。在每个人的手机里,都有一个SIM卡应用的菜单。用户开卡(贴片模式完成后,需要拿专用的POS机来完成开卡激活,与运营商无关,是服务提供商的服务范围)。
理论上来讲,贴片式的贴片也是跟手机分离的,密钥也可以保存在贴片里。而且,贴片的激活机制也需要通过POS机非常复杂但专业的流程实现。所以,贴片式的支付也是安全的。
SD卡模式

中国银联也曾考虑过SD卡模式,即在手机的SD卡中保存数字证书,也就是密钥。用户现需要安装保存在SD卡中的客户端程序,然后需要开卡激活该客户端,即下载保存数字证书(密钥)。然后就可以通过客户端中的相关操作完成支付了。
上面三种模式,是目前手机支付领域比较主流的三种外接设备的工作方式。个人比较倾向卡槽方案,一不改变人的使用习惯,也无需绑定、更换信用卡;贴片方式开卡流程非常复杂,需要有专人用专用的POS机激活,不利于大面积推广;SD卡模式的加密是个问题,如果把密钥保存在SD卡中,不太可能有用户只在使用支付的时候才换上专用的SD卡,如果长期携带会有安全隐患(就如同U盾在PC机上长连接一样)。
3.3、转化到PC端解决
第三种解决方案是目前支付宝模式。因为用户可以并不直接在移动端关联银行卡。而通过支付宝账户做了一层缓冲。用户完全可以通过PC端的操作来完成从银行账户到支付宝的关联乃至转账,再通过PC端与移动端一致的支付宝账户完成购买商品的支付。这样即便有风险,也只是支付宝移动端账户的风险,而不是你银行卡所有资金的风险。而在PC端完成支付已经是非常成熟的业务了。当然也有的用户喜欢在移动端来完成支付宝到银行卡的关联,个人建议不要这么做。
如果今天非要用手机完成支付的话,那么个人认为后两种方案还是可取的。第一种NFC近场支付,需要等待整个体系的建立完成,如标准、POS机设备等。
其他的解决方案,个人认为尚不完善,其安全性有待考察。

转载于:https://www.cnblogs.com/helenR/p/weixin_zhifu.html

今天的移动支付,还是很不安全[转]相关推荐

  1. 汇总少了退款汇总 多了一笔支付汇总 很可能是因为商户退款配置的是正交易权限(配置的问题)

    1t_busi_trans_detial 业务表 2t_mchnt_chk_result 商户对账表 3t_trans_sum_detail_two 汇总表(业务明细汇总sum_type=01 商户分 ...

  2. iOS支付宝(Alipay)接入详细流程,比微信支付更简单,项目实战中的问题分析

    最近在项目中接入了微信支付和支付宝支付,总的来说没有那么坑,很多人都说文档不全什么的,确实没有面面 俱到,但是认真一步一步测试下还是妥妥的,再配合懂得后台,效率也是很高的,看了这篇文章,你也只要几分钟 ...

  3. 第三方支付接口的技术比较研究

    发表期数:2011年第11期 所在版块:实践与应用 作者:李安渝 孙秋雯 摘 要:第三方支付市场的发展前景乐观,但同时市场竞争也越来越激烈.随着第三方支付业务许可牌照的发放,第三方支付将很可能打破大型 ...

  4. 小白也能看懂的教程:微信小程序在线支付功能开通详细流程(图文介绍)

    微信小程序不仅是一个展示平台,更多会用到小程序的电商功能,当然了,支付目前而言需要接入微信支付,那么具体而言,微信小程序要怎么开通支付功能呢?最近需要在微信小程序中用到在线支付功能,于是看了一下官方的 ...

  5. 比特币现金(BCH)支付进入DIY时代

    支付可以很简单,不过是买和卖之间的资金流通,支付也可以很复杂,曲折的购买路径与数不清的点击次数影响着买家的支付体验.于是,两个月前,PayPal推出带有智能支付按钮的PayPal Checkout,旨 ...

  6. 强监管下 协议支付会是互金平台救命稻草?(协议支付是代扣协议的升级版)

    近期,第三方支付的快捷支付.代扣代付渠道骤然收紧,导致多个行业不同程度受到影响,互金受到的冲击最为直接明显. 尤其是消费金融和P2P网贷行业,因为对监管尺度的负面预期,情绪上的恐慌大于对业务的实际影响 ...

  7. P2P平台选择网关支付、第三方托管、第三方+银行联合托管有什么区别?

    ▍PMCAFF产品经理社区的咖友提问:互联网金融领域现在有哪些主流的商业模式? ● ● ● ▍  Lily  北京烤鸭 产品经理 一.先来说下资金托管 先看看百度上"资产托管"词条 ...

  8. 挖洞技巧:支付漏洞之总结

    支付漏洞一直以来就是是高风险,对企业来说危害很大,对用户来说同样危害也大.就比如我用他人账户进行消费,这也属于支付漏洞中的越权问题.那么支付漏洞一般存在在哪些方面呢,根据名字就知道,凡是涉及购买.资金 ...

  9. ping html 微信支付,说说PING++介入微信H5支付,我趟过的坑。

    PING++:号称几行代码,搞定支付,很神奇吧.究竟有那么神奇吗,让本农(本码农)慢慢揭开神秘面纱吧. 项目背景:由于项目改版,领导决定,采用PING++支付,笔者这次作为PHP后端开发,更形象的讲其 ...

  10. 场景化支付的关键技术

    四.场景化支付的技术支撑 随着大数据.人工智能.云计算.移动互联技术的发展,普惠金融时代的到来,为了更好地服务用户,支付产业需要进行技术升级,满足各种场景需求.除了大数据和云计算等场景化支付的基础技术 ...

最新文章

  1. iOS 中的网络请求 (同步请求、异步请求、GET请求、POST请求)
  2. sdut 2128 树结构练习——排序二叉树(BST)的中序遍历
  3. 真正开始记录自己学习技术过程的点滴
  4. c++ 6.0 没有找到mspdb60.dll 问题的解决
  5. C语言编写一个赋值程序,实验2 用C语言编写简单程序——2.1 基本数据处理.doc
  6. python标准库之socket
  7. php中函数封装怎么弄,php封装函数步骤
  8. PHP用301重定向根域名到www域名
  9. 王健林:用深刻教训换来的8点心得
  10. 2016版excel_一招鲜,吃遍天之四:高效办公必备工具——Excel 易用宝
  11. 【Vue】报错Parsing error: No Babel config file detected for D:\VuecliWorkspace\vue_test\src\main.js.
  12. 问卷调查报告html,问卷调查报告格式优秀范文
  13. 【Opencv】图像分割——区域生长
  14. Faker最新仓库地址更新 4/6
  15. 手机银行消息服务器,服务与功能_手机银行_服务介绍_个人电子银行_电子银行频道_建设银行...
  16. 死理性派恋爱法:拒绝掉前面37%的人
  17. CreateProcess的用法
  18. 使用opencv调用摄像头识别颜色(python版)
  19. 64位操作系统安装——Linux(Ubuntu 16.04)+Windows7+iNode
  20. JAVA生成二维码(二)深度处理

热门文章

  1. l1范数最小化快速算法【文献阅读】
  2. 出席国际海水稻论坛-林裕豪:从玉农业谋定陆丰稻作改良
  3. SpringIOCAOP
  4. 20172329 2017-2018-2 《程序设计与数据结构》实验四报告
  5. 微信小程序配置WSS协议
  6. spring 配置文件无法加载,junit找不到xml配置文件java.lang.IllegalStateException: Failed to load ApplicationContext...
  7. Ubuntu中root用户和user用户的相互切换
  8. VS怎样创建和使用lib文件
  9. Java中的Serialization
  10. 对 UI 设计师来说,iPhone X 意味着什么?