前言

前幾天，知識星球中有位小伙伴，問了我一個問題：加密的手機號如何模糊查詢？

我們都知道，在做系統(tǒng)設(shè)計時，考慮到系統(tǒng)的安全性，需要對用戶的一些個人隱私信息，比如：登錄密碼、身份證號、銀行卡號、手機號等，做加密處理，防止用戶的個人信息被泄露。

很早之前，CSDN遭遇了SQL注入，導(dǎo)致了600多萬條明文保存的用戶信息被泄。

因此，我們在做系統(tǒng)設(shè)計的時候，要考慮要把用戶的隱私信息加密保存。

常見的對稱加密算法有 AES、SM4、ChaCha20、3DES、DES、Blowfish、IDEA、RC5、RC6、Camellia等。

目前國際主流的對稱加密算法是AES，國內(nèi)主推的則是SM4。

無論是用哪種算法，加密前的字符串，和加密后的字符串，差別還是比較大的。

比如加密前的字符串：蘇三說技術(shù)，使用密鑰：123，生成加密后的字符串為：U2FsdGVkX1+q7g9npbydGL1HXzaZZ6uYYtXyug83jHA=。

如何對加密后的字符串做模糊查詢呢？

比如：假設(shè)查詢蘇三關(guān)鍵字，加密后的字符串是：U2FsdGVkX19eCv+xt2WkQb5auYo0ckyw。

上面生成的兩個加密字符串差異看起來比較大，根本沒辦法直接通過SQL語句中的like關(guān)鍵字模糊查詢。

那我們該怎么實現(xiàn)加密的手機號的模糊查詢功能呢？

1 一次加載到內(nèi)存

實現(xiàn)這個功能，我們第一個想到的辦法可能是：把個人隱私數(shù)據(jù)一次性加載到內(nèi)存中緩存起來，然后在內(nèi)存中先解密，然后在代碼中實現(xiàn)模糊搜索的功能。

圖片

這樣做的好處是：實現(xiàn)起來比較簡單，成本非常低。

但帶來的問題是：如果個人隱私數(shù)據(jù)非常多的話，應(yīng)用服務(wù)器的內(nèi)存不一定夠用，可能會出現(xiàn)OOM問題。

還有另外一個問題是：數(shù)據(jù)一致性問題。

如果用戶修改了手機號，數(shù)據(jù)庫更新成功了，需要同步更新內(nèi)存中的緩存，否則用戶查詢的結(jié)果可能會跟實際情況不一致。

比如：數(shù)據(jù)庫更新成功了，內(nèi)存中的緩存更新失敗了。

或者你的應(yīng)用，部署了多個服務(wù)器節(jié)點，有一部分內(nèi)存緩存更新成功了，另外一部分剛好在重啟，導(dǎo)致更新失敗了。

該方案不僅可能會導(dǎo)致應(yīng)用服務(wù)器出現(xiàn)OOM問題，也可能會導(dǎo)致系統(tǒng)的復(fù)雜度提升許多，總體來說，有點得不償失。

2 使用數(shù)據(jù)庫函數(shù)

既然數(shù)據(jù)庫中保存的是加密后的字符串，還有一種方案是使用數(shù)據(jù)庫的函數(shù)解密。

我們可以使用MySQL的DES_ENCRYPT函數(shù)加密，使用DES_DECRYPT函數(shù)解密：

SELECT 
DES_DECRYPT('U2FsdGVkX1+q7g9npbydGL1HXzaZZ6uYYtXyug83jHA=', '123');

應(yīng)用系統(tǒng)重所有的用戶隱私信息的加解密都在MySQL層實現(xiàn)，不存在加解密不一致的情況。

該方案中保存數(shù)據(jù)時，只對單個用戶的數(shù)據(jù)進行操作，數(shù)據(jù)量比較小，性能還好。

但模糊查詢數(shù)據(jù)時，每一次都需要通過DES_DECRYPT函數(shù)，把數(shù)據(jù)庫中用戶某個隱私信息字段的所有數(shù)據(jù)都解密了，然后再通過解密后的數(shù)據(jù)，做模糊查詢。

如果該字段的數(shù)據(jù)量非常大，這樣每次查詢的性能會非常差。

3 分段保存

我們可以將一個完整的字符串，拆分成多個小的字符串。

以手機號為例：18200256007，按每3位為一組，進行拆分，拆分后的字符串為：182,820,200,002,025,256,560,600,007，這9組數(shù)據(jù)。

然后建一張表：

CREATE TABLE `encrypt_value_mapping` (
  `id` bigint NOT NULL COMMENT '系統(tǒng)編號',
  `ref_id` bigint NOT NULL COMMENT '關(guān)聯(lián)系統(tǒng)編號',
  `encrypt_value` varchar(255) NOT NULL COMMENT '加密后的字符串'
) ENGINE=InnoDB  CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='分段加密映射表'

這張表有三個字段：

• id：系統(tǒng)編號。
• ref_id：主業(yè)務(wù)表的系統(tǒng)編號，比如用戶表的系統(tǒng)編號。
• encrypt_value：拆分后的加密字符串。

用戶在寫入手機號的時候，同步把拆分之后的手機號分組數(shù)據(jù)，也一起寫入，可以保證在同一個事務(wù)當(dāng)中，保證數(shù)據(jù)的一致性。

如果要模糊查詢手機號，可以直接通過encrypt_value_mapping的encrypt_value模糊查詢出用戶表的ref_id，再通過ref_id查詢用戶信息。

具體sql如下：

select s2.id,s2.name,s2.phone 
from encrypt_value_mapping s1
inner join `user` s2 on s1.ref_id=s2.id
where s1.encrypt_value = 'U2FsdGVkX19Se8cEpSLVGTkLw/yiNhcB'
limit 0,20;

這樣就能輕松的通過模糊查詢，搜索出我們想要的手機號了。

注意這里的encrypt_value用的等于號，由于是等值查詢，效率比較高。

注意：這里通過sql語句查詢出來的手機號是加密的，在接口返回給前端之前，需要在代碼中統(tǒng)一做解密處理。

為了安全性，還可以將加密后的明文密碼，用*號增加一些干擾項，防止手機號被泄露，最后展示給用戶的內(nèi)容，可以顯示成這樣的：182***07。

4 其他的模糊查詢

如果除了用戶手機號，還有其他的用戶隱私字段需要模糊查詢的場景，該怎么辦？

我們可以將encrypt_value_mapping表擴展一下，增加一個type字段。

該字段表示數(shù)據(jù)的類型，比如：1.手機號 2.身份證 3.銀行卡號等。

這樣如果有身份證和銀行卡號模塊查詢的業(yè)務(wù)場景，我們可以通過type字段做區(qū)分，也可以使用這套方案，將數(shù)據(jù)寫入到encrypt_value_mapping表，最后根據(jù)不同的type查詢出不同的分組數(shù)據(jù)。

如果業(yè)務(wù)表中的數(shù)據(jù)量少，這套方案是可以滿足需求的。

但如果業(yè)務(wù)表中的數(shù)據(jù)量很大，一個手機號就需要保存9條數(shù)據(jù)，一個身份證或者銀行卡號也需要保存很多條數(shù)據(jù)，這樣會導(dǎo)致encrypt_value_mapping表的數(shù)據(jù)急劇增加，可能會導(dǎo)致這張表非常大。

最后的后果是非常影響查詢性能。

那么，這種情況該怎么辦呢？

5 增加模糊查詢字段

如果數(shù)據(jù)量多的情況下，將所有用戶隱私信息字段，分組之后，都集中到一張表中，確實非常影響查詢的性能。

那么，該如何優(yōu)化呢？

答：我們可以增加模糊查詢字段。

還是以手機模糊查詢?yōu)槔?/p>

我們可以在用戶表中，在手機號旁邊，增加一個encrypt_phone字段。

CREATE TABLE `user` (
  `id` int NOT NULL,
  `code` varchar(20)  NOT NULL,
  `age` int NOT NULL DEFAULT '0',
  `name` varchar(30) NOT NULL,
  `height` int NOT NULL DEFAULT '0',
  `address` varchar(30)  DEFAULT NULL,
  `phone` varchar(11) DEFAULT NULL,
  `encrypt_phone` varchar(255)  DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='用戶表'

然后我們在保存數(shù)據(jù)的時候，將分組之后的數(shù)據(jù)拼接起來。

還是以手機號為例：

18200256007，按每3位為一組，進行拆分，拆分后的字符串為：182,820,200,002,025,256,560,600,007，這9組數(shù)據(jù)。

分組之后，加密之后，用逗號分割之后拼接成這樣的數(shù)據(jù)：,U2FsdGVkX19Se8cEpSLVGTkLw/yiNhcB,U2FsdGVkX1+qysCDyVMm/aYXMRpCEmBD,U2FsdGVkX19oXuv8m4ZAjz+AGhfXlsQk,U2FsdGVkX19VFs60R26BLFzv5nDZX40U,U2FsdGVkX19XPO0by9pVw4GKnGI3Z5Zs,U2FsdGVkX1/FIIaYpHlIlrngIYEnuwlM,U2FsdGVkX19s6WTtqngdAM9sgo5xKvld,U2FsdGVkX19PmLyjtuOpsMYKe2pmf+XW,U2FsdGVkX1+cJ/qussMgdPQq3WGdp16Q。

以后可以直接通過sql模糊查詢字段encrypt_phone了：

select id,name,phone
from user where encrypt_phone like '%U2FsdGVkX19Se8cEpSLVGTkLw/yiNhcB%'
limit 0,20;

注意這里的encrypt_value用的like。

這里為什么要用逗號分割呢？

答：是為了防止直接字符串拼接，在極端情況下，兩個分組的數(shù)據(jù)，原本都不滿足模糊搜索條件，但拼接在一起，卻有一部分滿足條件的情況發(fā)生。

當(dāng)然你也可以根據(jù)實際情況，將逗號改成其他的特殊字符。

此外，其他的用戶隱私字段，如果要實現(xiàn)模糊查詢功能，也可以使用類似的方案。

最后說一句，雖說本文介紹了多種加密手機號實現(xiàn)模糊查詢功能的方案，但我們要根據(jù)實際業(yè)務(wù)場景來選擇，沒有最好的方案，只有最合適的。