发明内容
本申请所要解决的技术问题是提供一种网上交易安全认证方法及网上交易安全认证系统,既能克服硬件存在的使用范围、使用寿命及技术升级的问题,又能解决当前网上交易面临的防范钓鱼、木马、木马钓鱼能力较差的问题。
为了解决上述问题,本申请公开了一种网上交易安全认证方法,包括:
生成用户端与服务端进行加密通信的随机会话密钥;
所述服务器端依据所述随机会话密钥,验证所述用户端的用户身份;
用户身份验证通过后,所述服务器端生成交易图片信息,并依据所述随机会话密钥加密传输所述交易图片信息至用户端;
所述用户端确认所述交易图片信息后,所述服务器端依据所述随机会话密钥验证交易签名。
优选的,所述生成用户端与服务端进行加密通信的随机会话密钥,包括:
在用户端生成随机数;
用预置的RSA公钥加密所述随机数;
发送所述加密的随机数至服务端;
在服务端依据所述加密的随机数生成随机会话密钥;
发送所述随机会话密钥至用户端。
优选的,所述依据随机会话密钥验证用户端的用户身份,包括:
在用户端提取用户机器信息;
用所述随机会话密钥加密用户机器信息;
传送所述加密的用户机器信息至服务端;
在服务端验证用户机器信息匹配程度;
当用户机器信息匹配程度符合预置条件时,用户身份验证通过;
当用户机器信息匹配程度不符合预置条件时,用户身份验证失败。
优选的,所述方法还包括:
在服务端生成抓取因子,并发送至用户端;
则在用户端根据所述抓取因子提取用户机器信息,用所述随机会话密钥加密用户机器信息和抓取因子,并传送至服务端;
服务端依据所述抓取因子验证用户机器信息匹配程度。
优选的,当用户身份验证失败时,所述方法还包括:
用户端发送手机短信发送请求;
服务端收到所述请求后,获取用户信息,生成手机短信验证码,并发送所述手机短信验证码至用户绑定的手机;
用户收到手机短信验证码后,在用户端输入所述手机短信验证码,并发送至服务端;
服务端进行短信验证码验证,验证通过后,发送用户身份验证通过的结果至用户端。
优选的,所述生成交易图片信息,包括:
根据交易信息、随机会话密钥、时间和用户种子,生成交易验证码;
根据交易信息和随机会话密钥,生成摘要信息;
生成底图,并将摘要信息加入所述底图;
将所述交易信息和交易验证码加入所述包含摘要信息的底图,生成交易图片信息。
优选的,所述依据随机会话密钥验证交易签名,包括:
在用户端输入交易验证码;
对交易图片信息和交易验证码用所述随机会话密钥进行数字签名;
发送所述数字签名至服务端;
服务端验证所述数字签名是否正确,并发送验证结果至用户端。
本申请还提供了一种网上交易安全认证系统,包括:OTP控件、OTP控件服务器和OTP认证平台,其中,
所述OTP控件和OTP控件服务器,用于生成OTP控件与OTP控件服务器进行加密通信的随机会话密钥,并依据所述随机会话密钥,验证OTP控件的用户身份;
所述OTP认证平台,与OTP控件服务器相连,用于在收到OTP控件服务器发送的用户身份验证通过的信息后,生成交易图片信息,并依据所述随机会话密钥加密传输所述交易图片信息至OTP控件;在OTP控件确认所述交易图片信息后,依据所述随机会话密钥验证交易签名。
优选的,在生成随机会话密钥时,所述OTP控件用于生成随机数,用预置的RSA公钥加密所述随机数,并发送至OTP控件服务器;所述OTP控件服务器用于依据所述加密的随机数生成随机会话密钥,并发送所述随机会话密钥至OTP控件。
优选的,在验证OTP控件的用户身份时,所述OTP控件用于提取用户机器信息,用所述随机会话密钥加密用户机器信息,并发送至OTP控件服务器;所述OTP控件服务器用于验证用户机器信息匹配程度,当用户机器信息匹配程度符合预置条件时,用户身份验证通过;当用户机器信息匹配程度不符合预置条件时,用户身份验证失败。
优选的,所述OTP控件服务器还用于生成抓取因子,并发送至OTP控件;则所述OTP控件根据所述抓取因子提取用户机器信息,用所述随机会话密钥加密用户机器信息和抓取因子,并发送至OTP控件服务器;所述OTP控件服务器依据所述抓取因子验证用户机器信息匹配程度。
优选的,当用户身份验证失败时,所述系统还包括:客户端脚本模块,用于发送手机短信发送请求;所述OTP认证平台还用于收到所述请求后,获取用户信息,生成手机短信验证码,并发送所述手机短信验证码至用户绑定的手机;还用于进行短信验证码验证,验证通过后,发送用户身份验证通过的结果至客户端脚本模块。
优选的,所述OTP认证平台包括:
OTP算法驱动模块,用于根据交易信息、随机会话密钥、时间和用户种子,生成交易验证码;
OTP业务系统,用于根据交易信息和随机会话密钥,生成摘要信息;
图片服务器,用于生成底图,并将摘要信息加入所述底图;还用于将所述交易信息和交易验证码加入所述包含摘要信息的底图,生成交易图片信息。
优选的,在验证交易签名时,所述OTP控件用于输入交易验证码,对交易图片信息和交易验证码用所述随机会话密钥进行数字签名,并发送所述数字签名至OTP认证平台;所述OTP认证平台用于验证所述数字签名是否正确,并发送验证结果。
与现有技术相比,本申请包含以下优点:
第一,本申请基于OTP技术、密码控件技术、交易图片签名技术等软件技术实现了网上交易的安全认证,克服了硬件产品存在的使用范围、使用寿命和技术升级的难点;
第二,本申请通过利用随机会话密钥安全地传输交易图片的方式,实现了用户交易的二次确认,即利用软件的方式实现了二代OTP技术,解决了现有的软件产品防范钓鱼、木马、木马钓鱼困难的问题;
第三,本申请通过建立了OTP控件服务器和OTP认证平台,实现了OTP技术的批量化交易;
第四,本申请提供的安全认证系统是基于软件技术构建的,易于推广,如能在第三方系统(如第三方商家、第三方支付平台)中得到应用,可以增强整个行业的安全性。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。
本申请利用软件的方式实现了一种网上交易安全认证方法和网上交易安全认证系统,既能克服硬件存在的使用范围、使用寿命及技术升级的问题,又能解决当前网上交易面临的防范钓鱼、木马、木马钓鱼能力较差的问题。
下面通过图1至图9对本申请的内容进行详细说明。
需要说明的是,图1至图9的流程中涉及到位于用户端的OTP控件、JS(一种计算机脚本语言Javascript的缩写)脚本和浏览器,以及位于服务端的网上支付网关、OTP控件服务器(图中简称为控件服务器)、OTP认证平台、业务系统和数据库。其中,OTP控件安装在用户端的机器上,配合OTP控件服务器和OTP认证平台完成网上交易的安全认证。OTP控件服务器主要用于验证OTP控件的用户身份,OTP认证平台主要完成交易验证。网上支付SSL服务器是网上交易中用于完成网上支付的服务器,业务系统主要用于网上交易业务的数据处理。
参照图1,是本申请实施例所述一种网上交易安全认证方法流程图,具体步骤如下:
步骤101,生成用户端与服务端进行加密通信的随机会话密钥;
所述生成用户端与服务端进行加密通信的随机会话密钥是指用户端与服务端进行会话密钥交互,由用户端生成随机数发送至服务端,由服务端根据随机数生成随机会话密钥和抓取因子,并返回至用户端。
参照图2所示,详细的过程如下:
S1,页面跳转至收银台;
S2,JS脚本初始化OTP控件;
S3,JS脚本生成会话密钥请求,并发送给OTP控件;
S4,OTP控件生成24字节随机数;
S5,OTP控件用预置的RSA公钥(一种公钥加密算法,名称来自三个发明者RonRivest,AdiShamirh,LeonardAdleman的姓名)加密所述随机数;
S6,OTP控件将加密的数据返回给JS脚本;
S7,JS脚本调用浏览器发送会话密钥交互请求;
S8,浏览器发送会话密钥交互请求至网上支付网关;
S9,网上支付网关转发报文至OTP控件服务器;
所述报文包含所述会话密钥交互请求;
S10,OTP控件服务器解密报文,获取客户端随机数;
具体的,OTP控件服务器用RSA私钥解密得到OTP控件的24字节随机数;
S11,OTP控件服务器生成12字节的随机数;
S12,OTP控件服务器取OTP控件的24字节的前12字节和自己的12字节,变成一个24字节的随机会话密钥;
S13,OTP控件服务器保存所述随机会话密钥到数据库;
S14,OTP控件服务器生成抓取因子;
所述抓取因子是随机抽取的n个随机数的集合,用于步骤102中抓取用户机器信息,并用于验证所抓取的用户机器信息,是本实施例的一种优选实现方式。
S15,OTP控件服务器用OTP控件的24字节随机数作为密钥加密自己的12字节随机数和抓取因子;
S16,OTP控件服务器发送会话密钥交互响应;
S17,网上支付网关转发响应报文至浏览器;
S18,浏览器接收响应报文,返回JS脚本调用;
S19,JS脚本获取密文信息;
S20,JS脚本向OTP控件发送机器信息验证请求;
S21,OTP控件用自己的24字节随机数解密所述密文信息,获得OTP控件服务器的12字节随机数;
S22,OTP控件用自己的24字节的前12字节和解密得到的12字节得到随机会话密钥,随后的报文用所述随机会话密钥加密传输;
S23,OTP控件获取抓取因子。由上可知,控件和服务端之间生成了一个随机会话密钥,而且两边各自生成一半,因此非常安全。
步骤102,依据所述随机会话密钥,验证用户端的用户身份;
所述验证用户端的用户身份包括两种方式,一种通过用户机器信息进行验证,如图3所示;另一种是当用户机器信息验证失败后,通过手机短信对用户身份进行验证,如图4所示。
参照图3所示,所述通过用户机器信息进行验证的方式又可细分为下述步骤:
S1,JS脚本将会话密钥响应报文传入OTP控件;
S2,OTP控件获取随机会话密钥和抓取因子;
OTP控件用自己的24字节解密服务端响应,并用解密得到的12字节替换24字节的后12字节,最终得到所述随机会话密钥。
S3,OTP控件提取用户机器信息;
OTP控件根据抓取因子提取用户机器信息。用户机器信息采取编号的形式,每个编号对应抓取因子中的一个随机数,假设某次的抓取因子包含10个随机数,则对应这10个随机数提取对应编号的机器信息。OTP控件每次提取部分机器信息。
由于抓取因子是随机的,因此每次根据抓取因子提取的用户机器信息也是不同的。例如,控件服务器在某一次下放的抓取因子为16个随机数,而随后在下一次下放的抓取因子又为20个随机数,那么对于同一个OTP控件和同一个用户机器,每次抓取的用户机器信息都是不同的,从而提高了用户身份验证的安全性,这也是本实施例的一种优选实现方式。其中,用户机器信息包含机器的硬件信息,也可以包含软件信息,如操作系统版本等。
S4,OTP控件用随机会话密钥加密用户机器信息,并返回至JS脚本;
如果采用抓取因子的方法,则OTP控件还会把抓取因子同用户机器信息一起加密发送。
S5,JS脚本调用浏览器发送请求报文;
S6,浏览器发送请求报文至网上支付网关;
S7,网上支付网关转发报文至OTP控件服务器;
S8,OTP控件服务器读取数据库信息;
S9,OTP控件服务器根据抓取因子比对数据,逐个判断用户的机器信息是否变更;
通过比对抓取因子对应的值,即将根据抓取因子抓取的用户机器信息和数据库中所述抓取因子对应的值进行比对,判断用户的机器信息是否变更。
S10,当用户机器匹配成功率符合预置条件时,认为此用户机器匹配成功;
所述符合预置条件可以是,用户机器匹配成功率>=80%,此时认为用户身份验证通过;当用户机器匹配成功率<80%时,认为用户身份验证失败。
S11,OTP控件服务器返回成功报文至网上支付网关;
S12,网上支付网关转发成功报文至浏览器;
S13,浏览器接收成功报文,并返回JS脚本调用。
参照图4所示,所述通过手机短信进行用户身份验证的方式又可细分为下述步骤:
其中,S1至S9与图3中的S1至S9相同,在此略,下面从S10开始说明;
S10,当用户机器匹配成功率不符合预置条件时,认为此用户机器匹配失败;
如前所述,所述符合预置条件可以是,用户机器匹配成功率<80%,此时认为用户身份验证失败。
S11,OTP控件服务器返回失败报文至网上支付网关;
S12,网上支付网关转发失败报文至浏览器;
S13,浏览器接收报文,返回JS脚本调用;
S14,JS脚本从业务系统获取短信验证码验证页面;
S15,JS脚本展现所述页面;
通常,所述页面提示用户输入手机号码或其他用户相关信息;
S16,JS脚本发送短信发送请求至控件服务器;
当用户在上述页面输入手机号码其他用户相关信息后,JS脚本发送短信发送请求;
S17,控件服务器发送短信发送请求至OTP认证平台;
S18,OTP认证平台从业务系统获取用户信息;
所述用户信息可以是用户手机号码,也可以是用户名、电子邮箱、联系地址等其他相关信息;
S19,OTP认证平台生成验证码;
OTP认证平台是根据用户信息生成验证码;
S20,OTP认证平台发送短信请求至业务系统;
S21,由业务系统发送短信给用户绑定的手机;
其中,所述短信中包含了OTP认证平台生成的验证码,参照图5所示,是手机短信显示的信息内容示意图;
S22,用户收到所述短信后,在网页上输入短信验证码;
S23,JS脚本发送短信验证请求至OTP控件服务器;
S24,OTP控件服务器转发短信验证请求至OTP认证平台;
S25,OTP认证平台对手机验证码进行验证;
S26,验证成功后,OTP认证平台发送验证成功请求至OTP控件服务器;
S27,OTP控件服务发送验证成功响应至JS脚本;
S28,JS脚本向OTP控件发送抓取机器信息请求;
S29,OTP控件抓取所有的机器信息;
S30,OTP控件向JS脚本返回抓取的机器信息;
其中,OTP控件用随机会话密钥加密机器信息;
S31,JS脚本调用浏览器提交抓取的机器信息;
S32,浏览器向网上支付网关发送请求报文;
S33,网上支付网关向OTP控件服务器转发报文;
S34,OTP控件服务器更新用户机器信息;
S35,OTP控件服务器向网上支付网关发送响应报文;
S36,网上支付网关向浏览器转发响应报文;
S37,浏览器向JS调用返回响应报文;
S38,JS脚本收到响应报文,完成用户身份验证。
步骤103,用户身份验证通过后,生成交易图片信息,并依据所述随机会话密钥加密传输所述交易图片信息至用户端;
由服务端生成交易图片信息,所述交易图片信息可参见图7所示,并由服务端将交易图片信息发给用户端。
参照图6所示,用户端获取交易图片信息的过程具体包括:
S1,JS脚本发送用户机器验证结果至OTP控件;
当然,如果机器验证失败并采用手机短信验证方式,则可以将手机短信验证结果发送给OTP控件;
S2,OTP控件发送交易图片信息获取请求至JS脚本;
S3,JS脚本发送交易图片信息请求至浏览器;
S4,浏览器发送交易图片信息请求至网上支付网关;
S5,网上支付网关转发报文至OTP控件服务器;
S6,控件服务器发送获取交易图片请求至OTP认证平台;
S7,OTP认证平台根据订单号获取交易信息;
OTP认证平台从业务系统获取此次请求对应的订单号,并依据所述订单号获取对应的交易信息,所述交易信息包括交易内容、交易金额、交易时间等如图7所示的信息。
S8,OTP认证平台根据交易信息生成图片要素;
所述图片要素是指生成交易图片信息的要素,如交易验证码、摘要信息、底图等要素。
S9,OTP认证平台生成交易图片信息;
在OTP认证平台中,由图片服务器利用图片要素生成交易图片信息;
其中S8和S9生成交易图片信息的详细过程可参见图8所示流程;
S10,OTP认证平台用随机会话密钥加密交易图片信息,发送交易图片信息响应至OTP控件服务器;
S11,OTP控件服务器发送交易图片信息响应至网上支付网关;
S12,网上支付网关转发响应报文至浏览器;
S13,浏览器接收报文,返回JS脚本调用;
S14,JS脚本向OTP控件展示图片。
参照图8所示,在OTP认证平台中生成交易图片信息的过程具体包括:
1)OTP算法驱动根据交易信息、随机会话密钥、时间和用户种子生成交易验证码;
其中,所述时间是指交易时间,所述用户种子是一个20个字节的随机数,每个用户都有一个种子,而且都不一样。
2)OTP业务系统根据交易信息和随机会话密钥生成摘要信息,每一项交易对应唯一的摘要信息;
3)图片服务器生成底图;
4)将摘要信息加入底图,摘要信息与底图颜色一样;
5)将所述交易信息和交易验证码加入所述包含摘要信息的底图,生成交易图片信息。
步骤104,在用户端确认所述交易图片信息后,依据所述随机会话密钥验证交易签名。
所述验证交易签名是指用户获取交易图片信息后,从交易图片中获取交易验证码,并输入交易验证码确认交易,OTP控件对交易图片和交易验证码进行数字签名并发送至OTP认证平台,OTP认证平台验证数字签名是否正确并返回交易签名认证结果至用户端。
参照图9所示,具体包括:
S1,JS脚本发送图片展现请求至OTP控件;
S2,OTP控件展现交易内容信息,显示的交易图片信息参照图7所示;
S3,用户在OTP控件输入交易验证码;
S4,OTP控件对交易图片和交易验证码利用随机会话密钥进行数字签名;
S5,OTP控件发送签名验证请求至JS脚本;
S6,JS脚本发送签名验证请求至浏览器;
S7,浏览器发送交易信息图片请求至网上支付网关;
S8,网上支付网关转发报文至OTP控件服务器;
S9,OTP控件服务器发送交易签名验证请求至OTP认证平台;
S10,OTP认证平台验证签名是否正确;
S11,OTP认证平台发送交易签名验证结果至OTP控件服务器;
S12,OTP控件服务器发送交易图片验证响应至网上支付网关;
S13,网上支付网关转发响应报文至浏览器;
S14,浏览器接收报文,返回JS调用;
S15,进行后续处理。
综上所述,上述安全认证方法在传输过程中加入随机会话密钥,保证了整个传输过程的交易图片信息不会被篡改,同时图片信息变成在控件里面显示,并随着用户输入密码,控件对图片和密码签名,加密传输到服务端验证,这样就保证了整个交易过程中的安全性。
以上所述的用户是指OTP控件用户,所谓OTP控件用户是指安装了OTP控件并进行实名认证和手机绑定的用户。对于原密码控件用户,参照图10所示,升级为OTP控件用户的流程具体包括:
用户打开浏览器,输入支付网站网址,获取页面信息,网上支付网关下发带升级信息的脚本,通过浏览器显示,用户看到升级的提示,用户点击升级,向下载服务器提出下载请求,下载服务器将数据传输至浏览器,用户进行安装;更新后第一次支付,页面展现请求报文,网上支付网关查找用户类型,对于非实名认证用户,返回要求实名认证的页面,浏览器返回实名认证的页面,并展现给用户;用户登录身份信息和银行卡信息,浏览器发送实名认证请求,网上支付网关验证身份并打款,业务系统发送打款响应,网上支付网关转发报文至浏览器;用户输入打款和手机信息,浏览器发送验证请求,网上支付网关转发至业务系统,业务系统发送验证结果,浏览器展现验证结果给用户。
对于新用户申请,用户在注册后,按照上述图10所示流程操作即可升级为OTP控件用户。
此外,在步骤102验证用户身份的过程中,服务端首先通过用户机器信息验证用户身份,如果验证失败会再通过手机短信验证的方式验证用户身份,因此,用户绑定的手机号对安全支付来说是非常重要的信息。所以用户绑定的手机号变更需要通过以下两种方式之一才能完成:
一种是采用往用户注册邮箱发邮件的方式,用户通过邮件链接验证身份,然后更新新手机号码;
另一种是通过客服电话,有客服验证用户身份后,更新用户手机号码。
基于上述方法实施例的说明,本申请还提供了相应的系统实施例。
参照图11,是本申请实施例所述的一种网上交易安全认证系统结构图。
所述安全认证系统可以包括OTP控件10、OTP控件服务器20和OTP认证平台30,其中,
所述OTP控件10和OTP控件服务器20,用于生成OTP控件10与OTP控件服务器20进行加密通信的随机会话密钥,并依据所述随机会话密钥,验证OTP控件10的用户身份;
所述OTP认证平台30,与OTP控件服务器20相连,用于在收到OTP控件服务器发送的用户身份验证通过的信息后,生成交易图片信息,并依据所述随机会话密钥加密传输所述交易图片信息至OTP控件10;在OTP控件10确认所述交易图片信息后,依据所述随机会话密钥验证交易签名。
其中,在生成随机会话密钥时,所述OTP控件10用于生成随机数,用预置的RSA公钥加密所述随机数,并发送至OTP控件服务器20;所述OTP控件服务器20用于依据所述加密的随机数生成随机会话密钥,并发送所述随机会话密钥至OTP控件10。
其中,在验证OTP控件的用户身份时,所述OTP控件10用于提取用户机器信息,用所述随机会话密钥加密用户机器信息,并发送至OTP控件服务器20;所述OTP控件服务器20用于验证用户机器信息匹配程度,当用户机器信息匹配程度符合预置条件时,用户身份验证通过;当用户机器信息匹配程度不符合预置条件时,用户身份验证失败。
进一步优选的,所述OTP控件服务器20还用于生成抓取因子,并发送至OTP控件10;则所述OTP控件10可以根据所述抓取因子提取用户机器信息,用所述随机会话密钥加密用户机器信息和抓取因子,并发送至OTP控件服务器20;所述OTP控件服务器20可以依据所述抓取因子验证用户机器信息匹配程度。
进一步优选的,如图12所示,当上述用户身份验证失败时,所述系统还可以包括:
客户端脚本模块40,用于发送手机短信发送请求;
所述OTP认证平台30还用于收到所述请求后,获取用户信息,生成手机短信验证码,并发送所述手机短信验证码至用户绑定的手机;
用户收到手机短信验证码后,在客户端脚本模块40中输入所述手机短信验证码,并发送至OTP认证平台30;
所述OTP认证平台30还用于进行短信验证码验证,验证通过后,发送用户身份验证通过的结果至客户端脚本模块40。
进一步优选的,所述OTP认证平台30具体可以包括:
OTP算法驱动模块,用于根据交易信息、随机会话密钥、时间和用户种子,生成交易验证码;
OTP业务系统,用于根据交易信息和随机会话密钥,生成摘要信息;
图片服务器,用于生成底图,并将摘要信息加入所述底图;还用于将所述交易信息和交易验证码加入所述包含摘要信息的底图,生成交易图片信息。
其中,在验证交易签名时,所述OTP控件10用于输入交易验证码,对交易图片信息和交易验证码用所述随机会话密钥进行数字签名,并发送所述数字签名至OTP认证平台30;
所述OTP认证平台30用于验证所述数字签名是否正确,并发送验证结果。
对于上述安全认证系统实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
为了更好地理解本申请的内容,下面再结合几个黑客攻击的具体案例分析利用本申请提供的方法和系统如何能防范钓鱼、木马、木马钓鱼。
1、支付网站站内钓鱼
站内交易替换是近期出现的一种木马病毒变种,木马在支付网站站内创建一笔即时到帐交易,如:我要付款,然后跳转回收银台让用户支付。
站内交易替换的过程,参照图13所示:
①用户在购物网站购买商品后,用户点击确认购买,浏览器跳转到支付网站收银台后,木马拦截正常的支付流程;
②木马将浏览器导向支付网站即时到帐页面;
③木马生成一笔“我要付款”订单,收款方为欺诈者的网上支付账号;
④浏览器跳回支付网站收银台;用户看到自己需要支付一笔订单,这笔订单实际上会支付到欺诈者的网上支付账号;
⑤用户选择付款;
⑥用户支付木马生成的即时到帐订单,钓鱼过程结束。
在本申请的方案中,因为用户的交易信息是以图片形式传入控件显示,而且整个过程是由应用层的随机会话密钥加密,即使黑客创建一笔新的交易,他也无法让这笔交易的图片传入控件,因为每个控件的随机会话密钥不一样,黑客的图片无法用用户控件的随机会话密钥解密。
2、钓鱼到第三方外部商家
此类型木马的钓鱼步骤参照图14所示:
①用户机器感染木马后,木马会监听浏览器的URL地址栏;用户在购物网站购买商品后,用户点击确认购买;
②浏览器跳转到支付网站收银台后,木马会拦截正常的支付流程,跳转至另一个第三方外部商户;
③木马在用户客户端登录欺诈者的外部商户账号,然后生成一笔同样金额的订单,该订单使用支付网站进行付款;
④浏览器会跳回支付网站收银台;这时候,用户看到自己需要支付一笔订单,这笔订单实际上会支付到欺诈者的外部商户账号;
⑤用户选择付款;
⑥用户实际支付了一笔外部商户订单,支付网站会付款给所述第三方外部商户,钓鱼过程结束。
从以上流程可以看出,这种木马钓鱼不仅与支付网站的安全相关,而且与被钓鱼的第三方外部商家的安全性紧密相关。如果能将本申请的方案应用到第三方外部商家,因为绝大多数外部商家没有能力建设完善的安全体系,那么由支付网站提供客户端控件和服务端服务的方式,就可以防止这种木马。
3、钓鱼到第三方支付平台
此种木马钓鱼方式是用户通过在支付网站收银台的时候,木马去其他第三方支付平台生成一笔网银充值订单,诱骗用户进行网银充值付款。参照图15,详细过程如下:
①用户在收银台页面进行充值操作;这个操作可能由很多原因发起,如:用户在购物网站购买商品,进入收银台准备付款;用户发起一笔“我要付款”即时到帐交易;用户在个人版点击交易详情进行付款等;木马会监听浏览器的URL,当用户准备付款时,木马就拦截正常的操作流程;
②木马将浏览器导向其他第三方支付平台,并登录欺诈者的账号;木马可以使用下列方式将浏览器导向第三方支付平台:
(1)修改浏览器的跳转地址,跳转至第三方支付平台;
(2)修改网银订单提交表单的跳转地址;这种方式和图15中的流程稍有不同,需要木马在远程服务端动态生成一笔网银订单,然后远程发送给木马客户端,木马篡改页面中的表单信息;这种方式在木马出现初期较为常见;
(3)其他形式;木马在短时间内做大量的URL跳转,比如木马会在用户点击去网银充值时,不直接进行拦截,而在浏览器跳转到网银页面后,再跳转去盛大;
③无论木马在第二步会使浏览器跳转多少次,都会到第三方支付平台生成一笔网银充值订单;
④用户在浏览器看到自己需要支付一笔网银订单,支付的银行和金额和正常交易流程相同,但是网银充值收款方不是支付网站;
⑤用户没有注意充值收款方,进行了充值;
⑥银行将钱充值进欺诈者的帐号,钓鱼过程完成。
从以上流程可以看出,这种木马钓鱼不仅与支付网站的安全相关,而且跟被钓鱼的第三方支付平台的安全紧密相关。如果能将本申请的方案应用到第三方支付平台,由支付网站提供方案,第三方支付平台自建系统,方案被推广后,可以防止这种木马。
综上所述,本申请包含以下优点:
第一,本申请基于OTP技术、密码控件技术、交易图片签名技术等软件技术实现了网上交易的安全认证,克服了硬件产品存在的使用范围、使用寿命和技术升级的难点;
第二,本申请通过利用随机会话密钥安全地传输交易图片的方式,实现了用户交易的二次确认,即利用软件的方式实现了二代OTP技术,解决了现有的软件产品防范钓鱼、木马、木马钓鱼困难的问题;
第三,本申请通过建立了OTP控件服务器和OTP认证平台,实现了OTP技术的批量化交易;
第四,本申请提供的安全认证系统是基于软件技术构建的,易于推广,如能在第三方系统(如第三方商家、第三方支付企业)中得到应用,可以增强整个行业的安全性。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
以上对本申请所提供的一种网上交易安全认证方法和网上交易安全认证系统,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。