快捷導(dǎo)航

淺析java中密文的創(chuàng)建和校驗

更新時間：2024年04月28日 11:22:23 作者：衛(wèi)衛(wèi)講編程

這篇文章主要為大家詳細介紹了java中密文的創(chuàng)建和校驗的相關(guān)知識,文中的示例代碼講解詳細,感興趣的小伙伴可以跟隨小編一起學(xué)習(xí)一下

概述

在我很喜歡的一部（根據(jù)真實事件改編）的電影《模仿游戲》里面：

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

在客戶端進行保密
在傳輸時進行保密（最復(fù)雜，也最有效）
在服務(wù)端進行保密

加密的強度

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

一：哈希算法：最常見的加密手段，對明文密碼使用 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();
        }
    }
}

輸出結(jié)果：

MD5 Digest: 65a8e27d8879283831b664bd8b7f0ad4

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

二：哈希算法加鹽：增強了基礎(chǔ)的哈希算法，加上 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;
}

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

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

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

// 使用MD5加密密碼，并結(jié)合鹽值
private static String getSecurePassword(String passwordToHash, byte[] salt) {
    try {
        // 創(chuàng)建MD5摘要算法的 MessageDigest 對象
        MessageDigest md = MessageDigest.getInstance("MD5");
        // 將鹽值添加到摘要中
        md.update(salt);
        // 完成密碼的哈希計算
        byte[] hashedBytes = md.digest(passwordToHash.getBytes());
        // 將哈希值轉(zhuǎn)換為十六進制字符串
        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;
}

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

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

四：啟動 HTTPS 信道：HTTPS 加密傳輸是目前的主流方案，但是啟動 HTTPS 后安全信道后也并不能高枕無憂，也會帶來一系列的問題，例如因為會遇到服務(wù)端使用自簽名證書導(dǎo)致信息泄露風(fēng)險，服務(wù)端證書更新不及時，證書過期的問題，還有 TLS 版本過低或密碼學(xué)套件選用不當產(chǎn)生加密強度不足的風(fēng)險。

五：外置的 MFA：例如銀行等機構(gòu)在涉及金額交易的時候，會要求客戶使用外置的 U 盾，虛擬 MFA，手機驗證碼，人臉識別等外置設(shè)備來加強安全等級。一些關(guān)鍵企業(yè)或者軍事機構(gòu)甚至?xí)_辟一條與公網(wǎng)隔絕的獨立的內(nèi)部網(wǎng)絡(luò)進行信息通信來保證信息的安全。

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

客戶端加密

對于大多數(shù)應(yīng)用而言，要保證信息通信的安全，客戶端只有啟用 HTTPS 這一個方案可以選擇。而且對于密碼這樣的敏感信息而言，個人認為最好是在客戶端就可以盡快處理掉，以絕后患，原因如下：

服務(wù)端存儲明文密碼，數(shù)據(jù)庫被攻破導(dǎo)致用戶密碼泄露的新聞已經(jīng)屢見不鮮的，而且被拖庫最嚴重的還是國內(nèi)某最大的技術(shù)社區(qū)。。。
服務(wù)端把密碼輸入到日志，日志文件泄露或者被采集，導(dǎo)致用戶密碼泄露等等
避免中間人攻擊，就算網(wǎng)絡(luò)設(shè)備被劫持，信息被竊取，至少明文密碼不會泄露

總之，明文密碼最好在客戶端就被消滅掉，越早處理越好，不要把明文傳到服務(wù)端，傳輸?shù)娘L(fēng)險大，在防御上客戶端除了啟用 HTTPS 外，還要對明文密碼進行摘要處理，從而保證敏感的安全。至于客戶端應(yīng)該如何進行加密，我們接下來開始討論。

密文的創(chuàng)建和校驗

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

BCrypt 算法

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

public class BCryptExample {

    public static void main(String[] args) {
        // 創(chuàng)建 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 設(shè)置為 0.1 秒的時間，那么對所有由10位大小寫字母和數(shù)字組成的弱密碼（共62種字符）進行哈希計算一次，大約需要 8.39×10168.39×1016 秒。這等于大約 971.4 億天，或者大約 2661 百萬年的時間。這表明使用 BCrypt 和適當?shù)墓ぷ饕蜃涌梢詷O大增加破解密碼的難度，使得破解方法變得不可行。但是需要注意的是：

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