前后端分離的項(xiàng)目我做過不少登錄認(rèn)證這塊也踩過很多坑。早年在某公司做內(nèi)部管理系統(tǒng)時(shí)因?yàn)榈卿浗涌诒煌伦グl(fā)現(xiàn)密碼明文傳輸直接被安全團(tuán)隊(duì)點(diǎn)名整改——那會(huì)兒用戶密碼就是明文走HTTP只要在局域網(wǎng)里開個(gè)抓包工具賬號(hào)密碼就裸奔了。后來我重構(gòu)了整套認(rèn)證流程核心方案就是 Spring Boot Vue 基于 RSA 的用戶身份認(rèn)證加密機(jī)制。這篇文章把這套方案的完整設(shè)計(jì)與實(shí)現(xiàn)細(xì)節(jié)拆開講清楚從選型、后端實(shí)現(xiàn)、前端對(duì)接到聯(lián)調(diào)時(shí)容易踩的坑全部記錄下來。這個(gè)方案解決的核心問題很直接在前后端分離架構(gòu)下如何保證用戶密碼從瀏覽器發(fā)出時(shí)不是明文如何讓后端安全地還原密文并完成認(rèn)證同時(shí)兼顧工程上的可維護(hù)性和安全基線。適合正在做登錄模塊、被安全評(píng)審要求加密傳輸?shù)拈_發(fā)者參考也適合想理解非對(duì)稱加密在真實(shí)業(yè)務(wù)中怎么落地的朋友。1. 登錄加密方案問題拆解與選型背后的思考1.1 明文密碼傳輸?shù)碾[患到底有多大很多人覺得內(nèi)網(wǎng)系統(tǒng)、后端接口沒暴露公網(wǎng)密碼明文傳輸沒多大問題。這個(gè)想法我也有過直到被真實(shí)打臉。即使是內(nèi)網(wǎng)環(huán)境只要有人用 Wireshark 抓包或者在公司交換機(jī)上做一個(gè)鏡像端口所有HTTP請(qǐng)求里的密碼都是可讀的。更別說現(xiàn)在前后端分離的項(xiàng)目通常還會(huì)部署到公網(wǎng)或者通過小程序、App 端共用同一套 API。密碼明文傳輸帶來的風(fēng)險(xiǎn)不只是密碼泄露本身而是連鎖反應(yīng)。大部分人的密碼習(xí)慣是多個(gè)平臺(tái)復(fù)用同一個(gè)密碼一旦某個(gè)系統(tǒng)的密碼被拿到攻擊者會(huì)拿這個(gè)密碼去嘗試其他平臺(tái)。所以即使是一個(gè)不起眼的后臺(tái)管理系統(tǒng)密碼泄露也可能成為突破口。安全團(tuán)隊(duì)當(dāng)時(shí)給我看的報(bào)告里寫得清清楚楚明文密碼屬于高危漏洞整改方式就是傳輸加密。那為什么不用 MD5 加鹽之后再傳給后端嚴(yán)格來說這種方式防的是數(shù)據(jù)庫泄露后反向破解但對(duì)傳輸過程本身沒有任何保護(hù)。MD5 后的值仍然是固定值攻擊者抓包拿到這個(gè)值直接重放請(qǐng)求后端根本區(qū)分不了這是原始密碼還是摘要值。也就是說MD5 加鹽解決的是存儲(chǔ)安全不是傳輸安全。傳輸加密需要的是前端用某把密鑰加密后端用對(duì)應(yīng)的密鑰解密。這就引出了密鑰管理的選型問題。1.2 對(duì)稱加密與非對(duì)稱加密的取舍做傳輸加密最先想到的方案往往是 AES 對(duì)稱加密。AES 加解密速度快后端生成一個(gè) AES 密鑰前端拿到這個(gè)密鑰對(duì)密碼加密后端用同一個(gè)密鑰解密。但這里有個(gè)致命的問題AES 密鑰怎么安全地交給前端如果通過接口返回密鑰那么抓包的人同樣能拿到這把 AES 密鑰他就能自己解密請(qǐng)求里的密文甚至用這把密鑰偽造請(qǐng)求。你等于把鎖和鑰匙一起交給了對(duì)方。有人會(huì)說那把密鑰寫死在前端代碼里那更糟前端打包后的JS文件里直接能搜到密鑰字符串這層加密就是心理安慰。非對(duì)稱加密 RSA 的思路正好繞開了這個(gè)困境。RSA 密鑰對(duì)分成公鑰和私鑰公鑰公開沒關(guān)系它能加密不能解密私鑰只在后端保存用來解密。前端用后端下發(fā)的公鑰加密密碼就算攻擊者抓到了公鑰和密文沒有私鑰他也還原不出明文密碼。RSA 在這個(gè)場(chǎng)景下是最契合的選型。雖然它加解密速度比 AES 慢但登錄時(shí)只加密一個(gè)密碼字段數(shù)據(jù)量很小性能完全不是瓶頸。而且 RSA 還有 AES 不具備的附加價(jià)值后端可以用私鑰對(duì)令牌做簽名前端用公鑰驗(yàn)簽同一套密鑰體系可以服務(wù)多種安全場(chǎng)景。所以在登錄認(rèn)證場(chǎng)景下我直接用 RSA 而不是 AES。注意不要試圖用 RSA 加密整個(gè)請(qǐng)求體RSA 有長度限制且性能不占優(yōu)加密密碼、手機(jī)號(hào)這類短字段最合適。請(qǐng)求體整體加密請(qǐng)考慮 AES RSA 混合方案。1.3 整體認(rèn)證流程設(shè)計(jì)這套方案的核心流程如下前端用戶打開登錄頁時(shí)先向后端發(fā)起獲取公鑰的請(qǐng)求后端生成 RSA 密鑰對(duì)或從緩存取將公鑰的 Base64 字符串返回給前端。前端拿到公鑰后用 JSEncrypt 庫對(duì)用戶輸入的密碼進(jìn)行加密得到一段 RSA 密文然后連同用戶名一起提交到登錄接口。后端登錄接口從請(qǐng)求中取出密文用保存在服務(wù)端的 RSA 私鑰解密還原出明文密碼再走原有的用戶名密碼校驗(yàn)邏輯。校驗(yàn)通過后后端生成一個(gè)認(rèn)證令牌實(shí)際項(xiàng)目中可以用 JWT返回給前端。前端保存令牌后續(xù)請(qǐng)求在請(qǐng)求頭中攜帶這個(gè)令牌實(shí)現(xiàn)會(huì)話保持。流程上看只是多了“獲取公鑰”和“密碼加密”兩個(gè)環(huán)節(jié)但安全效果完全不同。密碼在整個(gè)傳輸鏈路上都是密文狀態(tài)只有后端私鑰能解密。2. 后端 Spring Boot 核心實(shí)現(xiàn)密鑰生成、解密接口與登錄認(rèn)證2.1 工程結(jié)構(gòu)與依賴準(zhǔn)備我用的技術(shù)棧是 Spring Boot 2.7 MyBatis-Plus JWTJDK1.8。先看工程依賴dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mindrot/groupId artifactIdjbcrypt/artifactId version0.4/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency dependency groupIdcommons-codec/groupId artifactIdcommons-codec/artifactId version1.15/version /dependency項(xiàng)目結(jié)構(gòu)上我單獨(dú)抽了一個(gè)crypto包用來放 RSA 相關(guān)代碼和業(yè)務(wù)代碼隔離。因?yàn)?RSA 工具類將來可能會(huì)在多個(gè)模塊復(fù)用獨(dú)立成包方便維護(hù)。核心類就三個(gè)RsaKeyService負(fù)責(zé)密鑰生命周期管理、RsaUtils加解密靜態(tài)工具、LoginController登錄接口。2.2 RSA 工具類的關(guān)鍵細(xì)節(jié)分段加密RSA 工具類是整套方案的基石。這里有一個(gè)非常關(guān)鍵的細(xì)節(jié)RSA 加密對(duì)明文長度有限制。使用 1024 位密鑰時(shí)最多只能加密 117 字節(jié)使用 2048 位密鑰時(shí)最多只能加密 245 字節(jié)。登錄密碼通常只有幾十字節(jié)但為了后續(xù)擴(kuò)展比如加密手機(jī)號(hào)、身份證號(hào)我統(tǒng)一實(shí)現(xiàn)分段加解密。public class RsaUtils { private static final String ALGORITHM RSA; private static final String TRANSFORMATION RSA/ECB/PKCS1Padding; private static final int KEY_SIZE 2048; // RSA/ECB/PKCS1Padding模式下2048位密鑰最多加密245字節(jié) private static final int MAX_ENCRYPT_BLOCK 245; // 解密對(duì)應(yīng)最長支持256字節(jié) private static final int MAX_DECRYPT_BLOCK 256; public static KeyPair generateKeyPair() throws NoSuchAlgorithmException { KeyPairGenerator keyPairGenerator KeyPairGenerator.getInstance(ALGORITHM); SecureRandom secureRandom new SecureRandom(); keyPairGenerator.initialize(KEY_SIZE, secureRandom); return keyPairGenerator.generateKeyPair(); } public static String encryptByPublicKey(String data, String publicKeyString) throws Exception { byte[] dataBytes data.getBytes(StandardCharsets.UTF_8); byte[] keyBytes Base64.decodeBase64(publicKeyString); PublicKey publicKey KeyFactory.getInstance(ALGORITHM) .generatePublic(new X509EncodedKeySpec(keyBytes)); // 對(duì)數(shù)據(jù)分段加密 ByteArrayOutputStream out new ByteArrayOutputStream(); try { Cipher cipher Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.ENCRYPT_MODE, publicKey); int inputLen dataBytes.length; int offSet 0; byte[] cache; int i 0; while (inputLen - offSet 0) { if (inputLen - offSet MAX_ENCRYPT_BLOCK) { cache cipher.doFinal(dataBytes, offSet, MAX_ENCRYPT_BLOCK); } else { cache cipher.doFinal(dataBytes, offSet, inputLen - offSet); } out.write(cache, 0, cache.length); i; offSet i * MAX_ENCRYPT_BLOCK; } return Base64.encodeBase64String(out.toByteArray()); } finally { out.close(); } } public static String decryptByPrivateKey(String data, String privateKeyString) throws Exception { byte[] dataBytes Base64.decodeBase64(data); byte[] keyBytes Base64.decodeBase64(privateKeyString); PrivateKey privateKey KeyFactory.getInstance(ALGORITHM) .generatePrivate(new PKCS8EncodedKeySpec(keyBytes)); // 對(duì)數(shù)據(jù)分段解密 ByteArrayOutputStream out new ByteArrayOutputStream(); try { Cipher cipher Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.DECRYPT_MODE, privateKey); int inputLen dataBytes.length; int offSet 0; byte[] cache; int i 0; while (inputLen - offSet 0) { if (inputLen - offSet MAX_DECRYPT_BLOCK) { cache cipher.doFinal(dataBytes, offSet, MAX_DECRYPT_BLOCK); } else { cache cipher.doFinal(dataBytes, offSet, inputLen - offSet); } out.write(cache, 0, cache.length); i; offSet i * MAX_DECRYPT_BLOCK; } return out.toString(StandardCharsets.UTF_8.name()); } finally { out.close(); } } }幾個(gè)容易出錯(cuò)的地方提醒一下前端加密后的密文是 Base64 字符串后端拿到后必須先 Base64 解碼再交給 RSA 解密。很多人忘記這一步直接拿字符串去解報(bào)javax.crypto.BadPaddingException。密鑰字符串存儲(chǔ)的格式是公鑰用X509EncodedKeySpec解析私鑰用PKCS8EncodedKeySpec解析。搞混了會(huì)報(bào)InvalidKeySpecException。SecureRandom初始化 KeyPairGenerator 是必要的可以避免在某些 JDK 版本下生成弱隨機(jī)密鑰。2.3 RsaKeyService 密鑰管理策略密鑰管理這里我做了兩個(gè)層面的設(shè)計(jì)。密鑰對(duì)的生成時(shí)機(jī)服務(wù)啟動(dòng)時(shí)生成一次還是每次獲取公鑰接口被調(diào)用時(shí)重新生成如果每次請(qǐng)求公鑰都重新生成密鑰對(duì)那么上一個(gè)公鑰加密的密文后端再用新私鑰解密就會(huì)失敗。如果前端同時(shí)打開了多個(gè)登錄頁拿到不同的公鑰就會(huì)出現(xiàn)“明明輸入的密碼沒錯(cuò)后端卻提示密碼解密失敗”的詭異問題。我采用的方案是應(yīng)用啟動(dòng)時(shí)生成一次密鑰對(duì)緩存在內(nèi)存中。獲取公鑰接口直接返回緩存中的公鑰登錄解密時(shí)使用緩存的私鑰。這樣所有前端拿到的都是同一把公鑰后端私鑰自始至終也是同一把。密鑰在內(nèi)存中不會(huì)持久化到磁盤應(yīng)用重啟后密鑰對(duì)自然更換安全性也有保障。Service public class RsaKeyService { PostConstruct public void init() { try { KeyPair keyPair RsaUtils.generateKeyPair(); this.publicKey Base64.encodeBase64String(keyPair.getPublic().getEncoded()); this.privateKey Base64.encodeBase64String(keyPair.getPrivate().getEncoded()); } catch (NoSuchAlgorithmException e) { throw new RuntimeException(RSA密鑰初始化失敗, e); } } private String publicKey; private String privateKey; public String getPublicKey() { return publicKey; } public String decrypt(String cipherText) { try { return RsaUtils.decryptByPrivateKey(cipherText, privateKey); } catch (Exception e) { throw new RuntimeException(解密失敗, e); } } }如果追求更強(qiáng)的安全性可以給密鑰對(duì)設(shè)置一個(gè)有效期比如每隔 24 小時(shí)重新生成一次并讓前端重新拉取公鑰。但要注意兼容會(huì)話中已經(jīng)使用舊公鑰加密的請(qǐng)求實(shí)際項(xiàng)目中我建議先做固定密鑰等穩(wěn)定后再考慮輪換。2.4 獲取公鑰接口與登錄接口實(shí)現(xiàn)獲取公鑰的接口很簡單就是一個(gè) GET 請(qǐng)求返回當(dāng)前公鑰字符串。但登錄接口需要注意幾個(gè)防御細(xì)節(jié)。RestController RequestMapping(/api/auth) public class LoginController { Autowired private RsaKeyService rsaKeyService; GetMapping(/publicKey) public ResultString getPublicKey() { return Result.success(rsaKeyService.getPublicKey()); } PostMapping(/login) public ResultLoginVO login(RequestBody LoginRequest request) { // 每次登錄嘗試前先檢查失敗次數(shù)防止暴力破解 if (loginAttemptService.isBlocked(request.getUsername())) { return Result.fail(嘗試次數(shù)過多請(qǐng)稍后再試); } String publicKey rsaKeyService.getPublicKey(); String decryptPassword; try { decryptPassword rsaKeyService.decrypt(request.getPassword()); } catch (Exception e) { logger.warn(密碼解密失敗用戶{}, request.getUsername()); return Result.fail(密碼解密失敗請(qǐng)刷新頁面后重試); } // 用戶名同樣建議加密傳輸從密文中解密 String decryptUsername rsaKeyService.decrypt(request.getUsername()); User user userService.findByUsername(decryptUsername); if (user null || !passwordEncoder.matches(decryptPassword, user.getPassword())) { loginAttemptService.loginFailed(request.getUsername()); return Result.fail(用戶名或密碼錯(cuò)誤); } // 登錄成功后簽發(fā) JWT String token jwtUtil.createToken(user.getId(), user.getUsername()); return Result.success(new LoginVO(token, user.getUsername())); } }為什么用戶名也要一起加密因?yàn)楣饧用苊艽a、用戶名明文傳輸攻擊者雖然拿不到密碼但可以收集系統(tǒng)里的有效用戶名用戶名本身就是一種敏感信息。登錄時(shí)把用戶名和密碼一起加密前端可以拼接成username : password再加密后端解密后拆分這樣其實(shí)更省事。不過要注意分隔符選擇避免用戶名或密碼中含有的字符沖突。登錄失敗之后返回給前端的提示語無論失敗原因是用戶不存在還是密碼錯(cuò)誤統(tǒng)一返回“用戶名或密碼錯(cuò)誤”避免泄露用戶名是否存在。這個(gè)屬于安全基線里的細(xì)節(jié)但很多人會(huì)忽略。2.5 密碼存儲(chǔ)的二次加固RSA 解決的是傳輸過程的問題但密碼到了后端存儲(chǔ)環(huán)節(jié)也不能裸奔。很多老系統(tǒng)用戶表里的密碼就是 MD5 或者 SHA1這種值可以查彩虹表直接還原等于把用戶的明文密碼變相暴露了。我在這個(gè)項(xiàng)目里對(duì)數(shù)據(jù)庫存儲(chǔ)也做了加固使用了 BCrypt 算法。BCrypt 的顯著特點(diǎn)是每次哈希同一個(gè)字符串會(huì)得到不同的結(jié)果因?yàn)樗鼉?nèi)部自動(dòng)加入隨機(jī)鹽。它還要一個(gè)成本因子參數(shù)默認(rèn) 10可以配置成 12 讓它計(jì)算更慢。這個(gè)慢其實(shí)是故意設(shè)計(jì)的目的就是拖慢攻擊者的批量破解速度讓暴力破解單個(gè)密碼的成本大大增加。Component public class PasswordEncoder { public String encode(String rawPassword) { return BCrypt.hashpw(rawPassword, BCrypt.gensalt(12)); } public boolean matches(String rawPassword, String encodedPassword) { return BCrypt.checkpw(rawPassword, encodedPassword); } }登錄流程在工程上還有一個(gè)性能上的坑RA 解密 BCrypt 校驗(yàn)兩步計(jì)算加起來會(huì)比純 MD5 校驗(yàn)慢一些用戶基本感知不到。但要注意如果系統(tǒng)面臨著極高的并發(fā)登錄壓力BCrypt 的慢反而會(huì)放大風(fēng)險(xiǎn)攻擊者可以故意發(fā)起海量登錄請(qǐng)求來消耗 CPU。所以限流措施是必須的至少要對(duì)登錄接口做一個(gè)簡單的并發(fā)限流。3. 前端 Vue 對(duì)接加密封裝、登錄調(diào)用與請(qǐng)求攔截3.1 依賴選擇與封裝思路Vue 前端做 RSA 加密我用的是jsencrypt這個(gè)庫。它在瀏覽器端的實(shí)現(xiàn)很成熟封裝了公鑰加密和私鑰解密的邏輯API 非常簡單幾行代碼就能跑通。Vue2 直接 npm 安裝后引入Vue3 也無縫支持。npm install jsencrypt安裝之后我習(xí)慣在src/utils/rsa.js里單獨(dú)封裝一個(gè)加密工具而不是在頁面組件里直接寫加密邏輯。原因是將來如果有多個(gè)頁面都要加密字段比如修改密碼頁、綁定手機(jī)頁、支付密碼頁統(tǒng)一封裝后一處修改、處處生效。import JSEncrypt from jsencrypt // 每次用前都要先初始化否則會(huì)丟失密鑰 const encryptor new JSEncrypt() /** * 使用公鑰加密 * param {String} content 明文內(nèi)容 * param {String} publicKey Base64編碼的公鑰 * returns {String|false} 加密失敗返回 false */ export function encryptByPublicKey(content, publicKey) { encryptor.setPublicKey(publicKey) return encryptor.encrypt(content) }注意encryptor定義為模塊級(jí)常量而不是在函數(shù)內(nèi)部 new 出來的是因?yàn)槊看?new 都會(huì)重新生成內(nèi)部狀態(tài)性能開銷不必要。但要注意在并發(fā)場(chǎng)景如果兩個(gè)請(qǐng)求同時(shí)使用同一個(gè) encryptor 實(shí)例可能互相覆蓋密鑰狀態(tài)。在登錄場(chǎng)景下并發(fā)加密的情況很少這個(gè)寫法是安全的。3.2 獲取公鑰并緩存公鑰獲取接口的調(diào)用時(shí)機(jī)可以在每次登錄前實(shí)時(shí)拉取也可以在應(yīng)用啟動(dòng)時(shí)拉取一次緩存進(jìn) Vuex 或內(nèi)存變量。我推薦登錄頁面加載時(shí)異步獲取一次存到 store 里這樣即使用戶停留了很久再登錄拿到的公鑰也是最新的。// store/modules/auth.js const state { publicKey: , token: } const mutations { SET_PUBLIC_KEY(state, key) { state.publicKey key } } const actions { async fetchPublicKey({ commit }) { const res await request({ url: /api/auth/publicKey, method: get }) commit(SET_PUBLIC_KEY, res.data) return res.data } }3.3 登錄頁面完整實(shí)現(xiàn)登錄頁的提交邏輯是先確保公鑰已經(jīng)存在然后把用戶名和密碼拼接后加密再把加密后的字符串按字段名傳給后端。這里我選擇“用戶名和密碼拼接后一起加密”而不是分別加密因?yàn)?HSEncrypt 的 RSA 加密每次產(chǎn)生的密文不同分別加密兩個(gè)短字符串會(huì)多兩次加密開銷而且拼在一起只調(diào)用一次加密出錯(cuò)的概率更小。template div classlogin-container el-form :modelloginForm submit.preventhandleLogin el-form-item label用戶名 el-input v-modelloginForm.username placeholder請(qǐng)輸入用戶名 / /el-form-item el-form-item label密碼 el-input v-modelloginForm.password typepassword placeholder請(qǐng)輸入密碼 show-password / /el-form-item el-button typeprimary :loadingloading clickhandleLogin 登 錄 /el-button /el-form /div /template script import { encryptByPublicKey } from /utils/rsa import { mapState, mapActions } from vuex export default { name: LoginPage, data() { return { loginForm: { username: , password: }, loading: false } }, computed: { ...mapState({ publicKey: state state.auth.publicKey }) }, methods: { ...mapActions([fetchPublicKey]), async handleLogin() { if (!this.loginForm.username || !this.loginForm.password) { this.$message.warning(請(qǐng)輸入用戶名和密碼) return } this.loading true try { let publicKey this.publicKey if (!publicKey) { publicKey await this.fetchPublicKey() } const content this.loginForm.username : this.loginForm.password const encrypted encryptByPublicKey(content, publicKey) if (!encrypted) { throw new Error(RSA 加密失敗) } await this.$store.dispatch(auth/login, { encryptedData: encrypted }) this.$message.success(登錄成功) this.$router.push(/dashboard) } catch (error) { this.$message.error(error.message || 登錄失敗請(qǐng)稍后重試) } finally { this.loading false } } }, mounted() { if (!this.publicKey) { this.fetchPublicKey() } } } /script登錄接口層面對(duì)應(yīng)地也需要調(diào)整參數(shù)結(jié)構(gòu)。前端傳的是encryptedData后端從請(qǐng)求體里取這一個(gè)字段就足夠了?？梢宰尯蠖私邮找粋€(gè)通用請(qǐng)求對(duì)象EncryptedRequestpublic class EncryptedRequest { private String encryptedData; // getter setter 省略 }后端拿到encryptedData后解密得到username:password格式的字符串再按第一個(gè)冒號(hào)位置拆分成用戶名和密碼。3.4 后續(xù)請(qǐng)求的令牌攜帶與登出清理用戶登錄成功后拿到 JWT 令牌前端 axios 攔截器統(tǒng)一在請(qǐng)求頭里加Authorization: Bearer token。這里有一個(gè)細(xì)節(jié)JWT 本身不是加密的它的 payload 部分 Base64 解碼之后任何人有能看到里面的內(nèi)容所以不要把敏感信息放到 JWT 里。我只放 userId 和 username 這類非敏感標(biāo)識(shí)信息角色權(quán)限信息也從用戶表里現(xiàn)查不放 JWT。service.interceptors.request.use( config { const token getToken() if (token) { config.headers[Authorization] Bearer token } return config }, error Promise.reject(error) )響應(yīng)攔截器對(duì) 401 狀態(tài)碼做統(tǒng)一處理跳轉(zhuǎn)到登錄頁并清理本地 token。這樣即使令牌過期用戶只需要重新登錄前端不用在每個(gè)頁面里單獨(dú)寫判斷。4. 聯(lián)調(diào)踩坑與問題排查實(shí)錄4.1 高頻報(bào)錯(cuò)對(duì)照表這套方案在實(shí)際聯(lián)調(diào)階段問題比我預(yù)想的多。下面這些是我總結(jié)的高頻報(bào)錯(cuò)和對(duì)應(yīng)的排查思路。現(xiàn)象原因解決方案后端報(bào)BadPaddingException密文被截?cái)嗷蚯岸思用芎髠鬟f給后端時(shí)被 URL 編碼/換行符破壞確認(rèn)前端傳遞的是 Base64 完整字符串檢查 JSON 序列化是否正常換行后端報(bào)InvalidKeySpecException密鑰字符串格式不對(duì)或使用了錯(cuò)誤的 KeySpec 解析類公鑰用X509EncodedKeySpec私鑰用PKCS8EncodedKeySpec解密出來是亂碼加密前字符串的編碼問題前端 UTF-8 后端也必須是 UTF-8兩端統(tǒng)一使用UTF-8前端 JSEncrypt 報(bào)unreachable code或返回 false公鑰字符串拷貝時(shí)帶了空格或換行去掉所有空白字符確保公鑰是純凈 Base64 串用戶反饋偶爾登錄失敗刷新后好了服務(wù)端重啟導(dǎo)致密鑰對(duì)變化前端緩存了舊公鑰在獲取公鑰接口返回中加入密鑰版本號(hào)前端發(fā)現(xiàn)版本變化就刷新緩存密文長度非常長接口返回 400數(shù)據(jù)超過容器請(qǐng)求體限制檢查 Nginxclient_max_body_size配置適當(dāng)調(diào)大4.2 一個(gè)印象深刻的排查過程有一件事印象特別深刻。內(nèi)部測(cè)試時(shí)同一個(gè)登錄接口在 Chrome 上正常在微信內(nèi)置瀏覽器里偶爾會(huì)報(bào)“密碼解密失敗”。查了很久忽然想到是微信瀏覽器的 URL 編碼問題。微信瀏覽器對(duì)某些特殊字符會(huì)進(jìn)行重新編碼RSA 密文里含有、/、這些字符在傳輸過程中可能被轉(zhuǎn)成空格導(dǎo)致后端 Base64 解碼后的數(shù)據(jù)不完整。解決方案有兩個(gè)一個(gè)是在前端加密后對(duì)密文做encodeURIComponent處理后端拿到后先URLDecoder.decode再 Base64 解碼另一個(gè)是把 Base64 字符串里的/替換成 URL 安全的字符集即 Base64 URL 變體。我采用的是簡單的前端encodeURIComponent 后端解碼的方案改動(dòng)量小兼容性也夠好。4.3 容易被忽視的安全加固項(xiàng)RSA 傳輸加密不是終點(diǎn)它是整個(gè)登錄安全鏈路里的一環(huán)。有幾個(gè)地方容易被忽略我列一下第一獲取公鑰的接口必須做防刷限流。因?yàn)楣€是公開的攻擊者可以無限次請(qǐng)求這個(gè)接口雖然沒有直接危害但可以發(fā)起大量請(qǐng)求消耗服務(wù)端資源。我用了一個(gè)簡單的計(jì)數(shù)限流比如 5 秒內(nèi)超過 100 次請(qǐng)求就拒絕服務(wù)。第二登錄接口必須配合圖形驗(yàn)證碼。RSA 加密擋住了密碼明文泄露但擋不住惡意攻擊者用自動(dòng)化腳本拿密碼字典暴力撞庫。驗(yàn)證碼或者滑塊驗(yàn)證是必要的。我建議驗(yàn)證碼接口放在獲取公鑰接口之后、登錄接口之前獨(dú)立存在不要和登錄邏輯耦合。第三RSA 密鑰必須妥善管理。開發(fā)環(huán)境下密鑰可以放在內(nèi)存里但生產(chǎn)環(huán)境建議配合配置中心和密鑰管理服務(wù)去管理私鑰至少不要把私鑰寫成常量放在代碼倉庫里。私鑰泄露等于安全性歸零這一點(diǎn)再怎么強(qiáng)調(diào)都不為過。第四整個(gè)登錄認(rèn)證鏈路建議配合 HTTPS。RSA 加密解決的是密碼字段的保護(hù)但頁面參數(shù)、JWT 令牌如果走明文 HTTP 傳輸依然可以被竊取。HTTPS 提供的是傳輸層的端到端加密RSA 提供的是應(yīng)用層字段加密兩層疊加才能互相補(bǔ)充。關(guān)于這套方案后續(xù)的擴(kuò)展方向我現(xiàn)在維護(hù)的項(xiàng)目里已經(jīng)把同樣的 RSA 加密機(jī)制用在了修改密碼、綁定手機(jī)號(hào)、重置密碼等所有涉及敏感信息提交的場(chǎng)景。實(shí)際做下來前后端只需要復(fù)用已有的工具類和接口約定擴(kuò)展成本很低。最后再分享一個(gè)小技巧建議把公鑰獲取接口和登錄接口的響應(yīng)都加上Cache-Control: no-store頭。瀏覽器默認(rèn)情況下對(duì) GET 請(qǐng)求可能做緩存如果公鑰被緩存在 CDN 中間層后端更新密鑰后前端拿到的還是舊公鑰排查起來會(huì)非常痛苦。踩過幾次坑之后我對(duì)這套方案的總結(jié)就是非對(duì)稱加密本身并不復(fù)雜復(fù)雜的是把它放在真實(shí)業(yè)務(wù)環(huán)境里考慮緩存、編碼、兼容性、限流這些工程問題。只要把這些問題都處理干凈RSA 用戶身份認(rèn)證加密機(jī)制就是一套真正經(jīng)得起安全評(píng)審和生產(chǎn)考驗(yàn)的登錄方案。