Hi everyone 
，
我正在為我的 Chrome Extension 和 n8n 工作流程開發本地安全設置，在建置下一個版本和撰寫下一篇教程之前，我想獲得一些反饋。
這是當前的參考文章：
最近，我在閱讀 IBM 關於密碼敏捷性的文章：
Crypto-agility and quantum-safe readiness | IBM Quantum Computing Blog
這讓我想到了一個簡單的問題：
我如何才能讓我目前的安全設置更容易在以後進行演進，而不至於變成過度設計的企業級密碼系統？
我目前的設置
我的項目故意保持簡單：
• 一個 Chrome Extension
• 一個原生訊息主機
• 一個本地 n8n 工作流程
• 基於 HMAC 的請求驗證
• 使用時間戳記／nonce 的重放保護
• 本地信任邊界
• Extension 中沒有暴露的密鑰
所以這不是一個多工作流程平台。它只是一個本地安全流程。
我為什麼考慮密碼敏捷性
我對密碼敏捷性的理解不是「為了改變而改變算法」。
對我來說，它意味著：
• 更容易在以後更新密碼選擇，
• 避免在各處進行硬編碼的驗證邏輯，
• 保持未來遷移選項開放，
• 能夠改變密鑰或密碼詳情而無需重寫整個工作流程。
對於小型本地項目，我認為不必要完全的密碼敏捷性。
我考慮的是輕量級密碼敏捷性。
我所說的「輕量級密碼敏捷性」是什麼意思
不是完整的企業架構。
不是邊車。
不是密碼閘道。
不是多個算法提供者。
只是一個小改進，使目前的設置以後更容易維護。
這意味著：
• 在一個地方保持驗證
• 將密鑰保留在程式碼之外
• 選擇性地稍後添加 kid 或版本欄位
• 使未來的更改更容易
• 避免重複的密碼邏輯
這對於小企業或本地項目來說似乎是一個很好的平衡：一個有用的升級，但仍然很簡單。
我提議的 v2.0 方向
當前流程
輕量級密碼敏捷性流程
目標不是創造額外的複雜性。
目標是使安全層更乾淨，更容易在以後進行演進。
我想要反饋的內容
我的主要問題是：
對於本地一個 extension／一個工作流程的設置，輕量級密碼敏捷性有意義嗎，還是已經太多了？
我認為值得這樣做是因為：
• 它提供了一個小但真實的改進，
• 它保持了架構的可維護性，
• 它避免了過度設計。
但在我建置 v2.0 之前，我想聽聽別人的想法。
這對於本地安全設置來說感覺像是正確的平衡嗎？