前一陣做代碼評審看到某業(yè)務(wù)模塊的用戶表里password字段直接存的是MD5值加鹽都沒有。問同事為什么這么寫他的回答特別典型“這不是加密了嗎別人拿到也解不開啊?！边@個說法我聽過太多次了。MD5、BCrypt、RSA這三個詞在很多人嘴里都是“加密”但實際上它們解決的問題完全不同用錯場景的后果也比想象中嚴重得多。今天就把這三個東西徹底聊透MD5本質(zhì)是什么、為什么它不適合存密碼BCrypt憑什么成為當前密碼存儲的主流方案RSA在數(shù)據(jù)傳輸里到底是怎么工作的以及實際項目中到底該怎么選型。1. 三種加密的本質(zhì)差異摘要、慢哈希與非對稱有些概念一混后面的坑就全踩了。先明確一個大前提MD5不是加密算法。MD5的全稱是Message-Digest Algorithm 5中文叫消息摘要算法第五版它屬于哈希函數(shù)也叫散列函數(shù)。哈希函數(shù)的特征是有輸入就能算出固定長度的輸出但反過來從輸出推輸入在計算上不可行。比如輸入“123456”MD5計算結(jié)果是“e10adc3949ba59abbe56e057f20f883e”這個過程只要幾十納秒但給你這段摘要你想反推出“123456”除了暴力窮舉沒有任何高效算法。從這個角度說MD5確實“解不開”但它的問題是可預(yù)測、可窮舉、可查表。BCrypt則不一樣。它也是一種哈希算法但它是專門為密碼存儲設(shè)計的自適應(yīng)哈希函數(shù)核心特點是“慢”。它的慢不是缺陷而是安全策略它通過內(nèi)置的cost factor成本因子主動控制計算耗時讓每一次哈希計算都需要幾十毫秒甚至幾百毫秒。一個普通用戶登錄時多等幾十毫秒完全無感但攻擊者想批量破解幾十萬條密碼時總耗時會被拉長到不可接受的程度。RSA更特殊它屬于非對稱加密是真正意義上的“可逆加密”。這里要提一個核心概念加密算法必須是可逆的。加密的本質(zhì)是在密鑰控制下把明文變成密文持有解密密鑰的人可以把密文還原成明文。MD5和BCrypt都做不到這一點它們是不可逆的單向函數(shù)。RSA的不可逆性只對沒有私鑰的人成立持有私鑰的一方可以完整解出原始數(shù)據(jù)。這一點決定了RSA的應(yīng)用方向它解決的是數(shù)據(jù)保密傳輸問題而不是密碼存儲問題。所以一張表就能說清它們的定位算法類型是否可逆核心用途典型場景MD5消息摘要不可逆完整性校驗文件校驗、接口簽名建議用更強算法替代BCrypt自適應(yīng)哈希不可逆密碼存儲用戶登錄密碼的落庫與校驗RSA非對稱加密可逆憑私鑰數(shù)據(jù)機密性密鑰交換、敏感數(shù)據(jù)加密傳輸MD5適合的場景是校驗數(shù)據(jù)有沒有被篡改BCrypt適合的場景是密碼驗證RSA適合的場景是保證傳輸過程中數(shù)據(jù)不被竊聽。三者不是同一個賽道上的競爭對手而是完全不同的三類工具。2. 為什么不能拿MD5存密碼從一次模擬“拖庫”事故說起很多團隊還在用MD5表面上是技術(shù)選型問題本質(zhì)上是對攻擊成本沒有概念。我把一次真實的模擬演練過程拆開來講你就能直觀感受到MD5存密碼有多危險。2.1 哈希速度是MD5的致命傷我用一臺普通的辦公筆記本電腦做過測試純CPU環(huán)境跑MD5每秒大約能算400萬次。看這個數(shù)字可能沒概念換一個說法假設(shè)攻擊者拿到了一整庫的用戶密碼摘要隨便選一條用最常見的弱口令字典跑一遍也就是幾百萬個候選密碼逐一做MD5計算然后比對摘要。整個過程不到一秒鐘就能把字典里所有組合試完如果這條密碼恰好是弱口令當場就能命中。更可怕的是數(shù)字升級能力。普通電腦上用支持MD5的專用破解設(shè)備或者GPU加速庫每秒可以跑到幾十億次甚至上百億次。在這個速度面前8位以內(nèi)純數(shù)字的密碼組合1秒內(nèi)必被掃穿8位小寫字母加數(shù)字的組合也就撐幾個小時的暴力窮舉。這根本不是“夠不夠安全”的討論而是“能不能撐過當天晚上”的問題。反觀BCrypt在同一臺電腦上跑一次計算大約需要80毫秒換算下來每秒只能算十來次。就算攻擊者拿到庫里所有摘要想要把字典跑完時間代價會放大幾十萬倍。這就是“慢哈希”的核心價值讓攻擊者的算力優(yōu)勢清零。2.2 彩虹表與加鹽有人會說“那我給MD5加鹽不就行了”加鹽確實有效但它解決的是另一個問題彩虹表攻擊。彩虹表是預(yù)先生成好的“密碼→摘要”映射表攻擊者可以提前把上億條常見組合的MD5值算好存起來拿庫里的摘要一對就知道密碼是什么。加鹽之后每條摘要都加入了隨機字符串同一個密碼在不同用戶下會產(chǎn)生不同摘要彩虹表直接失效。但加了鹽的MD5仍然有問題。鹽通常只增加20-30位隨機數(shù)據(jù)以當前算力攻擊者拿到鹽之后可以對目標用戶做單點窮舉。說的直白一點如果某個賬號的鹽是固定存儲的攻擊者對這條記錄跑字典攻擊速度依然是每秒幾百萬次只不過因為加鹽需要重新計算總時間會比無鹽時稍長但依然遠遠不夠安全。核心問題始終沒有解決MD5太快了。2.3 破解MD5密碼的實際路徑從一個攻擊視角看拿到MD5摘要之后破解流程大概是這樣的判斷摘要格式32位十六進制字符串基本可以確認是MD5。直接在線查詢把摘要丟到現(xiàn)成的MD5反查庫中撞庫命中率對于弱口令非常高。跑本地字典用rockyou等常見密碼字典一條條算MD5比對。暴力窮舉對短密碼、數(shù)字類密碼做全量掃描。規(guī)則變形在字典基礎(chǔ)上加后綴、改大小寫、插入生日數(shù)字這部分靠哈希速度做支撐。整個過程沒有用到任何破解“加密算法”的高級技巧純粹是算力碾壓。MD5的設(shè)計目標本來就是速度它誕生于1991年那時候的計算機算力和今天完全不在一個量級。拿30多年前為速度而生的算法來保護今天的密碼等同把家門鑰匙掛在門牌號下面誰來都能開門進去。注意不要再在新系統(tǒng)里用MD5做密碼哈希哪怕是加鹽的MD5。判斷標準很簡單一個密碼校驗過程在服務(wù)端耗時是否達到50毫秒以上。達不到就說明算法選錯了。3. BCrypt正確打開方式參數(shù)選擇與落地配置BCrypt是當前存儲密碼最穩(wěn)妥的常見選擇之一它從設(shè)計之初就假定攻擊者算力強大因此故意把計算拉慢。要做到“安全且不那么影響體驗”關(guān)鍵在參數(shù)。3.1 BCrypt的鹽是自動處理的很多人習慣“密碼哈希算法(密碼鹽)”但BCrypt的用法完全不同。BCrypt生成的字符串自帶鹽而且鹽是明文嵌在哈希結(jié)果里的。調(diào)用BCrypt校驗時只需要把存儲的哈希字符串和用戶輸入的密碼傳進去算法會自動從哈希串中提取鹽重新計算再跟存儲值比對。一個典型的BCrypt哈希長這樣$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy拆開看$2a$是算法版本標識10是cost factor緊接著的22個字符是鹽后面的字符串是真正的哈希值。整個過程不需要開發(fā)者在數(shù)據(jù)庫里單獨開一個salt字段也不需要自己生成隨機字符串省事很多。這一點對新手極其友好也減少了一個很容易犯的錯誤把鹽寫死在代碼里。BCrypt自動管理鹽天然規(guī)避了這個問題。3.2 cost factor選多少從算力角度拆解cost factor是BCrypt的核心調(diào)優(yōu)參數(shù)它決定計算迭代次數(shù)。數(shù)學關(guān)系是迭代次數(shù) 2 的 cost 次方。cost10時做1024輪cost12時做4096輪每增加1耗時翻倍。那么應(yīng)該選多少我慣用的流程是先在本機跑一個基準測試# 以Python為例快速測速 python -c import bcrypt, time for cost in [10, 11, 12, 13]: start time.time() for _ in range(10): bcrypt.hashpw(btest, bcrypt.gensalt(roundscost)) print(cost, (time.time()-start)/10*1000, ms) 不同機器結(jié)果不一樣大致可以參考我的MBP上cost10時單次哈希約65毫秒cost12時約260毫秒cost14時已經(jīng)到了秒級。選擇標準是服務(wù)端高峰期CPU能承受、用戶等待可接受即可。個人建議在常規(guī)Web項目里從cost10起步壓測時如果發(fā)現(xiàn)CPU占用過高再上調(diào)或下調(diào)。有一個反直覺的細節(jié)值得注意cost過低時BCrypt和MD5的區(qū)別被削弱失去抗暴力破解的意義但cost過高時用戶體驗會明顯變差而且在惡意攻擊下攻擊者可以大量請求登錄接口消耗服務(wù)器CPU形成變相的拒絕服務(wù)攻擊。所以不是越大越好需要平衡。Java里常見的Spring Security配置是這樣BCryptPasswordEncoder encoder new BCryptPasswordEncoder(10); String encoded encoder.encode(user_password); boolean matched encoder.matches(user_password, encoded);Python里也很簡潔import bcrypt hashed bcrypt.hashpw(buser_password, bcrypt.gensalt(rounds10)) ok bcrypt.checkpw(buser_password, hashed)3.3 BCrypt的輸入長度限制與額外防護BCrypt有一個很少被注意到的硬限制它只處理前72字節(jié)的輸入超過部分會被直接忽略。也就是說如果用戶密碼超過72字節(jié)后面輸入再多也不會參與哈希計算。對絕大多數(shù)人來說72字節(jié)夠用了因為普通密碼最多二三十個字符但如果你做的是國際化產(chǎn)品允許用戶填寫很長很復(fù)雜的密碼甚至把整句話當密碼就要注意這個邊界。兩種做法可以解決一是在加密前直接限制密碼最大長度比如最多64字節(jié)二是在BCrypt之前先做一次SHA-256再把SHA-256的原始字節(jié)丟給BCrypt。第二種方式兼容性不錯但要注意必須先取原始字節(jié)而不是十六進制字符串否則長度會翻倍依然可能超出限制。另一個實用的經(jīng)驗是不要把“密碼是否匹配”和“賬號是否存在”的響應(yīng)區(qū)別得太明顯。如果登錄時“賬號不存在”和“密碼錯誤”返回不同的提示攻擊者可以借此枚舉賬號。業(yè)界常用的做法是統(tǒng)一提示“賬號或密碼錯誤”。雖然BCrypt本身不會泄露賬號狀態(tài)但響應(yīng)層面的信息泄露往往被忽略。密碼存儲是一個縱深防御的問題除了選對算法還要注意其他部分密碼復(fù)雜度策略、登錄接口限流、異常登錄告警、定期強制更新高?？诹?。BCrypt解決的是密碼落庫后“即使拖庫也難以破解”的問題但它抗不了弱密碼本身也抗不了用戶把密碼寫在便利貼上這種物理泄露。4. RSA與數(shù)據(jù)傳輸從密鑰對生成到混合加密實踐RSA是公鑰密碼體系的代表它和對稱加密的最大區(qū)別在于加密和解密用的是兩把不同的鑰匙一把公開一把私藏。這個特性讓它在數(shù)據(jù)傳輸場景中顯得特別重要。4.1 公鑰加密、私鑰解密的流程先理解一個最直觀的用法。假設(shè)服務(wù)端要給某個客戶端傳輸一段敏感數(shù)據(jù)客戶端可以先把自己的公鑰發(fā)給服務(wù)端服務(wù)端用這個公鑰加密數(shù)據(jù)密文到達客戶端之后客戶端用私鑰解密整個過程中沒有任何人能看到明文。這里有個關(guān)鍵點公鑰是公開的誰都可以拿到但即使拿到了公鑰也無法推出私鑰。RSA的安全性建立在“大整數(shù)分解”的數(shù)學難題之上給定一個大合數(shù)要把它分解成兩個大質(zhì)數(shù)在當前算力下極其困難。密鑰長度越長分解難度指數(shù)級上升。以RSA-2048為例要分解一個2048位的整數(shù)地球上目前沒有任何公開的算力可以在可行時間內(nèi)完成。這就是RSA能保護傳輸數(shù)據(jù)的根基。4.2 密鑰長度與數(shù)據(jù)長度的限制關(guān)于RSA有一個常見的認知誤區(qū)以為RSA和AES一樣可以加密任意長度的數(shù)據(jù)。實際上RSA對明文長度有嚴格限制。以2048位密鑰為例RSA一次能加密的明文最大長度是密鑰長度(字節(jié)) - 填充占用(字節(jié))如果用PKCS#1 v1.5填充每個塊要占11字節(jié)的開銷那么最大明文長度 2048 / 8 - 11 245字節(jié)。如果用OAEP填充推薦SHA-1時開銷為42字節(jié)最大明文長度是214字節(jié)SHA-256時開銷更多最大明文190字節(jié)左右。超過這個長度就必須把數(shù)據(jù)進行分段加密每段分別用RSA加密再拼接性能極差。所以真實業(yè)務(wù)里幾乎不會用RSA直接加密業(yè)務(wù)數(shù)據(jù)而是采用混合加密。經(jīng)典的HTTPS握手就是這么做的客戶端生成一個臨時的對稱密鑰實際是Pre-Master Secret?？蛻舳擞梅?wù)器的RSA公鑰加密這個臨時對稱密鑰發(fā)送給服務(wù)器。服務(wù)器用RSA私鑰解密得到臨時對稱密鑰。后續(xù)所有業(yè)務(wù)數(shù)據(jù)都用這個對稱密鑰配合AES算法加密傳輸。這樣做的理由很好理解對稱加密AES加解密速度快可以處理任意長度數(shù)據(jù)但存在密鑰分發(fā)問題RSA解決密鑰分發(fā)但速度慢、長度受限。把兩者結(jié)合各取所長就是日常所有加密通信的基本套路。4.3 RSA的實際代碼操作與坑假設(shè)你寫了一個接口要給第三方傳遞保單數(shù)據(jù)又不方便走HTTPS常見做法是約定RSA公鑰加密。用Java實現(xiàn)時大致是這樣// 讀取對方公鑰 PublicKey publicKey readPublicKey(publicKeyPemText); Cipher cipher Cipher.getInstance(RSA/ECB/PKCS1Padding); cipher.init(Cipher.ENCRYPT_MODE, publicKey); byte[] encrypted cipher.doFinal(plainData);接收方解密PrivateKey privateKey readPrivateKey(privateKeyPemText); Cipher cipher Cipher.getInstance(RSA/ECB/PKCS1Padding); cipher.init(Cipher.DECRYPT_MODE, privateKey); byte[] decrypted cipher.doFinal(base64Decoded(encrypted));看起來簡單但坑非常多。最常見的坑包括第一個坑加密結(jié)果要Base64編碼。RSA加密后得到的密文是二進制數(shù)據(jù)直接轉(zhuǎn)成UTF-8字符串必然亂碼。必須用Base64做文本化編碼傳輸?shù)綄Χ嗽俳獯a。很多新手在這個環(huán)節(jié)卡半天還以為是RSA解不開。第二個坑密鑰和加密公鑰的格式解析。不同語言生成RSA密鑰的格式有差異。Java默認生成的X.509格式公鑰可以直接用getPublicKey讀但如果對方發(fā)的PEM格式帶了-----BEGIN PUBLIC KEY-----頭就需要先把頭尾去掉做Base64解碼后再通過KeyFactory生成。第三個坑分段加密問題。上面提到的245字節(jié)限制直接作用就是如果業(yè)務(wù)字段超過這個長度doFinal會拋DataLengthMustBeLessThanModulus異常。很多項目在測試階段功能正常一上線傳了長文本就爆。解決辦法就是改用混合加密或者對字段長度做強制校驗。第四個坑私鑰權(quán)限保護。RSA私鑰一旦泄露所有用它加密過的歷史數(shù)據(jù)都存在風險因為它可以解出私鑰對應(yīng)的所有密文。私鑰文件在生產(chǎn)環(huán)境必須做嚴格權(quán)限控制不能放進代碼倉庫也不能打日志打印。正確的做法是把私鑰放在專用密鑰管理服務(wù)中應(yīng)用運行時通過接口讀取。4.4 推薦的混合加密實現(xiàn)思路如果業(yè)務(wù)量不大但確實有敏感數(shù)據(jù)傳輸需求AESRSA混合加密在應(yīng)用層的實現(xiàn)思路如下每次加密時隨機生成一個AES密鑰用AES-GCM加密業(yè)務(wù)數(shù)據(jù)得到密文和認證標簽。用接收方的RSA公鑰加密這個AES密鑰。把“加密后的AES密鑰”和“AES密文”一起傳給接收方JSON字段分別叫encrypted_key和payload。接收方先用RSA私鑰解密出AES密鑰再用AES密鑰解密業(yè)務(wù)數(shù)據(jù)。這樣做的好處是業(yè)務(wù)數(shù)據(jù)大小不受RSA限制加密性能也遠遠優(yōu)于純RSA同時RSA只負責保護體積很小的對稱密鑰安全性也得到保證。這也是項目里最穩(wěn)妥的長期方案。5. 常見問題速查與選型決策表寫到這里把我在實際項目中遇到的高頻問題和決策經(jīng)驗統(tǒng)一整理一下方便大家直接對照。5.1 高頻率踩坑問題問題原因解決方案登錄校驗總是通不過BCrypt哈希里帶了鹽比對時必須用checkpw/matches不能直接比較哈希字符串確認代碼調(diào)用的是比對函數(shù)而不是字符串相等BCrypt存入數(shù)據(jù)庫報錯哈希串長度60個字符部分數(shù)據(jù)庫字段定義為varchar(32)字段長度改成varchar(64)或更長RSA加密后一頓亂碼沒做Base64編碼把二進制密文當字符串傳輸加密后Base64編碼文本化解密前先解碼RSA報DataLengthMustBeLessThanModulus單次加密數(shù)據(jù)超過密鑰上限改用混合加密或?qū)ψ侄巫鲩L度限制并用分段加密加鹽MD5還被破解哈希太快加鹽只擋彩虹表擋不住暴力窮舉換BCrypt等慢哈希方案別再優(yōu)化速度密碼哈希結(jié)果每次都不一樣這正是BCrypt的正常行為因為鹽隨機生成不要慌校驗函數(shù)內(nèi)部會自己處理鹽5.2 選型時想清楚三件事第一個問題是“數(shù)據(jù)需要還原嗎”。需要還原的選對稱加密如AES或非對稱加密如RSA不需要還原只做比對的選哈希方案BCrypt優(yōu)先。第二個問題是“誰要解這個數(shù)據(jù)”。如果只有接收方自己能解RSA或AES都行如果需要雙方各自持有一把不同鑰匙非對稱加密是唯一選擇。第三個問題是“被破解的代價有多大”。用戶密碼這種一旦泄露就是大范圍安全事件的數(shù)據(jù)必須用BCrypt臨時性的、低敏感的接口簽名用HMAC-SHA256就夠不必上RSA。5.3 關(guān)于MD5的一點公正評價說MD5不適合存密碼不等于MD5毫無用途。它在完整性校驗領(lǐng)域仍然有歷史地位比如下載文件時對比MD5值確認文件沒有損壞。但即便是完整性校驗今天也建議優(yōu)先用SHA-256或SHA-3因為MD5碰撞問題已經(jīng)被公開證明攻擊者可以構(gòu)造兩個不同內(nèi)容但MD5相同的文件這在安全攸關(guān)的校驗場景中是致命的。自2011年之后大部分CA機構(gòu)就不再信任MD5簽名的證書了。說句實在話新寫代碼時遇到MD5就直接打問號絕大部分場景都有更好的替代方案。真正非MD5不可的現(xiàn)代業(yè)務(wù)我還沒遇到過。6. 實操場景復(fù)盤與經(jīng)驗總結(jié)去年某項目接手一套老系統(tǒng)用戶表里上百萬條密碼全都是加鹽MD5。當時沒法一鍵全量遷移到BCrypt因為BCrypt校驗必須重新用密碼原文算而原文已經(jīng)不在了。最后采用漸進遷移策略登錄時先拿用戶輸入的密碼先做MD5校驗如果MD5比對通過立即用這一次輸入的明文密碼重新生成BCrypt哈希并更新數(shù)據(jù)庫下一次登錄走BCrypt校驗。一個多月后活躍用戶就全部遷移到了BCrypt。這個方案不用發(fā)密碼重置郵件也不用改用戶邏輯體驗平滑到幾乎無感。另一件事也和RSA有關(guān)。某個對接項目里對方要求用RSA加密請求體結(jié)果他們給的公鑰是2048位的而我方傳的參數(shù)卻以JSON字符串整體加密明文長度輕松超過200字節(jié)。聯(lián)調(diào)時報錯之后雙方第一反應(yīng)都是“對方RSA實現(xiàn)有問題”花了不少時間才定位到是數(shù)據(jù)長度超標。后來我把方案改成請求體先用AES-GCM加密再用RSA加密AES密鑰問題就再沒出現(xiàn)過。這個經(jīng)驗我見到類似的對接問題就一定會提一遍。這三種算法的選擇看似復(fù)雜歸根到底就是一句話想清楚數(shù)據(jù)要不要還原、誰需要還原、被還原后的代價有多大。密碼存儲選慢哈希BCrypt數(shù)據(jù)傳輸選非對稱加密RSA加上對稱加密AES的混合方案完整性校驗選SHA-256系。每種算法都有自己的生態(tài)位選對了就是安心的保障選錯了就是埋雷。最后分享一個我自己的習慣每次接新項目第一件事就是檢查現(xiàn)有代碼的哈希算法和加密方案看到MD5存密碼就標記為高優(yōu)先級技術(shù)債看到RSA分塊加密大數(shù)據(jù)就標記為重構(gòu)項。這些細節(jié)平時不顯山不露水一旦出事都是大事故。早點把它修好比任何事后補救都省心。