0


支付安全常见问题

支付安全常见问题

1.支付面临的主要安全问题

1、账号或密码等敏感信息被盗用

用户的账号和密码可能会被黑客获取,导致个人资金被盗用

2、交易信息被篡改

常见就是支付金额被篡改,比如实付金额小于应付金额,还就是转账时的收账账号或金额被篡改

image.png

还有情况就是在转账场景下修改收款账号或金额,当转账请求被黑客截获,把原收款账号修改为另一个账号,再发给支付平台。如果支付平台安全措施不到位,就可能把钱转到一个错误的账号上

image.png

3、交易信息被抵赖

举个场景,支付平台请求银行扣款200元,银行实际扣款失败,但是通知支付平台成功,支付平台也通知商户发货了。但是银行说他们返回给支付平台是扣款失败,扣款成功的信息不是银行发出来的。这种行为是抵赖

image.png

4、欺诈交易

包括套现、洗钱等违规交易,以及因为用户信息泄露导致盗刷等

5、服务不可用攻击

攻击者通过大量恶意流量占用支付系统的资源,使得合法用户无法正常访问支付平台,从而影响用户的交易体验甚至造成财务损失

image.png


2.支付安全核心关注点

1、敏感信息安全存储

对个人和商户/渠道的敏感信息进行安全存储

个人敏感信息包括身份证信息、支付卡明文数据和密码等,而商户/渠道的敏感信息则涉及商户登录/操作密码、渠道证书密钥等

2、交易信息安全传输

确保客户端与支付系统服务器之间、商户系统与支付系统之间、支付系统内部服务器与服务器之间、支付系统与银行之间的数据传输安全。这包括采用加密技术等措施来保障数据传输过程中的安全性

3、交易信息的防篡改与防抵赖

确保交易信息的完整性和真实性,防止交易信息被篡改或者被抵赖。一笔典型的交易,通常涉及到用户、商户、支付机构、银行四方,确保各方发出的信息没有被篡改也无法被抵赖

4、欺诈交易防范

识别并防止欺诈交易,包括套现、洗钱等违规操作,以及通过识别用户信息泄露和可疑交易来保护用户资产的安全。这一方面通常由支付风控系统负责

5、服务可用性

防范DDoS攻击,确保支付系统的稳定运行和服务可用性。通过部署防火墙、入侵检测系统等技术手段,及时发现并应对可能的DDoS攻击,保障支付服务的正常进行

下图是一个极简版的支付安全大图,包含了支付安全需要考虑的核心要点:

image.png


3.支付数据安全

加密与解密

加密和解密技术是数据安全的基础,在支付安全技术的核心技术之一,无论是支付平台与银行之间的通信,还是支付平台内部敏感数据的存储,都需要用到加解密技术

1、针对对称加密算法:

AES目前被认为是最安全和最常用的对称加密算法,推荐在支付行业使用。密钥长度建议使用256bit或以上

有些银行要求整个报文进行加密,这个时候一般都是使用AES 256来加密

2、针对非对称加密算法:

RSA当前在支付行业应用最广泛,ECC则逐渐成为移动设备和物联网设备中的首选算法,因其在资源受限环境下的高效性能而备受青睐。RSA推荐密钥长度为2048bit或以上,ECC推荐密钥长度为256bit或以上

3、数字信封加密算法

在一些场景里面,需要同时组合使用AES和RSA,比如大数据加密使用AES,AES密钥通过RSA加密后传输,并通过RSA进行签名,这样既解决了安全性,又解决了加密速度的问题,这就诞生了数字信封加密算法

数字信封加密算法组合了对称加密、非对称加密、数字签名和验签等多种加密技术,用于在网络通信中保护数据的安全性和完整性。传输的数据就像放在信封里面,只有收件人才能打开信封查看明文,所以被形象称为数字信封加密

它的原理是使用对称加密算法对要传输的数据进行加密,然后再使用接收方的公钥对对称密钥进行加密,再使用自己的私钥进行签名,最后将加密后的对称密钥和加密后的数据一起发送给接收方。接收方先使用对方的公钥进行验签,再使用私钥解密对称密钥,最后使用对称密钥解密数据

image.png

现在很多银行的打款文件要求使用PGP加密,因为文件里面有卡号等敏感数据。PGP通常推荐使用RSA 2048和AES 256,前者用于加密对称密钥和签名,后面用于加密大数据块

千万千万不要自己去发明一种【私有的】,【自己认为很安全】的算法,并应用到生产环境。因为业界推荐的这些算法的安全性是经过大量数字家和计算机科学家论证过的,也经过工业界持续地验证

典型应用场景

通常以下几个核心应用场景都会用到加解密技术:

image.png
1、传输加密

保护交易数据在互联网上传输过程中的安全,防止数据被窃听或篡改,具体的实现通常有两种:

  • 通道加密:比如使用HTTPS,或者VPN、专线等,实现数据传输端到端的加密
  • 报文数据加密:部分字段单独加密,比如把卡号等关键信息进行加密后再发出去。整体报文单独加密,先生成业务报文,然后对整个报文加密再发出去

2、存储加密

对敏感数据比如信用卡信息、用户身份证信息、密码等需要进行加密后存储到数据库中,以防止数据泄露

image.png

具体的实现通常也会分两种:

  • 直接加密:原始信息直接加密。通常用于信用卡、身体证等常规数据的加密
  • 加盐值(SALT)后再加密:原始信息先加上盐值,然后再进行加密。通常用于密码管理

登录与支付密码的特殊处理

1、传输层面

image.png

输入时一般会有安全控件,直接获取输入,其它应用无法在输入盗取。然后使用公钥加密,传输到后端后,再使用私钥解密,再进行转加密,最后保存到DB,或和DB的密码对比判断。

2、存储层面

image.png

通过为每个用户加盐,即使是相同的密码,由于盐值不同,加密后的密文也是不一样的。保护相同密码的用户。如果多个用户使用了相同的密码,没有盐值情况下,一个被破解后,就能找到使用相同密码的其它用户。每个用户不同的盐值,确保生成的密文不同。增加破解难度。尤其是密码较弱时,显著增加攻击者难度

还需要留意加盐策略:

随机和唯一:每个用户都是随机和唯一的。存储盐值:每个用户的密码和盐值都需要配对存储。因为在加密密钥更新时,需要使用盐值一起先解密再重新加密。盐值足够长:增加复杂性,推荐至少128位。

PCI认证

如果要保存用户的卡明文数据(比如用户名和卡号),就一定要经过PCI(Payment Card Industry)认证,在PCI认证范围内的域叫PCI域

image.png

简单地说,PCI规定了一个单独的区域(简称PCI域),可以处理用户的卡明文数据,包括加密后存储,或使用明文,这个区域的网络安全部署、数据访问控制、数据加密、日志打印、安全策略等全部都有由PCI DSS规定,并定期接受相关认证组织的审查。

特别注意的是,PCI标准要求所有的域都不能打印用户敏感信息,所有的域都不能存储明文用户敏感信息,比卡号只能打印前6后4,只有PCI域范围内的应用才能使用卡明文数据。


4.支付签名与验签技术

签名与验签技术概述

防篡改与防抵赖一般也称为数据的完整性和真实性验证问题,通常使用签名验签技术解决

签名:发送者将数据通过特定算法和密钥转换成一串唯一的密文串,也称之为数字签名,和报文信息一起发给接收方。

验签:接收者根据接收的数据、数字签名进行验证,确认数据的完整性,以证明数据未被篡改,且确实来自声称的发送方。如果验签成功,就可以确信数据是完好且合法的。

image.png

签名验签主要解决3个问题:

  • 身份验证:确认支付信息是由真正的发送方发出,防止冒名顶替
  • 完整性校验:确认支付信息在传输过程中未被篡改,每一笔交易都是完整、准确的
  • 防抵赖性:避免任何一方否则曾经进行过的交易,提供法律证据支持

安全支付流程:

双方先交换密钥,可以通过线下邮件交换,也可以通过线上自助平台交换。请求方发出交易报文前使用自己的私钥进行签名,接收方接收报文后先进行验签,验签通过后再进行业务处理。接收方处理完业务,返回前使用自己的私钥进行签名,请求方接收返回报文后先进行验签,验签通过后再进行业务处理

image.png
在支付场景来说,RSA使用最为广泛,密钥长度推荐2048比特

一些与防篡改有关的技术

1、数字摘要

数据摘要是一种通过对数据进行计算(也称为哈希、摘要、散列计算),生成固定长度的唯一数据串(通常称为摘要或哈希值),用于验证数据的完整性和一致性的技术。数据摘要通常用于验证数据在传输或存储过程中是否发生了更改。

上面有个缺陷,就是在传输过程中,报文被黑客截获,然后把100万字的文章和摘要报文全部替换,服务端发现不了的。这个缺陷在下面的HMAC算法中会解决。

当前在支付行业推荐的摘要算法是SHA256

需要说明的是,数字签名需要用到数字摘要算法,但是数字摘要算法不能替代数字签名。因为数字摘要只能证明数据是否完整,无法证明数据一定是某个人或某个机构发出来的。

2、HMAC算法

HMAC算法结合了哈希函数和密钥,通过对消息进行哈希运算,并使用密钥进行加密,生成一个唯一的摘要。这个摘要就是消息的认证码,用于验证消息的完整性和真实性。

HMAC因为使用摘要算法和对称加密,运算简单而快速,所以许多场景下,HMAC是一种简单而有效的选择,也被用作消息的完整性保护和身份验证。所以在支付场景下,也经常用于签名验签。

但需要说明的是,HMAC解决了纯摘要算法的部分问题,但仍不是严格意义上的数字签名算法,因为HMAC使用的是双方都拥有的对称密钥,无法证明消息一定是对方发出的,因为也有可能是某方伪造的。

3、数字时间戳

数字时间戳是一种用于确定特定事件发生时间的数字签名或哈希值,通常由数字时间戳服务(DTS:digital time-stamp service)颁发。数字时间戳将特定事件的时间信息与数字签名或哈希值绑定在一起,以确保该事件在特定时间之前已经存在,从而防止后续的篡改或伪造。

image.png

数字时间戳的应用场景主要在文件证明,电子邮件,数字证书等,比如法律文件、合同、知识产权、证书等,以证明在某个时间之前就存在了这份文件。

不过在支付系统中,目前比较少使用数字时间戳。


5.身份认证技术

常见的身份认证方法

在支付安全领域,身份认证就是确认支付交易的参与者是否是其声称的身份。简单地说,就是证明你是你

身份认证通常分为个人身份认证和企业/机构身份认证。常见的个人身份认证方法包括以下几种:

  • 用户名和密码认证:最常见的身份认证方式,但安全性相对较低,容易受到密码猜测、密码泄露等攻击。
  • 多因素认证(MFA)。就是要求用户同时使用2种方式验证身份,包括密码、短信验证码、指纹识别、人脸识别、硬件令牌等。一般是后台风控识别有风险时,才会这样。也经常叫风控挑战。
  • 生物特征认证。使用个体的生物特征(如指纹、虹膜、声纹、人脸等)来进行身份验证。这种认证方式通常需要专门的硬件设备来捕获生物特征,并使用算法进行比对。
  • 单点登录(SSO)与Oauth。用户只需在一个系统登录,就可以授权访问其它系统。
  • 数字证书。由CA机构颁发个人数字证书,这个比较少见。

数字证书

数字证书(Digital Certificate)是一种用于在网络通信中进行身份验证和数据加密的安全技术。它是由一家被称为证书颁发机构(Certificate Authority,CA)的可信任实体颁发的电子文档,用于证明某个实体(如网站、个人或组织)的身份和公钥。

数字证书包含以下主要信息:

  • 公钥: 数字证书中包含了一个实体的公钥,用于加密和解密通信数据。
  • 持有者信息: 数字证书中包含了证书持有者的身份信息,如姓名、电子邮件地址等。
  • 颁发者信息: 数字证书中包含了颁发该证书的证书颁发机构的信息,包括机构名称、联系方式等。
  • 有效期限: 数字证书中包含了证书的有效期限,即证书的生效日期和失效日期。
  • 数字签名: 数字证书中包含了颁发者对证书内容的数字签名,用于验证证书的真实性和完整性。

在网络通信中,当客户端与服务器建立安全连接时,服务器会向客户端发送自己的数字证书。客户端收到服务器的数字证书后,会使用证书中的公钥来验证服务器的身份和证书的真实性。如果验证通过,客户端就可以使用服务器的公钥加密通信数据,并将加密后的数据发送给服务器。

比如你访问以https开头的网站,浏览器就会验证网站服务商的证书。

在支付系统中,某些银行在对接时会要求双向证书认证。


6.常见的传输安全协议

所有数据全部经过加密后再传输比较麻烦,能不能简单一点,我们直接把传输的管道进行加密,然后传输明文数据?答案当然没有问题,比如SSL,TLS,HTTPS,专线等都是这个范畴

SSL/TSL

SSL协议的主要功能包括:

  • 加密通信: SSL协议使用加密算法对通信数据进行加密,以防止被窃听者窃取敏感信息。它支持多种加密算法,包括对称加密算法(如DES、3DES、AES)和非对称加密算法(如RSA、Diffie-Hellman)等。
  • 完整性验证: SSL协议使用消息认证码(MAC)或数字签名来验证通信数据的完整性,以防止数据被篡改。接收方可以通过验证MAC或数字签名来确保收到的数据未被篡改。
  • 身份认证: SSL协议支持服务器和客户端之间的身份认证,以确保通信双方的身份是合法的。服务器通常会提供数字证书来证明其身份,客户端可以使用证书来验证服务器的身份。SSL还支持双向身份认证,即客户端和服务器都可以进行身份认证。
  • 会话管理: SSL协议支持会话复用,以减少握手过程的开销和提高通信效率。

SSL协议最初广泛应用于Web浏览器和Web服务器之间的安全通信,用于保护网页传输的敏感信息,如用户名、密码和信用卡信息等。随着SSL协议的发展和演进,它逐渐被TLS协议所取代,但人们通常仍将TLS协议统称为SSL。

TLS(Transport Layer Security,传输层安全)协议是一种用于保护网络通信安全的协议。它建立在SSL(Secure Sockets Layer,安全套接层)协议的基础上,并在SSL的基础上进行了改进和扩展。

HTTPS

HTTPS(Hypertext Transfer Protocol Secure)是一种用于安全传输超文本的通信协议。它是在HTTP协议的基础上加入了SSL/TLS协议进行数据加密和身份验证,用于保护网络通信的安全性。

简单地理解,就是HTTP全部是明文传输,HTTPS构建在SSL/TSL之上,所有传输的数据是经过加密的。

除了HTTPS之外,还有其它一些传输协议是构建在SSL/TSL之上的,比如文件传输协议FTP是明文传输,SFTP也是基于SSL/TSL之上的加密传输。

专线

专线是一种物理连接,通常由电信提供商提供,用于在两个或多个地点之间建立私有的、专用的网络连接。专线可以是光纤、电缆或其他物理媒介,通常具有固定的带宽和可靠的连接质量。专线不依赖于公共网络,因此通常具有更高的安全性和稳定性,适用于需要高可靠性和低延迟的应用场景。

简单地说,专线很贵,更适用于需要高带宽、低延迟和高安全性的应用,如数据中心互连、企业网络内部连接等。

像支付宝与银联、网联就是通过专线连接。以前一些大支付公司和大银行直连时,一般也是通过专线连接。


7.支付风控

风控系统最核心最宝贵的资源是风控策略,因为如果知道一家支付公司的风控策略,就意味着可以想办法绕过支付系统的风控系统,进行欺诈交易。所以一般来说,研发风控系统的研发工程师往往不知道风控策略是怎么配置的。

image.png

虽然风控的策略是高度机密,但是有些公开的策略,大家可以了解一下,比如说下面这些就属于行为异常,大概率会被风控:

你一直在中国小额支付,突然在国外支付2万。平时一直使用IPHONE(风控会保存你的设备详细信息),突然使用Android机器支付2000块。一般都是10天买件商品,实然10分钟内支付50笔。

现代的风控系统不仅仅是策略,还有很多机器学习算法。但总的来说,仍然围绕:当次支付行为,历史交易数据,配置的规则策略,规则引擎,机器学习等展开。


8.统一密钥存储与安全服务

有一个公式是这样的:密钥的价值 = 密文的价值。比如你加密存储的密文价值10亿,那对应的密钥价值也有10亿

密钥的管理涉及4个方面:密钥存储、更新、备份和恢复、废止和销毁。如果想要管好这些密钥,就需要建设一个统一的密钥存储服务,否则密钥很容易被泄露。

密钥分为主密钥工作密钥,其中工作密钥用来加解密普通的业务数据,而主密钥用来加解密工作密钥。

一般来说主密钥应该存储在专门的硬件安全模块(HSM)中,俗称:硬件加密机,安全性极高。但是相对来说性能有限,且价格昂贵,管理复杂。

工作密钥一般由主密钥加密后保存在DB中,在需要的时候调用主密钥解密后,缓存在内存中,然后再去加解密普通的业务数据。

同时,密钥需要定期更新,减少被破解的风险

image.png


本文转载自: https://blog.csdn.net/Gherbirthday0916/article/details/140692653
版权归原作者 世界尽头与你 所有, 如有侵权,请联系我们删除。

“支付安全常见问题”的评论:

还没有评论