前后端分離的項目我做過不少登錄認證這塊也踩過很多坑。早年在某公司做內(nèi)部管理系統(tǒng)時因為登錄接口被同事抓包發(fā)現(xiàn)密碼明文傳輸直接被安全團隊點名整改——那會兒用戶密碼就是明文走HTTP只要在局域網(wǎng)里開個抓包工具賬號密碼就裸奔了。后來我重構了整套認證流程核心方案就是 Spring Boot Vue 基于 RSA 的用戶身份認證加密機制。這篇文章把這套方案的完整設計與實現(xiàn)細節(jié)拆開講清楚從選型、后端實現(xiàn)、前端對接到聯(lián)調(diào)時容易踩的坑全部記錄下來。這個方案解決的核心問題很直接在前后端分離架構下如何保證用戶密碼從瀏覽器發(fā)出時不是明文如何讓后端安全地還原密文并完成認證同時兼顧工程上的可維護性和安全基線。適合正在做登錄模塊、被安全評審要求加密傳輸?shù)拈_發(fā)者參考也適合想理解非對稱加密在真實業(yè)務中怎么落地的朋友。1. 登錄加密方案問題拆解與選型背后的思考1.1 明文密碼傳輸?shù)碾[患到底有多大很多人覺得內(nèi)網(wǎng)系統(tǒng)、后端接口沒暴露公網(wǎng)密碼明文傳輸沒多大問題。這個想法我也有過直到被真實打臉。即使是內(nèi)網(wǎng)環(huán)境只要有人用 Wireshark 抓包或者在公司交換機上做一個鏡像端口所有HTTP請求里的密碼都是可讀的。更別說現(xiàn)在前后端分離的項目通常還會部署到公網(wǎng)或者通過小程序、App 端共用同一套 API。密碼明文傳輸帶來的風險不只是密碼泄露本身而是連鎖反應。大部分人的密碼習慣是多個平臺復用同一個密碼一旦某個系統(tǒng)的密碼被拿到攻擊者會拿這個密碼去嘗試其他平臺。所以即使是一個不起眼的后臺管理系統(tǒng)密碼泄露也可能成為突破口。安全團隊當時給我看的報告里寫得清清楚楚明文密碼屬于高危漏洞整改方式就是傳輸加密。那為什么不用 MD5 加鹽之后再傳給后端嚴格來說這種方式防的是數(shù)據(jù)庫泄露后反向破解但對傳輸過程本身沒有任何保護。MD5 后的值仍然是固定值攻擊者抓包拿到這個值直接重放請求后端根本區(qū)分不了這是原始密碼還是摘要值。也就是說MD5 加鹽解決的是存儲安全不是傳輸安全。傳輸加密需要的是前端用某把密鑰加密后端用對應的密鑰解密。這就引出了密鑰管理的選型問題。1.2 對稱加密與非對稱加密的取舍做傳輸加密最先想到的方案往往是 AES 對稱加密。AES 加解密速度快后端生成一個 AES 密鑰前端拿到這個密鑰對密碼加密后端用同一個密鑰解密。但這里有個致命的問題AES 密鑰怎么安全地交給前端如果通過接口返回密鑰那么抓包的人同樣能拿到這把 AES 密鑰他就能自己解密請求里的密文甚至用這把密鑰偽造請求。你等于把鎖和鑰匙一起交給了對方。有人會說那把密鑰寫死在前端代碼里那更糟前端打包后的JS文件里直接能搜到密鑰字符串這層加密就是心理安慰。非對稱加密 RSA 的思路正好繞開了這個困境。RSA 密鑰對分成公鑰和私鑰公鑰公開沒關系它能加密不能解密私鑰只在后端保存用來解密。前端用后端下發(fā)的公鑰加密密碼就算攻擊者抓到了公鑰和密文沒有私鑰他也還原不出明文密碼。RSA 在這個場景下是最契合的選型。雖然它加解密速度比 AES 慢但登錄時只加密一個密碼字段數(shù)據(jù)量很小性能完全不是瓶頸。而且 RSA 還有 AES 不具備的附加價值后端可以用私鑰對令牌做簽名前端用公鑰驗簽同一套密鑰體系可以服務多種安全場景。所以在登錄認證場景下我直接用 RSA 而不是 AES。注意不要試圖用 RSA 加密整個請求體RSA 有長度限制且性能不占優(yōu)加密密碼、手機號這類短字段最合適。請求體整體加密請考慮 AES RSA 混合方案。1.3 整體認證流程設計這套方案的核心流程如下前端用戶打開登錄頁時先向后端發(fā)起獲取公鑰的請求后端生成 RSA 密鑰對或從緩存取將公鑰的 Base64 字符串返回給前端。前端拿到公鑰后用 JSEncrypt 庫對用戶輸入的密碼進行加密得到一段 RSA 密文然后連同用戶名一起提交到登錄接口。后端登錄接口從請求中取出密文用保存在服務端的 RSA 私鑰解密還原出明文密碼再走原有的用戶名密碼校驗邏輯。校驗通過后后端生成一個認證令牌實際項目中可以用 JWT返回給前端。前端保存令牌后續(xù)請求在請求頭中攜帶這個令牌實現(xiàn)會話保持。流程上看只是多了“獲取公鑰”和“密碼加密”兩個環(huán)節(jié)但安全效果完全不同。密碼在整個傳輸鏈路上都是密文狀態(tài)只有后端私鑰能解密。2. 后端 Spring Boot 核心實現(xiàn)密鑰生成、解密接口與登錄認證2.1 工程結(jié)構與依賴準備我用的技術棧是 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項目結(jié)構上我單獨抽了一個crypto包用來放 RSA 相關代碼和業(yè)務代碼隔離。因為 RSA 工具類將來可能會在多個模塊復用獨立成包方便維護。核心類就三個RsaKeyService負責密鑰生命周期管理、RsaUtils加解密靜態(tài)工具、LoginController登錄接口。2.2 RSA 工具類的關鍵細節(jié)分段加密RSA 工具類是整套方案的基石。這里有一個非常關鍵的細節(jié)RSA 加密對明文長度有限制。使用 1024 位密鑰時最多只能加密 117 字節(jié)使用 2048 位密鑰時最多只能加密 245 字節(jié)。登錄密碼通常只有幾十字節(jié)但為了后續(xù)擴展比如加密手機號、身份證號我統(tǒng)一實現(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; // 解密對應最長支持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)); // 對數(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)); // 對數(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(); } } }幾個容易出錯的地方提醒一下前端加密后的密文是 Base64 字符串后端拿到后必須先 Base64 解碼再交給 RSA 解密。很多人忘記這一步直接拿字符串去解報javax.crypto.BadPaddingException。密鑰字符串存儲的格式是公鑰用X509EncodedKeySpec解析私鑰用PKCS8EncodedKeySpec解析。搞混了會報InvalidKeySpecException。SecureRandom初始化 KeyPairGenerator 是必要的可以避免在某些 JDK 版本下生成弱隨機密鑰。2.3 RsaKeyService 密鑰管理策略密鑰管理這里我做了兩個層面的設計。密鑰對的生成時機服務啟動時生成一次還是每次獲取公鑰接口被調(diào)用時重新生成如果每次請求公鑰都重新生成密鑰對那么上一個公鑰加密的密文后端再用新私鑰解密就會失敗。如果前端同時打開了多個登錄頁拿到不同的公鑰就會出現(xiàn)“明明輸入的密碼沒錯后端卻提示密碼解密失敗”的詭異問題。我采用的方案是應用啟動時生成一次密鑰對緩存在內(nèi)存中。獲取公鑰接口直接返回緩存中的公鑰登錄解密時使用緩存的私鑰。這樣所有前端拿到的都是同一把公鑰后端私鑰自始至終也是同一把。密鑰在內(nèi)存中不會持久化到磁盤應用重啟后密鑰對自然更換安全性也有保障。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); } } }如果追求更強的安全性可以給密鑰對設置一個有效期比如每隔 24 小時重新生成一次并讓前端重新拉取公鑰。但要注意兼容會話中已經(jīng)使用舊公鑰加密的請求實際項目中我建議先做固定密鑰等穩(wěn)定后再考慮輪換。2.4 獲取公鑰接口與登錄接口實現(xiàn)獲取公鑰的接口很簡單就是一個 GET 請求返回當前公鑰字符串。但登錄接口需要注意幾個防御細節(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ù)過多請稍后再試); } String publicKey rsaKeyService.getPublicKey(); String decryptPassword; try { decryptPassword rsaKeyService.decrypt(request.getPassword()); } catch (Exception e) { logger.warn(密碼解密失敗用戶{}, request.getUsername()); return Result.fail(密碼解密失敗請刷新頁面后重試); } // 用戶名同樣建議加密傳輸從密文中解密 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(用戶名或密碼錯誤); } // 登錄成功后簽發(fā) JWT String token jwtUtil.createToken(user.getId(), user.getUsername()); return Result.success(new LoginVO(token, user.getUsername())); } }為什么用戶名也要一起加密因為光加密密碼、用戶名明文傳輸攻擊者雖然拿不到密碼但可以收集系統(tǒng)里的有效用戶名用戶名本身就是一種敏感信息。登錄時把用戶名和密碼一起加密前端可以拼接成username : password再加密后端解密后拆分這樣其實更省事。不過要注意分隔符選擇避免用戶名或密碼中含有的字符沖突。登錄失敗之后返回給前端的提示語無論失敗原因是用戶不存在還是密碼錯誤統(tǒng)一返回“用戶名或密碼錯誤”避免泄露用戶名是否存在。這個屬于安全基線里的細節(jié)但很多人會忽略。2.5 密碼存儲的二次加固RSA 解決的是傳輸過程的問題但密碼到了后端存儲環(huán)節(jié)也不能裸奔。很多老系統(tǒng)用戶表里的密碼就是 MD5 或者 SHA1這種值可以查彩虹表直接還原等于把用戶的明文密碼變相暴露了。我在這個項目里對數(shù)據(jù)庫存儲也做了加固使用了 BCrypt 算法。BCrypt 的顯著特點是每次哈希同一個字符串會得到不同的結(jié)果因為它內(nèi)部自動加入隨機鹽。它還要一個成本因子參數(shù)默認 10可以配置成 12 讓它計算更慢。這個慢其實是故意設計的目的就是拖慢攻擊者的批量破解速度讓暴力破解單個密碼的成本大大增加。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); } }登錄流程在工程上還有一個性能上的坑RA 解密 BCrypt 校驗兩步計算加起來會比純 MD5 校驗慢一些用戶基本感知不到。但要注意如果系統(tǒng)面臨著極高的并發(fā)登錄壓力BCrypt 的慢反而會放大風險攻擊者可以故意發(fā)起海量登錄請求來消耗 CPU。所以限流措施是必須的至少要對登錄接口做一個簡單的并發(fā)限流。3. 前端 Vue 對接加密封裝、登錄調(diào)用與請求攔截3.1 依賴選擇與封裝思路Vue 前端做 RSA 加密我用的是jsencrypt這個庫。它在瀏覽器端的實現(xiàn)很成熟封裝了公鑰加密和私鑰解密的邏輯API 非常簡單幾行代碼就能跑通。Vue2 直接 npm 安裝后引入Vue3 也無縫支持。npm install jsencrypt安裝之后我習慣在src/utils/rsa.js里單獨封裝一個加密工具而不是在頁面組件里直接寫加密邏輯。原因是將來如果有多個頁面都要加密字段比如修改密碼頁、綁定手機頁、支付密碼頁統(tǒng)一封裝后一處修改、處處生效。import JSEncrypt from jsencrypt // 每次用前都要先初始化否則會丟失密鑰 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定義為模塊級常量而不是在函數(shù)內(nèi)部 new 出來的是因為每次 new 都會重新生成內(nèi)部狀態(tài)性能開銷不必要。但要注意在并發(fā)場景如果兩個請求同時使用同一個 encryptor 實例可能互相覆蓋密鑰狀態(tài)。在登錄場景下并發(fā)加密的情況很少這個寫法是安全的。3.2 獲取公鑰并緩存公鑰獲取接口的調(diào)用時機可以在每次登錄前實時拉取也可以在應用啟動時拉取一次緩存進 Vuex 或內(nèi)存變量。我推薦登錄頁面加載時異步獲取一次存到 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 登錄頁面完整實現(xiàn)登錄頁的提交邏輯是先確保公鑰已經(jīng)存在然后把用戶名和密碼拼接后加密再把加密后的字符串按字段名傳給后端。這里我選擇“用戶名和密碼拼接后一起加密”而不是分別加密因為 HSEncrypt 的 RSA 加密每次產(chǎn)生的密文不同分別加密兩個短字符串會多兩次加密開銷而且拼在一起只調(diào)用一次加密出錯的概率更小。template div classlogin-container el-form :modelloginForm submit.preventhandleLogin el-form-item label用戶名 el-input v-modelloginForm.username placeholder請輸入用戶名 / /el-form-item el-form-item label密碼 el-input v-modelloginForm.password typepassword placeholder請輸入密碼 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(請輸入用戶名和密碼) 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 || 登錄失敗請稍后重試) } finally { this.loading false } } }, mounted() { if (!this.publicKey) { this.fetchPublicKey() } } } /script登錄接口層面對應地也需要調(diào)整參數(shù)結(jié)構。前端傳的是encryptedData后端從請求體里取這一個字段就足夠了?？梢宰尯蠖私邮找粋€通用請求對象EncryptedRequestpublic class EncryptedRequest { private String encryptedData; // getter setter 省略 }后端拿到encryptedData后解密得到username:password格式的字符串再按第一個冒號位置拆分成用戶名和密碼。3.4 后續(xù)請求的令牌攜帶與登出清理用戶登錄成功后拿到 JWT 令牌前端 axios 攔截器統(tǒng)一在請求頭里加Authorization: Bearer token。這里有一個細節(jié)JWT 本身不是加密的它的 payload 部分 Base64 解碼之后任何人有能看到里面的內(nèi)容所以不要把敏感信息放到 JWT 里。我只放 userId 和 username 這類非敏感標識信息角色權限信息也從用戶表里現(xiàn)查不放 JWT。service.interceptors.request.use( config { const token getToken() if (token) { config.headers[Authorization] Bearer token } return config }, error Promise.reject(error) )響應攔截器對 401 狀態(tài)碼做統(tǒng)一處理跳轉(zhuǎn)到登錄頁并清理本地 token。這樣即使令牌過期用戶只需要重新登錄前端不用在每個頁面里單獨寫判斷。4. 聯(lián)調(diào)踩坑與問題排查實錄4.1 高頻報錯對照表這套方案在實際聯(lián)調(diào)階段問題比我預想的多。下面這些是我總結(jié)的高頻報錯和對應的排查思路?，F(xiàn)象原因解決方案后端報BadPaddingException密文被截斷或前端加密后傳遞給后端時被 URL 編碼/換行符破壞確認前端傳遞的是 Base64 完整字符串檢查 JSON 序列化是否正常換行后端報InvalidKeySpecException密鑰字符串格式不對或使用了錯誤的 KeySpec 解析類公鑰用X509EncodedKeySpec私鑰用PKCS8EncodedKeySpec解密出來是亂碼加密前字符串的編碼問題前端 UTF-8 后端也必須是 UTF-8兩端統(tǒng)一使用UTF-8前端 JSEncrypt 報unreachable code或返回 false公鑰字符串拷貝時帶了空格或換行去掉所有空白字符確保公鑰是純凈 Base64 串用戶反饋偶爾登錄失敗刷新后好了服務端重啟導致密鑰對變化前端緩存了舊公鑰在獲取公鑰接口返回中加入密鑰版本號前端發(fā)現(xiàn)版本變化就刷新緩存密文長度非常長接口返回 400數(shù)據(jù)超過容器請求體限制檢查 Nginxclient_max_body_size配置適當調(diào)大4.2 一個印象深刻的排查過程有一件事印象特別深刻。內(nèi)部測試時同一個登錄接口在 Chrome 上正常在微信內(nèi)置瀏覽器里偶爾會報“密碼解密失敗”。查了很久忽然想到是微信瀏覽器的 URL 編碼問題。微信瀏覽器對某些特殊字符會進行重新編碼RSA 密文里含有、/、這些字符在傳輸過程中可能被轉(zhuǎn)成空格導致后端 Base64 解碼后的數(shù)據(jù)不完整。解決方案有兩個一個是在前端加密后對密文做encodeURIComponent處理后端拿到后先URLDecoder.decode再 Base64 解碼另一個是把 Base64 字符串里的/替換成 URL 安全的字符集即 Base64 URL 變體。我采用的是簡單的前端encodeURIComponent 后端解碼的方案改動量小兼容性也夠好。4.3 容易被忽視的安全加固項RSA 傳輸加密不是終點它是整個登錄安全鏈路里的一環(huán)。有幾個地方容易被忽略我列一下第一獲取公鑰的接口必須做防刷限流。因為公鑰是公開的攻擊者可以無限次請求這個接口雖然沒有直接危害但可以發(fā)起大量請求消耗服務端資源。我用了一個簡單的計數(shù)限流比如 5 秒內(nèi)超過 100 次請求就拒絕服務。第二登錄接口必須配合圖形驗證碼。RSA 加密擋住了密碼明文泄露但擋不住惡意攻擊者用自動化腳本拿密碼字典暴力撞庫。驗證碼或者滑塊驗證是必要的。我建議驗證碼接口放在獲取公鑰接口之后、登錄接口之前獨立存在不要和登錄邏輯耦合。第三RSA 密鑰必須妥善管理。開發(fā)環(huán)境下密鑰可以放在內(nèi)存里但生產(chǎn)環(huán)境建議配合配置中心和密鑰管理服務去管理私鑰至少不要把私鑰寫成常量放在代碼倉庫里。私鑰泄露等于安全性歸零這一點再怎么強調(diào)都不為過。第四整個登錄認證鏈路建議配合 HTTPS。RSA 加密解決的是密碼字段的保護但頁面參數(shù)、JWT 令牌如果走明文 HTTP 傳輸依然可以被竊取。HTTPS 提供的是傳輸層的端到端加密RSA 提供的是應用層字段加密兩層疊加才能互相補充。關于這套方案后續(xù)的擴展方向我現(xiàn)在維護的項目里已經(jīng)把同樣的 RSA 加密機制用在了修改密碼、綁定手機號、重置密碼等所有涉及敏感信息提交的場景。實際做下來前后端只需要復用已有的工具類和接口約定擴展成本很低。最后再分享一個小技巧建議把公鑰獲取接口和登錄接口的響應都加上Cache-Control: no-store頭。瀏覽器默認情況下對 GET 請求可能做緩存如果公鑰被緩存在 CDN 中間層后端更新密鑰后前端拿到的還是舊公鑰排查起來會非常痛苦。踩過幾次坑之后我對這套方案的總結(jié)就是非對稱加密本身并不復雜復雜的是把它放在真實業(yè)務環(huán)境里考慮緩存、編碼、兼容性、限流這些工程問題。只要把這些問題都處理干凈RSA 用戶身份認證加密機制就是一套真正經(jīng)得起安全評審和生產(chǎn)考驗的登錄方案。 Spring Boot + Vue前后端分離登錄認證：RSA加密機制設計與實踐
前后端分離的項目我做過不少登錄認證這塊也踩過很多坑。早年在某公司做內(nèi)部管理系統(tǒng)時因為登錄接口被同事抓包發(fā)現(xiàn)密碼明文傳輸直接被安全團隊點名整改——那會兒用戶密碼就是明文走HTTP只要在局域網(wǎng)里開個抓包工具賬號密碼就裸奔了。后來我重構了整套認證流程核心方案就是 Spring Boot Vue 基于 RSA 的用戶身份認證加密機制。這篇文章把這套方案的完整設計與實現(xiàn)細節(jié)拆開講清楚從選型、后端實現(xiàn)、前端對接到聯(lián)調(diào)時容易踩的坑全部記錄下來。這個方案解決的核心問題很直接在前后端分離架構下如何保證用戶密碼從瀏覽器發(fā)出時不是明文如何讓后端安全地還原密文并完成認證同時兼顧工程上的可維護性和安全基線。適合正在做登錄模塊、被安全評審要求加密傳輸?shù)拈_發(fā)者參考也適合想理解非對稱加密在真實業(yè)務中怎么落地的朋友。1. 登錄加密方案問題拆解與選型背后的思考1.1 明文密碼傳輸?shù)碾[患到底有多大很多人覺得內(nèi)網(wǎng)系統(tǒng)、后端接口沒暴露公網(wǎng)密碼明文傳輸沒多大問題。這個想法我也有過直到被真實打臉。即使是內(nèi)網(wǎng)環(huán)境只要有人用 Wireshark 抓包或者在公司交換機上做一個鏡像端口所有HTTP請求里的密碼都是可讀的。更別說現(xiàn)在前后端分離的項目通常還會部署到公網(wǎng)或者通過小程序、App 端共用同一套 API。密碼明文傳輸帶來的風險不只是密碼泄露本身而是連鎖反應。大部分人的密碼習慣是多個平臺復用同一個密碼一旦某個系統(tǒng)的密碼被拿到攻擊者會拿這個密碼去嘗試其他平臺。所以即使是一個不起眼的后臺管理系統(tǒng)密碼泄露也可能成為突破口。安全團隊當時給我看的報告里寫得清清楚楚明文密碼屬于高危漏洞整改方式就是傳輸加密。那為什么不用 MD5 加鹽之后再傳給后端嚴格來說這種方式防的是數(shù)據(jù)庫泄露后反向破解但對傳輸過程本身沒有任何保護。MD5 后的值仍然是固定值攻擊者抓包拿到這個值直接重放請求后端根本區(qū)分不了這是原始密碼還是摘要值。也就是說MD5 加鹽解決的是存儲安全不是傳輸安全。傳輸加密需要的是前端用某把密鑰加密后端用對應的密鑰解密。這就引出了密鑰管理的選型問題。1.2 對稱加密與非對稱加密的取舍做傳輸加密最先想到的方案往往是 AES 對稱加密。AES 加解密速度快后端生成一個 AES 密鑰前端拿到這個密鑰對密碼加密后端用同一個密鑰解密。但這里有個致命的問題AES 密鑰怎么安全地交給前端如果通過接口返回密鑰那么抓包的人同樣能拿到這把 AES 密鑰他就能自己解密請求里的密文甚至用這把密鑰偽造請求。你等于把鎖和鑰匙一起交給了對方。有人會說那把密鑰寫死在前端代碼里那更糟前端打包后的JS文件里直接能搜到密鑰字符串這層加密就是心理安慰。非對稱加密 RSA 的思路正好繞開了這個困境。RSA 密鑰對分成公鑰和私鑰公鑰公開沒關系它能加密不能解密私鑰只在后端保存用來解密。前端用后端下發(fā)的公鑰加密密碼就算攻擊者抓到了公鑰和密文沒有私鑰他也還原不出明文密碼。RSA 在這個場景下是最契合的選型。雖然它加解密速度比 AES 慢但登錄時只加密一個密碼字段數(shù)據(jù)量很小性能完全不是瓶頸。而且 RSA 還有 AES 不具備的附加價值后端可以用私鑰對令牌做簽名前端用公鑰驗簽同一套密鑰體系可以服務多種安全場景。所以在登錄認證場景下我直接用 RSA 而不是 AES。注意不要試圖用 RSA 加密整個請求體RSA 有長度限制且性能不占優(yōu)加密密碼、手機號這類短字段最合適。請求體整體加密請考慮 AES RSA 混合方案。1.3 整體認證流程設計這套方案的核心流程如下前端用戶打開登錄頁時先向后端發(fā)起獲取公鑰的請求后端生成 RSA 密鑰對或從緩存取將公鑰的 Base64 字符串返回給前端。前端拿到公鑰后用 JSEncrypt 庫對用戶輸入的密碼進行加密得到一段 RSA 密文然后連同用戶名一起提交到登錄接口。后端登錄接口從請求中取出密文用保存在服務端的 RSA 私鑰解密還原出明文密碼再走原有的用戶名密碼校驗邏輯。校驗通過后后端生成一個認證令牌實際項目中可以用 JWT返回給前端。前端保存令牌后續(xù)請求在請求頭中攜帶這個令牌實現(xiàn)會話保持。流程上看只是多了“獲取公鑰”和“密碼加密”兩個環(huán)節(jié)但安全效果完全不同。密碼在整個傳輸鏈路上都是密文狀態(tài)只有后端私鑰能解密。2. 后端 Spring Boot 核心實現(xiàn)密鑰生成、解密接口與登錄認證2.1 工程結(jié)構與依賴準備我用的技術棧是 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項目結(jié)構上我單獨抽了一個crypto包用來放 RSA 相關代碼和業(yè)務代碼隔離。因為 RSA 工具類將來可能會在多個模塊復用獨立成包方便維護。核心類就三個RsaKeyService負責密鑰生命周期管理、RsaUtils加解密靜態(tài)工具、LoginController登錄接口。2.2 RSA 工具類的關鍵細節(jié)分段加密RSA 工具類是整套方案的基石。這里有一個非常關鍵的細節(jié)RSA 加密對明文長度有限制。使用 1024 位密鑰時最多只能加密 117 字節(jié)使用 2048 位密鑰時最多只能加密 245 字節(jié)。登錄密碼通常只有幾十字節(jié)但為了后續(xù)擴展比如加密手機號、身份證號我統(tǒng)一實現(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; // 解密對應最長支持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)); // 對數(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)); // 對數(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(); } } }幾個容易出錯的地方提醒一下前端加密后的密文是 Base64 字符串后端拿到后必須先 Base64 解碼再交給 RSA 解密。很多人忘記這一步直接拿字符串去解報javax.crypto.BadPaddingException。密鑰字符串存儲的格式是公鑰用X509EncodedKeySpec解析私鑰用PKCS8EncodedKeySpec解析。搞混了會報InvalidKeySpecException。SecureRandom初始化 KeyPairGenerator 是必要的可以避免在某些 JDK 版本下生成弱隨機密鑰。2.3 RsaKeyService 密鑰管理策略密鑰管理這里我做了兩個層面的設計。密鑰對的生成時機服務啟動時生成一次還是每次獲取公鑰接口被調(diào)用時重新生成如果每次請求公鑰都重新生成密鑰對那么上一個公鑰加密的密文后端再用新私鑰解密就會失敗。如果前端同時打開了多個登錄頁拿到不同的公鑰就會出現(xiàn)“明明輸入的密碼沒錯后端卻提示密碼解密失敗”的詭異問題。我采用的方案是應用啟動時生成一次密鑰對緩存在內(nèi)存中。獲取公鑰接口直接返回緩存中的公鑰登錄解密時使用緩存的私鑰。這樣所有前端拿到的都是同一把公鑰后端私鑰自始至終也是同一把。密鑰在內(nèi)存中不會持久化到磁盤應用重啟后密鑰對自然更換安全性也有保障。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); } } }如果追求更強的安全性可以給密鑰對設置一個有效期比如每隔 24 小時重新生成一次并讓前端重新拉取公鑰。但要注意兼容會話中已經(jīng)使用舊公鑰加密的請求實際項目中我建議先做固定密鑰等穩(wěn)定后再考慮輪換。2.4 獲取公鑰接口與登錄接口實現(xiàn)獲取公鑰的接口很簡單就是一個 GET 請求返回當前公鑰字符串。但登錄接口需要注意幾個防御細節(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ù)過多請稍后再試); } String publicKey rsaKeyService.getPublicKey(); String decryptPassword; try { decryptPassword rsaKeyService.decrypt(request.getPassword()); } catch (Exception e) { logger.warn(密碼解密失敗用戶{}, request.getUsername()); return Result.fail(密碼解密失敗請刷新頁面后重試); } // 用戶名同樣建議加密傳輸從密文中解密 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(用戶名或密碼錯誤); } // 登錄成功后簽發(fā) JWT String token jwtUtil.createToken(user.getId(), user.getUsername()); return Result.success(new LoginVO(token, user.getUsername())); } }為什么用戶名也要一起加密因為光加密密碼、用戶名明文傳輸攻擊者雖然拿不到密碼但可以收集系統(tǒng)里的有效用戶名用戶名本身就是一種敏感信息。登錄時把用戶名和密碼一起加密前端可以拼接成username : password再加密后端解密后拆分這樣其實更省事。不過要注意分隔符選擇避免用戶名或密碼中含有的字符沖突。登錄失敗之后返回給前端的提示語無論失敗原因是用戶不存在還是密碼錯誤統(tǒng)一返回“用戶名或密碼錯誤”避免泄露用戶名是否存在。這個屬于安全基線里的細節(jié)但很多人會忽略。2.5 密碼存儲的二次加固RSA 解決的是傳輸過程的問題但密碼到了后端存儲環(huán)節(jié)也不能裸奔。很多老系統(tǒng)用戶表里的密碼就是 MD5 或者 SHA1這種值可以查彩虹表直接還原等于把用戶的明文密碼變相暴露了。我在這個項目里對數(shù)據(jù)庫存儲也做了加固使用了 BCrypt 算法。BCrypt 的顯著特點是每次哈希同一個字符串會得到不同的結(jié)果因為它內(nèi)部自動加入隨機鹽。它還要一個成本因子參數(shù)默認 10可以配置成 12 讓它計算更慢。這個慢其實是故意設計的目的就是拖慢攻擊者的批量破解速度讓暴力破解單個密碼的成本大大增加。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); } }登錄流程在工程上還有一個性能上的坑RA 解密 BCrypt 校驗兩步計算加起來會比純 MD5 校驗慢一些用戶基本感知不到。但要注意如果系統(tǒng)面臨著極高的并發(fā)登錄壓力BCrypt 的慢反而會放大風險攻擊者可以故意發(fā)起海量登錄請求來消耗 CPU。所以限流措施是必須的至少要對登錄接口做一個簡單的并發(fā)限流。3. 前端 Vue 對接加密封裝、登錄調(diào)用與請求攔截3.1 依賴選擇與封裝思路Vue 前端做 RSA 加密我用的是jsencrypt這個庫。它在瀏覽器端的實現(xiàn)很成熟封裝了公鑰加密和私鑰解密的邏輯API 非常簡單幾行代碼就能跑通。Vue2 直接 npm 安裝后引入Vue3 也無縫支持。npm install jsencrypt安裝之后我習慣在src/utils/rsa.js里單獨封裝一個加密工具而不是在頁面組件里直接寫加密邏輯。原因是將來如果有多個頁面都要加密字段比如修改密碼頁、綁定手機頁、支付密碼頁統(tǒng)一封裝后一處修改、處處生效。import JSEncrypt from jsencrypt // 每次用前都要先初始化否則會丟失密鑰 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定義為模塊級常量而不是在函數(shù)內(nèi)部 new 出來的是因為每次 new 都會重新生成內(nèi)部狀態(tài)性能開銷不必要。但要注意在并發(fā)場景如果兩個請求同時使用同一個 encryptor 實例可能互相覆蓋密鑰狀態(tài)。在登錄場景下并發(fā)加密的情況很少這個寫法是安全的。3.2 獲取公鑰并緩存公鑰獲取接口的調(diào)用時機可以在每次登錄前實時拉取也可以在應用啟動時拉取一次緩存進 Vuex 或內(nèi)存變量。我推薦登錄頁面加載時異步獲取一次存到 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 登錄頁面完整實現(xiàn)登錄頁的提交邏輯是先確保公鑰已經(jīng)存在然后把用戶名和密碼拼接后加密再把加密后的字符串按字段名傳給后端。這里我選擇“用戶名和密碼拼接后一起加密”而不是分別加密因為 HSEncrypt 的 RSA 加密每次產(chǎn)生的密文不同分別加密兩個短字符串會多兩次加密開銷而且拼在一起只調(diào)用一次加密出錯的概率更小。template div classlogin-container el-form :modelloginForm submit.preventhandleLogin el-form-item label用戶名 el-input v-modelloginForm.username placeholder請輸入用戶名 / /el-form-item el-form-item label密碼 el-input v-modelloginForm.password typepassword placeholder請輸入密碼 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(請輸入用戶名和密碼) 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 || 登錄失敗請稍后重試) } finally { this.loading false } } }, mounted() { if (!this.publicKey) { this.fetchPublicKey() } } } /script登錄接口層面對應地也需要調(diào)整參數(shù)結(jié)構。前端傳的是encryptedData后端從請求體里取這一個字段就足夠了?？梢宰尯蠖私邮找粋€通用請求對象EncryptedRequestpublic class EncryptedRequest { private String encryptedData; // getter setter 省略 }后端拿到encryptedData后解密得到username:password格式的字符串再按第一個冒號位置拆分成用戶名和密碼。3.4 后續(xù)請求的令牌攜帶與登出清理用戶登錄成功后拿到 JWT 令牌前端 axios 攔截器統(tǒng)一在請求頭里加Authorization: Bearer token。這里有一個細節(jié)JWT 本身不是加密的它的 payload 部分 Base64 解碼之后任何人有能看到里面的內(nèi)容所以不要把敏感信息放到 JWT 里。我只放 userId 和 username 這類非敏感標識信息角色權限信息也從用戶表里現(xiàn)查不放 JWT。service.interceptors.request.use( config { const token getToken() if (token) { config.headers[Authorization] Bearer token } return config }, error Promise.reject(error) )響應攔截器對 401 狀態(tài)碼做統(tǒng)一處理跳轉(zhuǎn)到登錄頁并清理本地 token。這樣即使令牌過期用戶只需要重新登錄前端不用在每個頁面里單獨寫判斷。4. 聯(lián)調(diào)踩坑與問題排查實錄4.1 高頻報錯對照表這套方案在實際聯(lián)調(diào)階段問題比我預想的多。下面這些是我總結(jié)的高頻報錯和對應的排查思路?，F(xiàn)象原因解決方案后端報BadPaddingException密文被截斷或前端加密后傳遞給后端時被 URL 編碼/換行符破壞確認前端傳遞的是 Base64 完整字符串檢查 JSON 序列化是否正常換行后端報InvalidKeySpecException密鑰字符串格式不對或使用了錯誤的 KeySpec 解析類公鑰用X509EncodedKeySpec私鑰用PKCS8EncodedKeySpec解密出來是亂碼加密前字符串的編碼問題前端 UTF-8 后端也必須是 UTF-8兩端統(tǒng)一使用UTF-8前端 JSEncrypt 報unreachable code或返回 false公鑰字符串拷貝時帶了空格或換行去掉所有空白字符確保公鑰是純凈 Base64 串用戶反饋偶爾登錄失敗刷新后好了服務端重啟導致密鑰對變化前端緩存了舊公鑰在獲取公鑰接口返回中加入密鑰版本號前端發(fā)現(xiàn)版本變化就刷新緩存密文長度非常長接口返回 400數(shù)據(jù)超過容器請求體限制檢查 Nginxclient_max_body_size配置適當調(diào)大4.2 一個印象深刻的排查過程有一件事印象特別深刻。內(nèi)部測試時同一個登錄接口在 Chrome 上正常在微信內(nèi)置瀏覽器里偶爾會報“密碼解密失敗”。查了很久忽然想到是微信瀏覽器的 URL 編碼問題。微信瀏覽器對某些特殊字符會進行重新編碼RSA 密文里含有、/、這些字符在傳輸過程中可能被轉(zhuǎn)成空格導致后端 Base64 解碼后的數(shù)據(jù)不完整。解決方案有兩個一個是在前端加密后對密文做encodeURIComponent處理后端拿到后先URLDecoder.decode再 Base64 解碼另一個是把 Base64 字符串里的/替換成 URL 安全的字符集即 Base64 URL 變體。我采用的是簡單的前端encodeURIComponent 后端解碼的方案改動量小兼容性也夠好。4.3 容易被忽視的安全加固項RSA 傳輸加密不是終點它是整個登錄安全鏈路里的一環(huán)。有幾個地方容易被忽略我列一下第一獲取公鑰的接口必須做防刷限流。因為公鑰是公開的攻擊者可以無限次請求這個接口雖然沒有直接危害但可以發(fā)起大量請求消耗服務端資源。我用了一個簡單的計數(shù)限流比如 5 秒內(nèi)超過 100 次請求就拒絕服務。第二登錄接口必須配合圖形驗證碼。RSA 加密擋住了密碼明文泄露但擋不住惡意攻擊者用自動化腳本拿密碼字典暴力撞庫。驗證碼或者滑塊驗證是必要的。我建議驗證碼接口放在獲取公鑰接口之后、登錄接口之前獨立存在不要和登錄邏輯耦合。第三RSA 密鑰必須妥善管理。開發(fā)環(huán)境下密鑰可以放在內(nèi)存里但生產(chǎn)環(huán)境建議配合配置中心和密鑰管理服務去管理私鑰至少不要把私鑰寫成常量放在代碼倉庫里。私鑰泄露等于安全性歸零這一點再怎么強調(diào)都不為過。第四整個登錄認證鏈路建議配合 HTTPS。RSA 加密解決的是密碼字段的保護但頁面參數(shù)、JWT 令牌如果走明文 HTTP 傳輸依然可以被竊取。HTTPS 提供的是傳輸層的端到端加密RSA 提供的是應用層字段加密兩層疊加才能互相補充。關于這套方案后續(xù)的擴展方向我現(xiàn)在維護的項目里已經(jīng)把同樣的 RSA 加密機制用在了修改密碼、綁定手機號、重置密碼等所有涉及敏感信息提交的場景。實際做下來前后端只需要復用已有的工具類和接口約定擴展成本很低。最后再分享一個小技巧建議把公鑰獲取接口和登錄接口的響應都加上Cache-Control: no-store頭。瀏覽器默認情況下對 GET 請求可能做緩存如果公鑰被緩存在 CDN 中間層后端更新密鑰后前端拿到的還是舊公鑰排查起來會非常痛苦。踩過幾次坑之后我對這套方案的總結(jié)就是非對稱加密本身并不復雜復雜的是把它放在真實業(yè)務環(huán)境里考慮緩存、編碼、兼容性、限流這些工程問題。只要把這些問題都處理干凈RSA 用戶身份認證加密機制就是一套真正經(jīng)得起安全評審和生產(chǎn)考驗的登錄方案。