手機(jī)沒(méi)網(wǎng)了,卻還能支付,這是什么原理?
編輯導(dǎo)讀:在一些信號(hào)很差的地方,手機(jī)沒(méi)網(wǎng)了卻依然還能支付,這是什么原理呢?本文將從四個(gè)方面對(duì)這個(gè)問(wèn)題展開(kāi)分析,希望對(duì)你有幫助。
現(xiàn)在生活已經(jīng)離不開(kāi)微信/支付寶電子支付,平常出去吃飯、購(gòu)物只要帶個(gè)手機(jī),就可以解決一切,以致于現(xiàn)在已經(jīng)好久沒(méi)摸過(guò)真?了。有一次出去吃飯,排著隊(duì)付錢(qián),等著過(guò)程非常無(wú)聊,準(zhǔn)備拔出手機(jī)來(lái)把荒野亂斗,卻發(fā)現(xiàn)這個(gè)地方竟然連不上網(wǎng)。
看著手機(jī)明明信號(hào)滿格,但是就是顯示網(wǎng)絡(luò)無(wú)連接,蘋(píng)果手機(jī)用戶痛,誰(shuí)用誰(shuí)知道。
由于沒(méi)有網(wǎng)絡(luò),而我又沒(méi)帶錢(qián),所以就怕付錢(qián)的時(shí)候因?yàn)槭謾C(jī)沒(méi)網(wǎng),沒(méi)辦法使用支付寶扣款。正想著時(shí),已經(jīng)排到了我,不管三七二十一,先用下支付寶試試,實(shí)在不行就不吃了。
不過(guò)沒(méi)想到,當(dāng)商家用掃碼搶掃描支付寶上付款碼支付以后,雖然我的手機(jī)最終沒(méi)有彈出支付成功的頁(yè)面,但是商家端顯示支付成功,并成功打印出了小票,過(guò)了一會(huì),我的手機(jī)收到支付寶扣款短信。
因?yàn)槲易罱墓ぷ鲗?duì)都是與微信/支付寶有關(guān),整體支付流程還是比較清楚,但是付款碼為什么能離線支付確實(shí)不是很清楚,所以研究了一番,于是有了今天的文章。
一、科普支付方式
在聊付款碼離線原理之前,我們先給不熟悉支付寶/微信支付方式同學(xué)先科普一下常見(jiàn)的兩種支付方式。
微信、支付寶線下支付常用支付方式有兩種,一種是我們打開(kāi)手機(jī),主動(dòng)掃描商家提供碼牌,這種支付方式一般稱(chēng)為主掃支付(用戶主動(dòng)掃碼)。
以支付寶為例,付款流程如圖所示:
圖片來(lái)自支付寶官網(wǎng)
第二種則是我們打開(kāi)手機(jī),展示我們的付款碼,然后商家使用掃碼槍等工具獲取付款碼完成支付,這種支付方式一般稱(chēng)為被掃支付(用戶被掃碼)。
以支付寶為例,付款流程如圖所示:
圖片來(lái)自支付寶官網(wǎng)
對(duì)于第一種方式,需要手機(jī)端 APP 掃碼,然后彈窗確認(rèn)付款,這種方式是沒(méi)有辦法在手機(jī)沒(méi)有網(wǎng)絡(luò)的情況完成支付,所以我們上文說(shuō)的沒(méi)有網(wǎng)絡(luò)的情況特指付款碼支付的場(chǎng)景。
二、付款碼付款流程
在聊付款碼離線支付的前提前,我們先來(lái)來(lái)看下付款碼的整體流程,以超市購(gòu)物為例,一次付款碼的支付信息流如圖所示:
參考知乎@天順
這個(gè)過(guò)程商家后臺(tái)系統(tǒng)是需要調(diào)用的支付寶條碼支付的接口,完成支付。
「由于商家后臺(tái)需要在線聯(lián)網(wǎng)與支付寶后臺(tái)通訊,所以說(shuō)付款碼的離線支付,指的是客戶端沒(méi)有的網(wǎng)絡(luò)的情況,商家端其實(shí)必須實(shí)時(shí)聯(lián)網(wǎng)在線?!?/p>
一次付款碼接口調(diào)用流程如圖所示:
來(lái)自支付寶官網(wǎng)
通過(guò)上面兩張圖,我們整體了解付款碼交互流程。
付款碼的技術(shù)方案其實(shí)可以分為客戶端在線與離線的兩種情況,下面我們來(lái)看下兩種方案具體實(shí)現(xiàn)方式。
三、在線碼方案
客戶端在線碼的方案,這個(gè)應(yīng)該比較容易想到,只要支付寶/微信在登錄的情況下,點(diǎn)擊付款按鈕,客戶端調(diào)用后臺(tái)系統(tǒng)的申請(qǐng)付款碼接口。
后臺(tái)系統(tǒng)受到請(qǐng)求之后,生成一個(gè)付款碼,然后在數(shù)據(jù)庫(kù)保存付款碼與用戶的關(guān)系,并且返回給客戶端。
只要客戶端在有效期內(nèi)展示該付款碼,就可以完成支付,否則該二維碼就將會(huì)過(guò)期。
使用這種方案,相對(duì)來(lái)說(shuō)比較安全,因?yàn)槊看味际欠?wù)端生成碼,服務(wù)端可以控制冪等,沒(méi)有客戶端偽造的風(fēng)險(xiǎn)的。
另外即使需要對(duì)付款碼規(guī)則調(diào)整,比如付款碼位數(shù)增加一位,我們只要調(diào)整服務(wù)端代碼即可,客戶端都無(wú)需升級(jí)。
「不過(guò)這種方案缺點(diǎn)也比較明顯,客戶端必須實(shí)時(shí)在線聯(lián)網(wǎng),沒(méi)有網(wǎng)絡(luò)則無(wú)法獲取付款碼。」
另外,現(xiàn)在有一些智能設(shè)備也開(kāi)始支持支付寶支付,這些設(shè)備中很大一部分是沒(méi)有聯(lián)網(wǎng)的功能(比如小米手環(huán)四),那這種情況是沒(méi)辦法使用在線碼方案。
基于這種情況,所以開(kāi)始有了離線碼方案。
四、離線碼方案
說(shuō)起離線碼大家可能比較陌生,但是實(shí)際上你如果仔細(xì)觀察,其實(shí)很多場(chǎng)景都用到了離線碼。
比如說(shuō)以前去黑網(wǎng)吧玩夢(mèng)幻西游的時(shí)候,賬號(hào)總是被盜。
沒(méi)辦法,花了一筆重資買(mǎi)了一個(gè)網(wǎng)易將軍令,每次登錄的時(shí)候,除了輸入用戶名與密碼以外,還需要輸入動(dòng)態(tài)口令。從此賬號(hào)就很少被盜了。
又比如說(shuō)每次網(wǎng)易支付的時(shí)候,我們除了輸入銀行卡密碼以外,還需要輸入網(wǎng)銀盾上動(dòng)態(tài)碼,這樣才能完成支付。
畫(huà)外音:這里又要吐槽一下,網(wǎng)銀盾以前真的超難用,動(dòng)不動(dòng)就驅(qū)動(dòng)不兼容。還記得當(dāng)初用網(wǎng)銀充值黃鉆,搞了一下午都沒(méi)有成功!
當(dāng)然上面這些可能已經(jīng)是老古董了,很多人都可能沒(méi)用過(guò),現(xiàn)在比較流行是「手機(jī)驗(yàn)證器APP」,比如 「Google Authenticator」 等。
這種令牌器,動(dòng)態(tài)產(chǎn)生一次性口令(「OTP, One-time Password」),可以防止密碼被盜用引發(fā)的安全風(fēng)險(xiǎn)。
其實(shí)付款碼離線方案技術(shù)原型就是基于這種方案,所以下面我們就基于 Google Authenticator,來(lái)了解一下這其中的原理。
1. 動(dòng)態(tài)口令技術(shù)原理
首先如果我們需要使用 「Google Authenticator」,我們需要在網(wǎng)站上開(kāi)啟二次驗(yàn)證功能,以 Google 賬號(hào)為例,在設(shè)置兩步驗(yàn)證的地方可以找到如下設(shè)置:
當(dāng)我們點(diǎn)擊設(shè)置,將會(huì)彈出一個(gè)二維碼,然后使用 「Google Authenticator」 APP 掃碼綁定。
當(dāng)我們綁定之后, 「Google Authenticator」 APP 將會(huì)展示動(dòng)態(tài)碼。
我們來(lái)解析一下這個(gè)二維碼,對(duì)應(yīng)下面這個(gè)字符串:
otpauth://totp/Google%3Ayourname@gmail.com?secret=xxxx&issuer=Google
上面的字符串中,最重要就是這一串密鑰 secret,這個(gè)是一個(gè)經(jīng)過(guò) 「BASE32」 編碼之后的字符串,真正使用時(shí)需要將其使用「BASE32」 解碼,處理偽碼如下:
original_secret=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxsecret=BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret)))
「這個(gè)密鑰客戶端與服務(wù)端將會(huì)同時(shí)保存一份,兩端將會(huì)同樣的算法計(jì)算,以此用來(lái)比較動(dòng)態(tài)碼的正確性。」
我們以客戶端為例,生成一個(gè)動(dòng)態(tài)碼,首先我們需要經(jīng)過(guò)一個(gè)簽名函數(shù),這里 **Google Authenticator **采用的 「HMAC-SHA1」,這是一種基于哈希的消息驗(yàn)證碼,可以用比較安全的單向哈希函數(shù)(如 SHA1)來(lái)產(chǎn)生簽名。
簽名函數(shù)偽碼如下:
hmac=SHA1(secret+SHA1(secret+input))
上面函數(shù)中的,input 使用當(dāng)前時(shí)間整除 30 的值。
input=CURRENT_UNIX_TIME()/30
這里時(shí)間就充當(dāng)一個(gè)動(dòng)態(tài)變參,這樣可以源源不斷產(chǎn)生動(dòng)態(tài)碼。
「另外這里整除 30,是為了賦予驗(yàn)證碼一個(gè) 30 秒的有效期?!?/p>
這樣對(duì)于用戶輸入來(lái)講,可以有充足時(shí)間準(zhǔn)備輸入這個(gè)動(dòng)態(tài)碼,另外一點(diǎn)客戶端與服務(wù)端可能存在時(shí)間偏差,30 秒的間隔可以很大概率的屏蔽這種差異。
畫(huà)外音:這個(gè)有效時(shí)間其實(shí)很考量,如果比較長(zhǎng),安全性就差。
如果比較短,用戶體驗(yàn)就很差,不容易輸入準(zhǔn)備。
經(jīng)過(guò) 「HMAC-SHA1」 簽名函數(shù)以后,我們得到一個(gè)長(zhǎng)度為 40 的字符串,我們還需要將其轉(zhuǎn)化為 6 位數(shù)字,方便用戶輸入。處理的偽碼如下:
four_bytes=hmac[LAST_BYTE(hmac):LAST_BYTE(hmac)+4]large_integer=INT(four_bytes)small_integer=large_integer%1,000,000
完整的算法偽碼如下:
original_secret=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxsecret=BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret)))input=CURRENT_UNIX_TIME()/30hmac=SHA1(secret+SHA1(secret+input))four_bytes=hmac[LAST_BYTE(hmac):LAST_BYTE(hmac)+4]large_integer=INT(four_bytes)small_integer=large_integer%1,000,000
當(dāng)客戶端將動(dòng)態(tài)碼上傳給服務(wù)端,服務(wù)端查詢數(shù)據(jù)庫(kù)獲取到用戶對(duì)應(yīng)的密鑰,然后使用同樣的算法進(jìn)行處理生成一個(gè)動(dòng)態(tài)碼,最后比較客戶端上傳動(dòng)態(tài)碼與服務(wù)端生成是否一致。
2. 付款碼離線方案
上面我們了解了動(dòng)態(tài)口令的實(shí)現(xiàn)方案,付款碼生成原理其實(shí)也大致如此。
不過(guò)付款碼離線方案采用動(dòng)態(tài)密鑰的方式(「全局唯一」),定時(shí)請(qǐng)求服務(wù)端更換密鑰,以此保證更高的安全性。
另外在一次性動(dòng)態(tài)口令方案,需要雙方基于同樣的秘鑰,所以服務(wù)端需要明確知道這「背后正確用戶」。以上面的登錄場(chǎng)景為例,登錄過(guò)程輸入用戶名,服務(wù)端就可以根據(jù)這個(gè)在數(shù)據(jù)庫(kù)中查詢相應(yīng)的密鑰。
但是在付款碼的支付場(chǎng)景中,支付過(guò)程僅僅傳遞一個(gè)付款碼,就可以向相應(yīng)的用戶扣款。不用想,這個(gè)付款碼這串?dāng)?shù)字一定包含相應(yīng)的用戶信息。
所以付款碼的相應(yīng)的算法相比動(dòng)態(tài)碼會(huì)更加復(fù)雜,這樣才可以有效保證安全性。
看到這里,不知道你們是否急切想了解這套算法那?
這種算法豈能是我們能掌握的?
支付寶核心算法咱不知道,但是我們可以從其他人公開(kāi)設(shè)計(jì)方案了解一個(gè)皮毛。
這里小黑哥給你一個(gè)知乎網(wǎng)友@反方向的鐘回答的離線二維碼實(shí)現(xiàn)方式,給你 look look。
來(lái)自:https://www.zhihu.com/que
stion/49811134/answer/135886638
3. 付款碼離線碼的劣勢(shì)
最后我們來(lái)看下付款碼離線方案的劣勢(shì):
第一,算法調(diào)整不靈活,如果相關(guān)算法較大的調(diào)整,可能需要升級(jí)客戶端,并且這個(gè)期間服務(wù)端還需要兼容新老算法產(chǎn)生的付款碼。
第二,安全性問(wèn)題,正常的情況相關(guān)密鑰無(wú)法被普通用戶獲取,但是架不住有有心之人。他們可能通過(guò)獲取手機(jī)用戶 Root 權(quán)限或者越獄手機(jī),利用惡意程序獲取密鑰,然后隨意生成付款碼。
看到這一點(diǎn),大家可能會(huì)擔(dān)心自己的錢(qián)包安全了。不過(guò)這一點(diǎn),我覺(jué)得不過(guò)過(guò)分擔(dān)心,螞蟻集團(tuán)這么多大神,不是吃干飯的,他們肯定有很多措施保證支付安全。
第三數(shù)據(jù)碰撞問(wèn)題,A 用戶生成付款碼算出來(lái)與 B 用戶一致,這就 Hash 算法一樣,再怎么優(yōu)秀的算法,也有概率才生一樣的額 Hash 值。
這就導(dǎo)致原本是扣用戶 A 的錢(qián),最后卻扣了 B 用戶。這樣一來(lái),確實(shí)很烏龍,對(duì)于 B 用戶來(lái)講,莫名其妙被扣錢(qián)了。
不過(guò)放心,這種事放到放到現(xiàn)在,我覺(jué)得還是比買(mǎi)彩票中獎(jiǎng)低,所以這種事還是不用過(guò)分擔(dān)心了。
即使真被誤扣了,放心,支付寶這么大體量肯定會(huì)跟客戶賠錢(qián)的。
五、最后
最后總結(jié)一下,我們平常使用付款碼支付,其實(shí)原理就是商家端獲取我們手機(jī) APP 付款碼(「其實(shí)就是一串?dāng)?shù)字」),然后后臺(tái)調(diào)用支付寶支付接口完成扣款。
這個(gè)流程商家端后臺(tái)程序必須聯(lián)網(wǎng)在線,但是對(duì)于我們客戶端來(lái)講可以在線,也可以離線。
如果我們客戶端在線,那就可以通過(guò)服務(wù)端向客戶端發(fā)送付款碼,這種方式更加安全,靈活,但是對(duì)于弱網(wǎng)環(huán)境下,體驗(yàn)就很差。
如果我們客戶端沒(méi)網(wǎng),那就通過(guò)客戶端通過(guò)一定算法生成付款碼,服務(wù)端收到經(jīng)過(guò)相關(guān)校驗(yàn),確認(rèn)是哪個(gè)用戶,確認(rèn)碼有效性,并且完成扣款。這種方式,適合客戶端沒(méi)有網(wǎng)絡(luò)的情況,不過(guò)相對(duì)不靈活,且安全性稍差。
嘿嘿,了解原理,有沒(méi)有覺(jué)得還是挺有意思的~
下次排隊(duì)付款錢(qián),如果手機(jī)沒(méi)網(wǎng),不要擔(dān)心尷尬,放心拿出手機(jī)付錢(qián)~
對(duì)了,看完記得一鍵三連,這個(gè)對(duì)我真的很重要。
六、參考
- https://www.zhihu.com/question/49811134/answer/135886638
- https://garbagecollected.org/2014/09/14/how-google-authenticator-works/
作者:樓下小黑哥;微信公號(hào)@程序通事,支付行業(yè),后端技術(shù)
本文由 @樓下小黑哥 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來(lái)自Pexels,基于CC0協(xié)議
如果手機(jī)長(zhǎng)時(shí)間處于無(wú)網(wǎng)狀態(tài),收不到密鑰,是不是離線支付也沒(méi)用了
從收款場(chǎng)景處理離線支付其實(shí)很崩潰,去年做的時(shí)候支付寶的離線支付并不給系統(tǒng)實(shí)時(shí)返回支付成功,導(dǎo)致大量主動(dòng)查詢補(bǔ)通知,甚至對(duì)未支付的支付寶訂單多次輪詢,非常占資源
為什么離線支付沒(méi)有實(shí)時(shí)返回通知呢?
團(tuán)隊(duì)
講得好!
認(rèn)同