加密的手機號，如何模糊查詢？

作者：蘇三呀 2023-10-12 08:22:21

移動開發移動應用

雖說本文介紹了多種加密手機號實現模糊查詢功能的方案，但我們要根據實際業務場景來選擇，沒有最好的方案，只有最合適的。

前言

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

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

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

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

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

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

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

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

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

比如：假設查詢蘇三關鍵字，加密后的字符串是：U2FsdGVkX19eCv+xt2WkQb5auYo0ckyw。

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

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

1 一次加載到內存

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

圖片

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

但帶來的問題是：如果個人隱私數據非常多的話，應用服務器的內存不一定夠用，可能會出現OOM問題。

還有另外一個問題是：數據一致性問題。

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

比如：數據庫更新成功了，內存中的緩存更新失敗了。

或者你的應用，部署了多個服務器節點，有一部分內存緩存更新成功了，另外一部分剛好在重啟，導致更新失敗了。

該方案不僅可能會導致應用服務器出現OOM問題，也可能會導致系統的復雜度提升許多，總體來說，有點得不償失。

2 使用數據庫函數

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

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

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

應用系統重所有的用戶隱私信息的加解密都在MySQL層實現，不存在加解密不一致的情況。

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

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

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

3 分段保存

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

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

然后建一張表：

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

這張表有三個字段：

id：系統編號。
ref_id：主業務表的系統編號，比如用戶表的系統編號。
encrypt_value：拆分后的加密字符串。

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

如果要模糊查詢手機號，可以直接通過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語句查詢出來的手機號是加密的，在接口返回給前端之前，需要在代碼中統一做解密處理。

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

4 其他的模糊查詢

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

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

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

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

如果業務表中的數據量少，這套方案是可以滿足需求的。

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

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

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

5 增加模糊查詢字段

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

那么，該如何優化呢？

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

還是以手機模糊查詢為例。

我們可以在用戶表中，在手機號旁邊，增加一個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='用戶表'

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

還是以手機號為例：

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

分組之后，加密之后，用逗號分割之后拼接成這樣的數據：,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。

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

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

當然你也可以根據實際情況，將逗號改成其他的特殊字符。

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

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

責任編輯：武曉燕來源：蘇三說技術

加密手機模糊查詢