存档

2010年10月 的存档

手机应用的信任关系

2010年10月25日 没有评论

前几天参加了支付和移动互联网峰会,写了一些想法。这几天还在思考一个问题:如何才能信任一个手机应用呢?

对于基于网页的应用,这个问题比较好解决。我们在浏览器里打开某网站地址,可以通过检查URL是否正确,对于https的地址,还可以查看安全证书。如果这些都没有问题,就可以确认访问到的网站是我们希望的,而不是李鬼。

对于应用程序,有数字签名来保证一个程序是某开发者发布且没有被修改过。当确认签名没有问题的时候,就可以放心使用了。

看看上面两种情况,为什么能信任一个以前没有接触过的网页或应用呢?我觉得这是信任的传递过程。对于网页应用,首先,我信任使用的浏览器,才确定浏览器展示给我的URL和安全证书是网页本身的;我信任安全证书签发机构,才信任证书的使用者。这是把对浏览器和证书签发机构的信任传递到网页上。对于应用程序,我信任操作系统,才确定展示给我的数字签名的确是应用本身的;我信任数字签名签发机构,才信签名的使用者。这是把对操作系统和数字签名签发机构的信任传递到应用上。

到了手机上,对于网页,没有什么差别,但对于应用来说,情况有所不同。

看看Android的情况。每个应用发布时都需要签名,但这个签名是应用开发者自己创建的签名,没有第三方机构签发。手机上的操作系统还是可以信任的,但操作系统并不能把应用的签名情况展示给用户。

单单对于一个应用本身,我无法确认是不是声称的开发者发布的。当我要找某银行的应用时,Google market上的应用都不一定可靠,因为任何人都可以发布一个声称是银行的应用。Google在发布环境基本没有审察,即使是钓鱼也会在Market上被用户看到。这条路无法建立信任,我通常会到银行的官方网站,通过其提供的链接来下载应用。这相当与把对网站的信任传递到应用上。

在iPhone上,情况好一些。因为app store有发布前的审察机制,肯定不能100%过滤,但会提高钓鱼者成本。对于银行、交易相关应用,还是小心一些为好,最好也通过官方网站链接访问。

应用内支付IAP (In-App Purchase),问题就更大了。信任链在应用这就已经断掉了,应用的身份无法信任,我怎么能信任这个应用展示给我的支付界面呢?看到Paypal、Alipay都在做这个工作,但就目前的情况来说,我不看好。对于钓鱼,恐怕都是事后处理,而不能在之前防范。有用户被钓鱼,自然不敢使用;有防范意识的用户,知道钓鱼程序无法识别的话,可能会拒绝所有程序。这样,这个市场随着一些用户被钓鱼和一些用户增强防范意识,会变得越来越小。

App store也有IAP,但使用的是自己的支付手段,钓鱼者最多得到用户的app store帐号或者让用户用这个帐号购买一些东西,但交易后如果用户发现,可以向app store申诉。这样,钓鱼者即使钓鱼成功也未必能有收益,买卖就不划算了。这个方式并不是建立信任链,而是通过控制支付达到的。

但第三方支付就不这么容易了。Alipay似乎可以在其界面输入银行帐号密码来直接从银行转帐。钓鱼这可以仿造支付界面,骗取银行信息。对Alipay来说,他的任何代码和服务器都没有参与这个行为,怎么能找他负责呢?银行也没有看到有这笔交易,除非用户在输入信息后立即发现问题,否则银行也无法发现。

即使Alipay使用了淘宝的收货后确认付款的机制,也是有问题的,原因仍然是在于对应用没有信任。不像网页上,操作都是在淘宝/支付宝的域名下完成,手机上的交易是在一个没有信任关系的应用里进行,我并不知道我的帐号信息发给alipay服务器的同时是否还被这个应用留了一份。不过,如果使用收货后确认付款的机制加上OTP (one time password),应该就会安全了,因为即使应用留了一份帐号信息,也是无效的。

总之,由于手机系统的原因,信任不能传递到应用,仅仅在手机应用本身的支付是不安全的,要做的话,需要在手机之外打些补丁。

分类: Android, iOS 标签: ,

手机支付的思考

2010年10月20日 没有评论

今天,听了支付宝支付和移动互联网峰会,会上介绍了支付宝的手机支付。会上提到的支付方式,是与Apple的IAP (In-App Purchase) 类似,在应用中通过调用支付宝的接口来实现支付,购买游戏中道具或关卡、以及应用中的某些功能。

演示这个支付方式的程序,是运行在Android平台的,但这是Google Android market明文禁止的。前些天我还听说有Android开发者因为在程序中使用了Paypal支付方式而被Google suspend了。这样说来,使用这种支付方式就不能在Google Android market上发布了。不过,要是在其他market发布,现在没听说哪个非Google的market能占绝对的市场份额,开发者就要忙于在各个market发布了。

在介绍过程中,我还想到另一个问题:如何防钓鱼。开始时我只是觉得或许会有人钓鱼,窃取用户资料。在会议结束后,恰好碰到一个阿里巴巴的人,和他讨论了这个问题,他也没说出什么好的解决办法,更多的是事后补救。在回来的路上,我又仔细想了想,这个问题影响将很大,不仅仅是被钓鱼者,也会使有防范意识的人不敢使用这种支付方式。

先来看看正常的支付过程:某个应用中,有需要付费的项目,用户点击后,进入到支付宝界面,用户在支付宝界面中输入用户帐号密码,成功后返回应用。

那么,钓鱼的应用也可以在界面上模仿这个过程,只不过不使用支付宝界面,而是用自己的界面模拟支付宝。在获取用户资料后,发给钓鱼服务器。

电脑上,可以通过安全控件防止监听键盘,通过检查url来防止把账户信息输入到不信任的服务器上。但对于手机用户来说,并不知道这个支付界面的到底是谁的,支付宝还是钓鱼程序,因为支付界面都是由一个未必通过认证的程序展示出来的。

某个界面,并没有url可以让用户检查。虽然有package的名字,但对用户不可见,并且这也是可以模仿的。

在支付界面显示预留信息,或者短信认证,也不是安全的办法。首先,要显示预留信息,就要求用户先登录,之后才能判断。这时即使发现问题,用户帐号也已经泄露了。另外,钓鱼程序可以通过夹在用户和支付宝之间,做一个代理来获取帐号信息,骗过用户。这里不存在电脑上MITM会遇到的证书错误问题。

其他防钓鱼的方法,我能想到的就是在程序之外验证,比如OTP (one time password),这肯定能保护帐号,但需要额外设备,有成本。

这个认证是一个双向认证,用户要认证服务器是正确的服务器,而服务器也要认证用户身份。在电脑上,这个过程有CA机构签发证书保证,但手机上缺少了这个角色,就无法认证服务提供者。OTP可以说是另一个认证服务器的方式,来保证服务器的身份。

或者,如果确认程序本身是没有恶意的,也可以。但目前的Google market没有审核机制,这个无法保证。Apple的app store也有IAP方式,但因为程序是要经过审核的,钓鱼程序会被审核过滤,也很难有鱼上钩。

Android程序虽然有签名,但这是开发者自己建立的签名,并不能说明身份。不像ssl证书,是由可信机构签发。

总之,问题的根本在于要求我输入帐号信息的界面不能证明自己是支付界面,只能通过程序之外来证明,增加了认证成本。但目前没有看到这方面的支持,在解决这个疑问之前,没有防范意识的用户有安全风险,有防范意识的用户也无法识别真伪。

不知道Google禁止第三方支付是不是也基于这个原因,或许是为了保证用户安全。

分类: Android 标签: ,