互联网金融平台常见绑卡鉴权方式分析对比

1.背景

互联网金融平台账户进行开户或者支付业务时,绑卡鉴权环节是必经之路。
那么什么是绑卡鉴权?绑卡是将用户银行卡信息提供给金融平台,以后金融平台就用这个信息去银行完成支付。绑卡实际上是一个授权,让用户允许商家自动从他的账户上扣除资金,所以绑卡也叫签约,用户和银行,商家的三方签订的支付合约。 但我们知道,绑卡对用户和商户来说都存在巨大风险:一方面需要向电商暴露个人信息,一旦被窃取,资金就容易被盗走。还有在手机上执行支付,一旦手机丢失,窃取者就可以轻而易举的使用或者转移资金。

2.绑卡场景

怎么绑卡?我们知道对接银行有两种途径,直接对接银行接口和通过银联来间接对接。这两种情况下绑卡处理也不同。
绑卡场景
以支付宝、招行网银、直销app绑卡流程为例,我们可以体验下:

支付宝绑卡.png

招行一网通.png

招行掌上生活.png

这里有如下要点:
(1)只能绑自己的卡,这主要从安全角度考虑。
(2)需要用户在银行侧预留的手机号进行短信验证。但不是所有银行都需要。这个时候,为了统一处理,可以考虑自己发验证短信。

绑卡流程

这里面涉及两种类型的绑卡流程:首次绑卡和非首次绑卡

“首次绑卡”

承担着验证用户身份的功能,填写敏感信息的步骤一般需要后置,虽然有用户填错信息需要重新输入的情况,但为保证信息安全,牺牲部分体验是必要的。

“再次绑卡”

针对的用户主要是高级用户,并且这一操作不再承担验证身份的目的, 如果用户已经登录,密码输入这一步可直接过掉。

先介绍比较简单的银联直联绑卡。为了保证卡的安全,绑卡有这些前置需求:

1.用户必须已经绑定了手机号。该手机号用于修改支付密码。
2.用户需设置了支付密码。支付密码不同于登录密码。

针对用户不同状态,绑卡流程上有区别。当然,绑卡是安全操作,要求用户必须登录到系统中。为了避免和服务器端的交互被劫持,所有操作必须在安全链接中进行,即使用https。当用户开始绑卡时,执行如下流程:

1.手机号

检查用户是否有手机号。没有则进入设置手机号流程。

2.支付密码

检查用户是否设置支付密码。如果已经设置,则需要用户输入密码。确认后开始绑卡。否则,也是先进去绑卡后设置密码。

3.银行卡号信息

用户输入卡号,系统根据卡号判断卡的发卡行,并显示给用户。

4.银行预留手机号

用户输入银行预留手机。对于没有绑过卡的用户,需要用户提供真实姓名和身份证号(即首次绑卡)。对于信用卡,还需要输入cv码和有效期。这一步,卡的信息都收集全了。

5.调用银行绑卡验证接口进行绑卡。

这里有一个四要素验证的概念。由于国内要求实名制,所有银行卡都是实名办理的,所以银行可以验证姓名,身份证号,银行卡号和手机号是不是一致的,如果没问题,则会发短信到手机上。

实名认证

绑卡操作有个不错的副产品,就是实名认证。常说的二要素,三要素,四要素认证,可以通过这个操作完成。 二要素指姓名和身份证号,三要素加上银行卡号,四要素则加上手机号。看起来,似乎银行都应该支持四要素验证,但大部分银行接口仅支持三要素,毕竟手机号还是非常容易变。 当然,实名认证,也就是二要素认证,是应用最多的认证了。国内唯一的库是在公安部这,由NCIIC负责对外提供接口。可以提供如下功能:

简项核查:返回“一致”“不一致”“库中无此号”
返照核查:返回“一致+网纹照片”“不一致”“库中无此号”
人像核查:返回“同一人”“不同人”“库中无此号”

短信和身份验证

一般绑卡操作第五步需要银行下发短信验证码。 短信验证的接口,不同银行还不一样。有些银行是短信和身份验证一起做了;有些银行是可以配置身份验证是否同时发短信。还有些比较奇葩的机构,比如某联,接口中让你传身份信息,但实际上没传也是可以的,也不验证身份信息到底对不对。

此类接口一般包含如下内容:
版本号:当前接口的版本号;
编码方式: 默认都是UTF-8,指传输的内容的编码方式;
签名和签名方法: 生成报文的签名。 不是所有的字段都需要放到签名中,文档中会说明哪些字段需要签名;
签名算法:生成签名的算法,RSA, RSA128, MD5等。
商户代码:在渠道侧注册的商户号。
商户订单号:即发送给渠道的订单号;
发送时间:该请求送出的时间。
账号和账号类型: 银行卡、存折、IC卡等支持的账号类型以及对应的账号;
卡的加密信息:如信用卡的CVN2,有效期等。
开户行信息:开户行所在地以及名称;大部分是不需要的。
身份证件类型和身份证号: 可以用于实名验证的证件,指 身份证、军官证、护照、回乡证、台胞证、警官证、士兵证等。不同银行可以支持的证件类型不一样,这也不是问题。大部分就是身份证了。
姓名:真实姓名,必须和身份证一致;
手机号:在所在银行注册的手机号。

系统会返回上述数据的验证结果。如果验证通过,则会发短信。但这不是所有的渠道都是这样。哪些字段会参与验证、需不需要发短信,需要注意看接口文档。

6.绑卡签约流程

用户输入短信验证码并确认绑卡,服务器端将用户实名信息以及短信验证码组合形成报文,发送给银行,执行签约操作。银行侧签约成功后,返回签约号给商户。

绑卡接口

绑卡接口和发短信接口类似,还需要将用户的卡号,身份证等信息传递过去。在绑卡成功后,会返回一个签约号。这个签约号是后续调用支付,解约等接口所必须的。 这里有个问题,已经绑卡的用户,再绑一次,会出现什么情况?目前银行都会返回已绑卡的信息,也就是不支持重复绑卡。

3.互联网金融平台常见绑卡鉴权方式

好了,科普到此结束,回归我们今天的重点,目前从市场上来看,不同的平台封装出了不同的快捷支付鉴权方式,这些鉴权方式各有优劣,我们收集了部分常见的鉴权方式,一起来看看各自有什么特点,下面将从绑卡鉴权方式,鉴权要素,安全系数三个维度进行分析常见的绑卡鉴权对比

3.1全渠道鉴权

  • 特点:

我们较常见且较方便的鉴权方式为全渠道鉴权,即银行卡四要素鉴权,提供姓名、身份证号、银行卡号、手机号四要素绑卡成功之后,后续只需要在商户输入交易密码(短信验证码)即可进行支付。

  • 鉴权要素:姓名、身份证号、银行卡号、手机号
  • 安全性:1

目前最快捷的绑卡方式,最早应用于支付宝等第三方支付平台的银行卡鉴权,经多年验证,安全级别较高。但这种绑卡方式依赖于用户的银行预留手机号的短信验证码,因此对短信运营商的安全措施和用户的手机信息安全要求都很高。
但是事实证明,短信验证码很容易泄露。此前有过骗子通过移动运营商的“短信保管箱”业务盗取用户验证码进行盗刷的情况;同时骗子还可以通过伪基站、病毒链接、病毒二维码等植入手机木马拦截短信,以及通过社交工具伪装熟人骗取短信验证码。

3.2第三方支付平台鉴权

  • 特点:

第三方支付平台鉴权,即开户时需要对接第三方支付进行鉴权,例如易宝支付、快钱等,有些对用户无感知的,有些是用户可感知的,无感知的即不会跳转到第三方支付平台,后台帮用户隐形开户,有感知的是跳转到第三方平台页面,让用户自己提供信息进行开户,鉴权绑卡成功之后同样是只需要输入交易密码(短信验证码)即可进行支付。

  • 鉴权要素:姓名、身份证号、银行卡号、手机号
  • 安全性:1

3.3人行小额鉴权

  • 特点:

人行小额鉴权和全渠道鉴权相比多了一个银行卡类型的判断(注:银行账户分为Ⅰ类户、Ⅱ类户、Ⅲ类户),这个参数在一些场景还是比较有用的,例如绑卡的时候用来识别卡为一类户还是二类户,对防范薅羊毛等相关行为有一定作用,其他的和全渠道没什么区别。

  • 鉴权要素:姓名、身份证号、银行卡号、手机号、卡类型
  • 安全性:2

3.4银联消费鉴权

  • 特点:

银联是个比较特殊的第三方支付平台,可进行类似全渠道银行卡四要素鉴权,也可进行四要素+取款密码的方式,这由发卡行决定。与全渠道鉴权和第三方支付平台鉴权相比,不同的点在于银联鉴权允许用户在其网关页面输入银行卡的交易密码进行验证,如下两图所示,两个不同的发卡行需要的鉴权要素不一致,这由发行卡决定。

  • 鉴权要素:姓名、身份证号、银行卡号、手机号、密码(可选)
  • 安全性:3

3.5银联网关鉴权

  • 特点:

银联网关鉴权,在提供了绑卡四要素以外还需要跳转到发卡行(或者银联)的网关页面输入银行卡的取款密码进行校验,校验通过后才能绑卡成功。

  • 鉴权要素:姓名、身份证号、银行卡号、手机号、密码
  • 安全性:3

在验证了四要素信息及银行预留手机号验证码后,附加银行卡取款密码。这也是目前银联等推行的更安全的验证方式。但是让用户在互联网平台上输入银行卡取款密码需要很强的信任感,同时取款密码的输入也依赖各类插件或者SDK等,对平台的集成难度加大,也影响平台体验的统一,因此目前使用此类方式绑卡的平台不多。同时这种绑卡方式也不是无限可击,虽然多了一层密码保护,增加了骗子盗取的难度,但是目前密码泄露非常严重,更何况很多人的密码其实和他们的个人信息相关。因此这种绑卡方式虽然安全性有所提高,但是使用率也不高。

3.6小额打款验证鉴权

  • 特点:

一种相对简陋的绑卡方式,平台通过用户帐户、姓名给用户打入一笔小金额,用户正确提交入账金额给平台,由此确定用户对卡的所有权,完成绑卡。但是由于在银行的安全体系里,账户的查询权限比支付权限要低很多,渠道相对便捷,诈骗团伙通过简化版网银或通过银行客服电话等查询余额,完成银行卡所有权的认证之后,就可以将卡的查询权限提升为支付权限,隐患很大。

  • 鉴权要素:姓名、身份证号、银行卡号、手机号
  • 安全性:2

3.7小额转账验证鉴权

  • 特点:

商户会进行姓名、身份证号、银行卡号三要素鉴权,三要素通过之后商户还会要求用户使用将要绑定的银行卡向商户的对公户转入指定金额,用户需要登录网银向商户的对公账号转入对应金额,商户会校验金额是否正确,核对账户名称、银行账号是否一致,验证成功后绑定银行卡。

  • 鉴权要素:姓名、身份证号、银行卡号、手机号、密码
  • 安全性:3

与小额打款绑卡类似,把平台转账给用户变成了用户转账给平台,因此需要用户拥有银行卡的转账权限。由于能够最大限度保证持卡人的账户安全,因此,虽然操作转账相对麻烦导致用户体验上会打折扣,这种方式在互联网金融平台中接受度较高。但是,由于目前银行在做各种体验升级,每个银行的安全级别不尽相同,有些银行做创新业务尝试,很可能小金额的转账需要的授权级别比较低,如果被骗子突破用于绑卡,即可在平台实现大金额的投资交易。

以上为比较常见的鉴权方式,当然还存在其他的封装模式,不一一列举,那么上面的几种方式安全性以及用户体验孰优孰劣相信大家已经有个大概了。

4.互联网金融平台绑卡潜在漏洞及应对措施

短信验证码容易泄漏

虽然说这些鉴权方式都是比较安全的,但是盗开、盗刷、薅羊毛等因为鉴权导致的安全事件还是频繁出现,说明鉴权的风险还是存在的,主要因为上述中前几类鉴权都是提供银行卡四要素,这对于现在大数据时代(或者说黑灰产)来说,唯一相对保密的就是手机动态验证码,然而这并不能难倒黑灰产人员,黑灰产人员可以对普通用户发送钓鱼短信,短信中包含恶意链接,点击则会安装恶意APP,从而导致手机短信验证码被盗取,造成盗开盗刷等安全事件。我们对曾经捕获的恶意APP样本进行分析,进入木马收件箱可看见大量被盗取的手机验证码。

互联网金融平台该如何应对

1.同卡进出

即资金与银行卡完全绑定,确保从哪里投资回哪里去,实现资金的闭环,典型的案例如券商的银证账户。

同卡进出可以最大限度保障资金安全,即使发生盗刷,资金最终还是只能在同一张银行卡内流转,骗子无法取走。因此,当前券商、基金、保险的用户资金几乎都是同卡进出,互联网金融平台也越来越多的采用同卡进出的方案,这是平台确保客户资金安全的一把金锁。

2.提醒和教育用户

虽然平台可以通过“同卡进出”掐断提现,但是骗子的骗术层出不穷,总能找到突破口。平台还是有提醒和教育用户的责任和义务。比如可以提醒用户注意防范骗子伪装成熟人、警察,不要相信所谓“安全账户”、不要泄露短信验证码、不要点击陌生链接、不要随意输入银行卡密码等个人信息等。

3.远期风控措施

远期来看,互联网金融平台还可以尝试一些更有效更有力的风控措施,增加验证手段,提高信息盗取的难度,例如将四要素认证升级为卡密认证,以及增加视频认证等,大大增加诈骗行为的实施难度。
  与此同时,互联网金融平台可以利用行业内的风险数据的黑名单库,通过接入一些第三方平台可以进行匹配查询,进而识别风险用户。
  此外,还可以加强行为分析风控。通过行为分析、关系网分析等对风险行为进行识别,进而及时制止。还可以通过机器学习逐步建立和完善风险识别模型。

参考资料:http://blog.lixf.cn/essay/2016/10/12/account-3-bank/

时间: 2024-11-08 20:48:43

互联网金融平台常见绑卡鉴权方式分析对比的相关文章

usim 鉴权操作-USIM卡鉴权操作APDU流程

问题描述 USIM卡鉴权操作APDU流程 我正在做一个USIM卡模拟鉴权操作. 已经知道命令如下: 0088008122 10252325256348526314151225141514121025632541250214632102521452631425 目前只知道具体的APDU操作命令,但不清楚具体操作流程. 请大侠回复

Onvif开发之客户端鉴权获取参数篇

前面一篇已经介绍了客户端如何发些设备,下面这篇简单介绍下在发现设备后,如何通过ONVIF协议来获取设备的相关参数 ONVIF中不管是客户端还是设备端,最先实现的接口都是关于能力的那个接口,在客户端实现的函数名也就是[soap_call___tds__GetServiceCapabilities]通过获取的接口才知道设备具有那些能力,能够进行那些操作,服务端最基本的也需要实现这接口,让客户端知道设备支持那些基本操作.但是当设备端作了加密处理的话,即使你实现了这些接口,也不能正常获取到参数的,所以需

mongodb 3.x 用户创建和鉴权配置学习笔记

MongoDB默认安装后是不需要密码的. 此时你 show dbs 会看到只有一个local数据库,那个所谓的admin是不存在的. mongoDB 没有root,只有能管理用户的用户 userAdminAnyDatabase. ####1.设置鉴权模式#### 这里由于Mongo3以后默认的鉴权机制更改为SCRAM-SHA-1,而spring-boot直到 1.3.0 rc 仍然不支持Mongo3 的新默认鉴权方式 所以这里指定为旧版本方式MONGODB-CR #切换到admin库 use a

认证鉴权与API权限控制在微服务架构中的设计与实现(一)

作者: [Aoho's Blog] 引言: 本文系<认证鉴权与API权限控制在微服务架构中的设计与实现>系列的第一篇,本系列预计四篇文章讲解微服务下的认证鉴权与API权限控制的实现. 1. 背景 最近在做权限相关服务的开发,在系统微服务化后,原有的单体应用是基于session的安全权限方式,不能满足现有的微服务架构的认证与鉴权需求.微服务架构下,一个应用会被拆分成若干个微应用,每个微应用都需要对访问进行鉴权,每个微应用都需要明确当前访问用户以及其权限.尤其当访问来源不只是浏览器,还包括其他服务

互联网产品常见盈利模式

本文所指的商业模式即盈利模式,并非广义上的"商业模式". 上篇日志里,谈到互联网产品的商业模式,gem 同学也认同这是很重要又极其困难的一点.吴军在<浪潮之巅>里面提到过一个观点,所有 Web 2.0 的公司都没有在真正意义上找到自己的商业模式,并最终将被能成功演变为 Web 2.0 的传统互联网 1.0 巨头所超过.不过,这里的"Web 2.0"所指的对象似乎比我们通常所说的要狭义.它更看重提供开放平台,并允许其他用户使用.交互,且完全依靠 UGC ,

从1972年开始,互联网改变了人们获取知识的方式和途径

对于中美两国而言,1972年无疑是一个具有特殊意义的年份.这一年2月21日,美国总统尼克松访华,20多年来中美关系的坚冰被打破,中美关系由此翻开了崭新的一页,世界战略格局因此发生了重大变化,而带来此次巨变的乒乓外交则成了世界外交史上的经典. 也是在这一年,25岁的电脑工程师诺兰·布什内尔(Nolan Bushnell)创立了世界上第一家电子游戏公司阿塔利(Atari).在计算机世界尚处蛮荒的时代,阿塔利借助其著名的游戏<乒乓>让计算机不再只是技术天才的玩具,而变成了真正可以愉悦大众的商品. 大

互联网金融平台“拾财贷”迎来一周年庆典

1月28日消息,近日,互联网金融平台"拾财贷"迎来一周年庆典.拾财贷是中国第一家也是目前最大的一家以融资租赁债权众投平台为主的互联网金融公司,官网域名为"拾财贷"三拼域名shicaidai.com. "拾财贷"是东亮集团旗下东亮拾财贷(厦门)资产管理有限公司运营的个人对企业的P2B网络理财投资服务平台.据whois信息可知,域名shicaidai.com注册于2013年8月,在2014年12月8日有过信息更新,现已续费至2021年8月.相关shi

《移动App测试实战》——1.1 互联网产品常见的研发流程

1.1 互联网产品常见的研发流程 对于每个研发组织,因为产品的特性.组织的特点和一些历史原因,对于产品研发流程的理解和设定都有不同的考虑.但是以我们工作过的几家互联网来说,因为互联网产品的一些共同点,大致的产品研发流程其实大同小异,或者是做类似的事情但叫法不同.考虑到本书的读者可能当前的工作范围不一定是互联网产品,或者还没有机会了解整个研发流程,这里先做一些基本的介绍,也便于后面章节关于质量提升方面的讨论.为了了解流程,首先需要介绍一下互联网产品研发相关的分工,主要的角色如下:产品经理.负责产品

各路资本开始“扎堆”涌入互联网金融平台

洪偌馨 继多家银行涉足P2P业务后,另一大传统金融业机构――证券公司也瞄准了这个日益崛起的互联网金融平台行业. 近日,深圳的P2P借贷平台投哪儿网.北京的互联网金融服务平台91金融先后宣布获得来自广发信德.海通开元的投资.值得注意的是,这两家投资公司分别为广发证券和海通证券的直投子公司. 去年以来,各路资本开始"扎堆"涌入以P2P借贷.线上理财.垂直搜索等为代表的互联网金融平台.然而,随着互联网金融行业的发展和竞争的加剧,这些创业平台已经告别了单纯对资金的需求,转向考量双方资源整合的空