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