微信和支付宝离线付款码,动态密码保护器实现原理探索(2)

今天这篇文章主要讲微信和支付宝的离线付款码的一种实现思路。
付款码就是我们出示给商家扫码的一种码,这种码在首次初始化之后,不用联网也可以动态生成。
本文仅代表个人的一种实现原理的探索,仅供参考,不代表实际支付宝的付款码实现方案,也许支付宝的付款码实现方案算法更加完美,更加好。

如果有更好的算法和想法,欢迎评论和我探讨。

下面是摘自支付宝的付款码功能说明:

离线使用
首次使用时,需要网络才可以进行支付。之后无须网络也可以支付

付款安全
二维码,条形码每分钟会自动更新,并会在生成之后短时间之内有效。

从首次使用,需要网络这一点可以看出,支付宝客户端肯定是向服务器请求了用来生成付款码的秘钥的。

下面是支付宝付款码的数字

2816 7565 2589 992104

微信付款码的数字

1345 7744 7121 375039

都是一样的格式,前面三个四位数的数字加上后面一个6位数的数字

再看看一下付款码的商家侧的流程,详细可以看微信支付的付款码文档

这里简单描述一下流程就是

扫码枪等商家的设备在获取到用户的付款码之后,把付款码发送到商户后台系统,商户后台系统再向微信支付系统发起支付请求,然后查询支付结果。

这里有一点需要注意的是:和上一篇文章讲的将军令的六位数的动态密码不一样的是,将军令是知道你的对应的用户信息的。但是商户后台在把付款码发送到微信支付请求支付的时候,商户后台是不知道这个付款码是哪个用户的。因为扫码设备,只是扫到了付款码的数字,然后就发送到商户后台了,是不可能追踪到时哪个用户的付款am的。所以可以肯定的是这18位的付款码数字是包含了用户信息的

所以这里和上一篇文章的6位动态密码有很大区别,那就是这18位付款码数字需要携带用户的个人信息。

这样子的话,生成18位付款码需要的条件是:

  • 每分钟随机生成
  • 一旦截图或者退出后台,付款码需要重新生成
  • 携带用户的信息
  • 必须是18位数字
  • 付款码是一次性使用的,使用过的不能重新使用
  • 和设备绑定
  • 生成后的付款码在一定时间内是有效的,也就是说假设有效期是20秒,那么为了安全,20秒前生成的付款码就报废了

所以如果要实现付款码的功能,那么需要满足上面的条件才可以。

付款码应该有两个部分,一个部分是需要解密的部分,另一个部分是纯哈希

解密部分就是需要获取到这个付款码是属于哪个用户的,纯哈希指的就是将用户设备的时间分钟级别,半分钟级别加上用户的设备识别码,用户的ip,用户的手机等信息,用户的地址,等等一系列信息做一个哈希。

然后服务器在根据解密的用户信息,在数据库里面查询用户的相关信息,同样做一个哈希,如果能匹配的话,就能证明是这个用户。

哈希这一点和上一篇文章一样很好理解,关键在于解密用户信息,同样要支持动态生成。

用户信息这个东西字段是很大的,像支付宝这种级别的应用,用户超过好几亿,就算使用简单的数字递增算法,讲过加密之后,加密的内容也是比原文多的。任何加密算法都是一样的,密文肯定是比原文的字节数要多的。否则的话,信息就要丢失,那就是哈希算法了,而不是加密算法。

假设用户的支付宝id是794850067,这里就有9位数了。9位数的话,意味着可以容纳大约10亿个id,放宽到10位数,那么支付宝就可以标记一个用户了。往前填充位数为0。

因此假设的支付宝id就是0794 8500 67 一共10位数。

接下来就是哈希信息,这个需要服务器和客户端使用相同的哈希算法和加密算法。

读者可以回到上一章节的信息,假设客户端和服务端计算得到的哈希码是676890,注意这个哈希码是和时间有关的。

假设当前时间是1561648680(秒级别),也就是10位数。

那么支付宝id加上时间组成前面十位数。当然支付宝肯定不会这么简单把前面十位数表示成时间戳加上支付宝id

这个时间戳生成肯定是有动态算法混淆的,比如当处于联网的时候,可能就把十位数再加上一个固定的数字,这个数字是保存到支付宝客户端的。

这样的话,支付宝id加上时间位数,最多不超过12位数用来表示身份信息。

然后剩下的6位数用来存放上一篇文章讲到的哈希密码。

这样支付宝在获取到付款码的时候,先解开前面的12位信息,获取到用户信息。再计算出对应的动态哈希,这样就可以验证成功了。

简单表述一下:

    alipay_id = 794850067
    unix_time_id = 1561648688
    dynamic_id = 156677889 # 这个额外id是我自己的一种设计,假想支付宝服务器和客户端协商的,每天生成不同序列的id,同步
    hash_id = 66777888 # 这个hash id是客户端计算用户各种信息做一个汇总得出的哈希
    final_id = str(alipay_id+unix_time_id+dynamic_id) + str(hash_id)
    print(len(final_id))

所以动态生成变化的就是unix_time_id ,dynamic_id,hash_id

因为前面12位数是alipay_id+unix_time_id+dynamic_id这几个相加的,所以是会动态变化的。

后面的hashid也是会变化的。

支付宝服务器收到付款码之后,可以用前面12位数减去动态id再减去时间id就可以得到用户id

然后再根据用户id计算hashid

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,377评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,390评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,967评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,344评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,441评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,492评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,497评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,274评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,732评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,008评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,184评论 1 342
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,837评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,520评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,156评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,407评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,056评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,074评论 2 352