加密的藝術：密文的創建和校驗

概述

在我很喜歡的一部（根據真實事件改編）的電影《模仿遊戲》裏面：

著名的科學家圖靈帶領他的團隊，花費兩年的時間，費勁九牛二虎之力，在找到德軍的話術口令後才得以破解了德軍通訊加密裝置 “英格瑪”，爲第二次世界大戰取得勝利打下的堅實的基礎。那麼德軍使用的通訊加密究竟是一種怎樣的技術，這是我們今天要探討的數據加密技術。數據的保密是對數據加密、解密的統稱，用學院派的說法就是，使用某種算法改變了信息原本的形態，使攻擊者即使竊取了信息也因爲沒有對應的解密的方法也無法獲取當信息的真實內容。這就是信息保密的目的，對於信息的保密，可以在三個環節進行，分別是：

在客戶端進行保密
在傳輸時進行保密（最複雜，也最有效）
在服務端進行保密

加密的強度

在安全領域大家都知道安全是區分等級的，不同應用的敏感信息重要性不同，所以需要的安全等級也不同，這個世界上沒有絕對的安全，安全等級不可能無止境的拉滿，任何安全手段都可以破解（只要花費足夠的成本），想要更高級別的安全等級，就要付出更高的成本（工作量，算力）等。例如常見的加密技術可以說明這一點。加密的強度從低到高，分別有：

一：哈希算法：最常見的加密手段，對明文密碼使用 MD5 等哈希摘要算法進行不可逆的哈希計算進行加密，示例：

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;

public class MD5Hash {
    public static void main(String[] args) {
        String text = "yourPassword";
        try {
            MessageDigest md = MessageDigest.getInstance("MD5");
            byte[] hashBytes = md.digest(text.getBytes());
            StringBuilder hexString = new StringBuilder();
            for (byte b : hashBytes) {
                hexString.append(String.format("%02x", b));
            }
            System.out.println("MD5 Digest: " + hexString.toString());
        } catch (NoSuchAlgorithmException e) {
            e.printStackTrace();
        }
    }
}

輸出結果：

MD5 Digest: 65a8e27d8879283831b664bd8b7f0ad4

這種方式，安全等級低，弱密碼容易被彩虹表（預先進行摘要好的哈希表，進行反向破譯）破擊。

二：哈希算法加鹽：增強了基礎的哈希算法，加上 salt 鹽值混淆哈希計算，可以有效防禦彩虹表的攻擊，示例：

private static final String SALT = "YourFixedSalt";  // 固定鹽值

private static String getSecurePassword(String passwordToHash) {
    String generatedPassword = null;
    try {
        MessageDigest md = MessageDigest.getInstance("MD5");
        // 添加固定鹽值
        md.update(SALT.getBytes());
        byte[] bytes = md.digest(passwordToHash.getBytes());
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < bytes.length; i++) {
            sb.append(Integer.toString((bytes[i] & 0xff) + 0x100, 16).substring(1));
        }
        generatedPassword = sb.toString();
    } catch (NoSuchAlgorithmException e) {
        e.printStackTrace();
    }
    return generatedPassword;
}

這種方案的缺點是，但如果鹽值泄露，那麼破譯所以密文也是一件很容易得事情，而且弱密碼即使加了鹽值，在強大算力的彩虹表面前，破譯也不是一件難事。

三：動態鹽加哈希：動態鹽值有一個特點，就是每個鹽值只使用一次，這種方式有點像就像我喜歡喫的那家酸菜魚，他們家宣傳的口號就是：油每次只用一次，本質上就是花費更高的成本換來更高的安全。示例：

public static void main(String[] args) {
    // 待加密的密碼
    String passwordToHash = "yourPassword";
    // 生成動態鹽值
    byte[] salt = getSalt();
    // 獲取帶鹽的安全密碼
    String securePassword = getSecurePassword(passwordToHash, salt);
    System.out.println("Secure Password: " + securePassword);
    System.out.println("Salt: " + bytesToHex(salt));
}

// 使用MD5加密密碼，並結合鹽值
private static String getSecurePassword(String passwordToHash, byte[] salt) {
    try {
        // 創建MD5摘要算法的 MessageDigest 對象
        MessageDigest md = MessageDigest.getInstance("MD5");
        // 將鹽值添加到摘要中
        md.update(salt);
        // 完成密碼的哈希計算
        byte[] hashedBytes = md.digest(passwordToHash.getBytes());
        // 將哈希值轉換爲十六進制字符串
        return bytesToHex(hashedBytes);
    } catch (NoSuchAlgorithmException e) {
        e.printStackTrace();
        return null;
    }
}

// 生成一個隨機的鹽值
private static byte[] getSalt() {
    SecureRandom sr = new SecureRandom();
    byte[] salt = new byte[16];
    sr.nextBytes(salt);
    return salt;
}

// 將字節數組轉換爲十六進制字符串
private static String bytesToHex(byte[] bytes) {
    StringBuilder sb = new StringBuilder();
    for (byte b : bytes) {
        sb.append(String.format("%02x", b));
    }
    return sb.toString();
}

動態鹽值可以解決固定鹽值帶來的風險，如果由客戶端動態生成鹽值給服務端進行計算，那麼 客戶端如果安全的把動態鹽值傳輸給服務端 就是另外一個問題，既然通信的信道是安全可靠的，那麼傳輸動態鹽值就沒有意義，既然通信信道是不安全的，那麼傳輸動態鹽值也有被竊聽的風險，也沒有意義。這簡直就是一個 “先有雞，還是先有蛋” 的問題。

四：啓動 HTTPS 信道：HTTPS 加密傳輸是目前的主流方案，但是啓動 HTTPS 後安全信道後也並不能高枕無憂，也會帶來一系列的問題，例如因爲會遇到服務端使用自簽名證書導致信息泄露風險，服務端證書更新不及時，證書過期的問題，還有 TLS 版本過低或密碼學套件選用不當產生加密強度不足的風險。

五：外置的 MFA：例如銀行等機構在涉及金額交易的時候，會要求客戶使用外置的 U 盾，虛擬 MFA，手機驗證碼，人臉識別等外置設備來加強安全等級。一些關鍵企業或者軍事機構甚至會開闢一條與公網隔絕的獨立的內部網絡進行信息通信來保證信息的安全。

通過以上示例是想要證明，對於安全和保密而言：這個世界上是沒有絕對的安全，想要更高級別的安全等級，就要付出更高的成本 ，當然有人會挑刺的說，那我拔掉網線不聯網最安全，雖然有一定的合理性，但這樣封閉式的安全沒有意義，所以不在我們討論的範圍之內。

客戶端加密

對於大多數應用而言，要保證信息通信的安全，客戶端只有啓用 HTTPS 這一個方案可以選擇。而且對於密碼這樣的敏感信息而言，個人認爲最好是在客戶端就可以儘快處理掉，以絕後患，原因如下：

服務端存儲明文密碼，數據庫被攻破導致用戶密碼泄露的新聞已經屢見不鮮的，而且被拖庫最嚴重的還是國內某最大的技術社區。。。
服務端把密碼輸入到日誌，日誌文件泄露或者被採集，導致用戶密碼泄露等等
避免中間人攻擊，就算網絡設備被劫持，信息被竊取，至少明文密碼不會泄露

總之，明文密碼最好在客戶端就被消滅掉，越早處理越好，不要把明文傳到服務端，傳輸的風險大，在防禦上客戶端除了啓用 HTTPS 外，還要對明文密碼進行摘要處理，從而保證敏感的安全。至於客戶端應該如何進行加密，我們接下來開始討論。

密文的創建和校驗

之前說了在信息安全領域沒有絕對的安全，需要多高的安全等級就要消耗多大的安全成本。對於大多數普遍的應用而言，啓動 HTTPS 加密通信是在安全等級和安全成本之間的一個合適的平衡點。所以結合實際情況選擇合適的方案就好。

BCrypt 算法

上面介紹無論如何對明文進行哈希計算，就算加鹽都有被彩虹表暴力破解的可能。爲了解決這個問題，引入慢哈希函數來解決可能是一個更理想的方案。慢哈希，就是在哈希計算和 salt 鹽值之外增加一個計算時間 cost 的參數，慢哈希通過延長哈希計算時間和消耗的資源來有效的避免諸如彩虹表等暴力破解的攻擊，提供系統的安全性，BCrypt 算法就是一個具有代表性的慢哈希函數。示例：

public class BCryptExample {

    public static void main(String[] args) {
        // 創建 BCryptPasswordEncoder 實例，可以指定工作因子，默認是 10
        BCryptPasswordEncoder encoder = new BCryptPasswordEncoder();

        // 加密密碼
        String originalPassword = "yourPassword";
        String encodedPassword = encoder.encode(originalPassword);
        System.out.println("Encoded Password: " + encodedPassword);

        // 校驗密碼
        boolean isMatch = encoder.matches(originalPassword, encodedPassword);
        System.out.println("Password matched: " + isMatch);
    }
}

如果我們把慢哈希計算的 cost 設置爲 0.1 秒的時間，那麼對所有由10位大小寫字母和數字組成的弱密碼（共62種字符）進行哈希計算一次，大約需要 8.39×10168.39×1016 秒。這等於大約 971.4 億天，或者大約 2661 百萬年的時間。這表明使用 BCrypt 和適當的工作因子可以極大增加破解密碼的難度，使得暴力破解方法變得不可行。但是需要注意的是：

BCrypt 存在對計算資源和時間有很大的消耗，會明顯降低服務端性能，只建議在客戶端進行慢哈希處理

密文的創建

對於敏感信息加密階段，可以參考以下方案進行處理：

用戶創建密碼，客戶端接收用戶的明文密碼
客戶端對密碼使用固定鹽值 + BCrypt 慢哈希進行加密後發給服務端
服務端接收密文，然後生成隨機鹽值，對密文進行二次加密
服務端將隨機鹽和二次密文存儲到數據庫

密文的校驗

在對密文進行校驗階段，可以參考以下方案進行處理：

說明：

用戶輸入密碼，客戶端收到用戶的明文密碼
客戶端對密碼使用固定鹽值 + BCrypt 慢哈希進行加密後發給服務端
服務端接收客戶端密文，然後從數據庫取出隨機鹽和二次密文
服務端使用隨機鹽對客戶端密文進行加密，然後和自身的二次密文進行對比
密文內容相同，則表示密碼校驗通過

加密的藝術：密文的創建和校驗

概述

加密的強度

客戶端加密

密文的創建和校驗

BCrypt 算法

密文的創建

密文的校驗

ziw2pdf

apisix~helm方式的部署到k8s

firmeye - IoT固件漏洞挖掘工具

HTTPS 是如何進行安全傳輸的？

加密的藝術：密文的創建和校驗

憑證管理揭祕：Cookie-Session 與 JWT 方案的對決

4A 安全之授權：編程的門禁，你能解開嗎？

身份認證的盡頭竟然是無密碼？

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結