20180122-支付密码设计框架

Posted by PaymentGroup on January 22, 2018

今天最重要的话题,无疑是龚老师开通知乎账户了。访问这个地址:https://www.zhihu.com/people/gong-xiao-dong-31/ , 直达龚老师的知乎账户。 有支付相关的问题,可以在知乎上邀请龚老师来回答了。


主题分享

大家好,今天主要和大家交流下支付金融业务中用户安全验证方面的技术设计与架构。

支付中的用户验证场景,我们主要通过三个方面的手段来互相补充,进行安全校验:

2018-01-24 18:44:48

中间的卡验证也可以理解为实名性验证,通过一些实名信息或四六要素来进行身份校验,是准确性和安全性较高级别的验证,但是也容易因为苛刻性增大用户操作难度,所以并不是所有场合都适用;短信校验是最常见的校验方式,即时通知来提升校验的实时性;而支付密码就是支付金融场景中最重要的一道门槛。

今天主要重点介绍下密码框架的大概设计思想:

2018-01-24 18:46:49

由一个典型的密码交互过程我们可以看到,框架设计中,主要需要考虑3个方面的安全性: 传输安全、存储安全、校验安全

一、需要先解决传输的安全,怎么解决需要先想清楚我们要解决传输中可能的哪些问题:

2018-01-24 18:48:36

明确了问题后,我们可以根据目标来选取相应的技术方案来保证,主要方案如图:

2018-01-24 18:49:07

二、解决了传输问题,需要考虑密码存储的问题,这个业内主要解决方案大体一致:

2018-01-24 18:49:31

主要手段还是选一个安全性高的单向散列算法,外加随机盐。详细涉及公司机密,加密方法和盐随机性大家设计方案即可

三.最后就是校验的安全,无论是短信、银行卡、还是密码,最终校验完,目标都是去做具有安全风险的业务操作,所以操作前我们必须确认用户是做完校验正常进来的,不是伪造的hacker,那么法宝就是验证令牌,校验前用唯一的请求号来校验,校验完,安全模块生成对应的成功token下发给调用方,最后,调用方做下步业务时来校验令牌的有较性:

2018-01-24 18:49:58

今天的内容就大概讲完了,实际使用时,这三种验证方式,需要相辅相成,例如,设密码时,可能需要结合短信校验;忘记密码时,可能又需要验银行卡或短信;绑银行时,可能又会结合密码与短信;总之,我们的目标就是尽可能保证操作是用户本人,防止盗号等风险行为。


Q&A

Q: 支付密码和google的动态口令,哪个的安全性更高?
A: 这个很难说,如果密码系统中有风险的话,动态的安全性更高一些, 如果两都结合,例如我们平时生活中作中一些校验,会让你设个自己的pin密码,再加个动态码,再一起校验,这样肯定安全性更高。
但对于目前的主流支付场景,大部分公司还是选择了静态密码,这样降低用户的输入难度,提升体验。
比如,我有一个外行的朋友抱怨说支付宝密码还要数字+字母,微信支付只需要数字,所以他喜欢微信支付,所以用户的耐心是有限的。 安全与用户体验、成本始终是矛盾体。

Q: 看用在那个场景了,小额支付考虑便捷,大额支付或提现,还是组合的安全
A: 对,像银行大额甚至要电话确认或人脸识别等,但我们目前还没做到这么严格的验证。主要是交易额度也业务上暂时没放太大。


招聘信息

  • 今日头条老熊团队在招聘, 支付产品经理、研发工程师都需要,工作地点:北京、上海, 猛击这里查看
  • 有赞团队在招聘, 支付产品经理、架构师、研发工程师, 工作地点:北京、杭州, 猛击这里查看
  • 蚂蚁金服招聘互联网金融监管科技高级专家/资深专家(成都,北京), 猛击这里查看

本文档来自“支付产品架构交流群” 的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自“支付产品架构交流群”的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。目前支付产品架构群还有不少空位。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。