帳號資料庫不能成為密碼神諭

主張：帳號資料列不能協助解鎖保管箱

雲端帳號資料庫有其用途。它能告訴服務哪個公開身份擁有帳號、帳號是否已停用，以及訂閱是否允許使用付費功能。它也能在不取得私密簽署金鑰的情況下，協助驗證已簽署的請求。

但它不能告訴服務——或竊取資料庫副本的人——如何測試某個人的主密碼猜測。

這正是 NT² 為 Cloudflare D1 帳號資料表設定的界線：資料表保存服務身份與使用權限事實，但不保存任何用來解鎖保管箱、驗證主密碼，或在沒有使用者參與下啟動還原的材料。

這項區分很重要，因為資料庫不需要直接包含主密碼，也可能成為密碼神諭。鹽值不是密碼，驗證資料不是密碼，加密的還原套件也未必是密碼。然而，只要這些片段能組合起來回答「這次猜測是否正確」，它們就構成一套密碼測試系統。

當每個資料欄單獨看起來都無害時，這項風險尤其容易被忽略。一個欄位協助新裝置找到金鑰派生設定；另一個讓 API 拒絕錯誤密碼；還有一個讓客服還原更方便。沒有任何欄位直接叫做「密碼」，但它們合在一起，可能已經讓攻擊者能夠私下持續猜測，不必再次呼叫真正的服務。

我們不希望帳號資料庫遭入侵，同時就代表密碼邊界遭到突破。因此，雲端帳號資料表是圍繞一項「不具備的能力」來設計：它無法協助開啟保管箱。

限制：便利的還原資料欄會變成離線神諭

線上密碼檢查可以採取一些離線檢查無法使用的防禦。服務可以限制請求速率、偵測異常流量、延遲重複失敗、封鎖濫用網路、提醒帳號擁有者，並留下稽核紀錄。這些控制並不完美，但防守方仍位於迴圈之中。

攻擊者一旦複製到可驗證密碼的材料組合，就能把防守方移出迴圈。

攻擊者可以取一組候選密碼，以對應鹽值執行指定的金鑰派生函式，再用結果嘗試驗證已知資料或還原物件。驗證成功就代表猜對了；失敗則換下一組。整個迴圈在攻擊者的硬體上、以攻擊者決定的速度執行，不會再向 NT² 發出任何請求。

刻意提高成本的金鑰派生函式，能增加每次嘗試所需的運算量。獨立鹽值則能防止一份預先計算表套用到每個帳號。兩者都是必要的防護，卻都不會把弱密碼變成強密碼；相關值被複製後，也都無法恢復伺服器端的速率限制。

因此，集中保存「非機密」解鎖輔助材料，會改變整套威脅模型。鹽值在設計上可以公開，但把大量鹽值與可靠的密碼驗證資料集中放在一起，對攻擊者便具有實際價值。若再加入還原啟動材料，同一份資料庫甚至可能揭露猜測成功後，該如何重建或取得下一個步驟。

過去的帳號 schema 很容易逐漸累積這類材料，理由通常也都可以理解：

• 讓新裝置的初次設定看起來全自動；
• 讓客服確認使用者是否記得正確密碼；
• 提供大家熟悉的「忘記密碼」流程；
• 在所有本機副本消失後，仍保留還原能力；
• 讓帳號資料庫同時成為雲端身份與本機解鎖的權威來源。

這些便利並不是毫無代價的中繼資料。它們會讓服務供應者成為解鎖設計的一部分。

把這些欄位稱為「託管」、「啟動材料」或「驗證中繼資料」，不會減少它們實際具備的能力。資料集能回答什麼問題，才決定它的安全性質。如果資料庫匯出檔能回答某次主密碼猜測是否正確，它就是離線密碼神諭。如果不需要使用者持有的因子或裝置，就能推進還原，它就是還原權威。

NT² 過去曾考慮在雲端帳號端保存更多便利材料。我們已移除那些能讓人離線測試密碼，或從帳號資料庫開始重建還原流程的資料欄。這不是外觀上的清理，而是實際減少遭竊 D1 快照可以被拿來做什麼。

剩下的資料庫依然敏感。公開金鑰、帳號狀態、帳務事實、時間戳記與請求中繼資料，都需要存取控制、監控、保留限制與謹慎維運。「不是密碼神諭」不等於「不值得保護」，而是即使資料庫邊界失守，其中仍少了一項格外危險的能力。

設計：D1 綁定公開身份，解鎖留在本機

NT² 只交給邊緣服務一項更窄的工作。

雲端帳號綁定至保管箱金鑰 DID，也就是與保管箱簽署金鑰關聯的公開密碼學身份。身份驗證時，邊緣服務會傳送全新的挑戰；裝置以私密金鑰簽署挑戰，邊緣服務再使用已註冊的公開材料驗證簽章。

因此，D1 可以保存這段關係所需的事實：

• 用來識別雲端帳號的保管箱金鑰 DID；
• 公開簽署與金鑰協議材料；
• 帳號是否已停用；
• NT² Premium 使用權限與帳務狀態；
• 帳號營運所需的時間戳記與有限服務中繼資料。

這些事實讓服務可以回答一項遠端授權問題：「這個請求方是否控制已為此帳號註冊的密碼學身份？」

它們無法回答本機解鎖問題：「這是否為使用者的主密碼，而且能否開啟保管箱？」

兩個問題使用不同材料，因為它們授予的能力不同。有效的挑戰簽章可以授權傳輸加密 replica 資料，卻不會派生保管箱的本機加密金鑰。付費訂閱可以允許同步，卻不會讓密文變得可讀。帳務 email 可以接收收據，卻不會變成根身份或解鎖因子。

密碼端的材料留在本機保管箱設定檔。裝置把 KDF 鹽值與密碼驗證資料，和它們要解鎖的保管箱放在一起。使用者輸入主密碼後，裝置在本機執行派生，並用候選金鑰檢查本機已驗證密文。邊緣服務不接收密碼、不回傳鹽值、不檢查驗證資料，也不宣布猜測是否正確。

本機驗證資料的價值，正是它能讓應用程式得到明確結果。裝置可以先區分可用的密碼派生金鑰與錯誤金鑰，再嘗試開啟保管箱其他部分。然而，可驗證密碼的材料一旦集中保存就很危險。放在單一使用者的本機加密保管箱旁，是合理機制；複製進每位使用者的帳號資料表後，卻會成為高價值的猜測目標。

因此，儲存位置本身也表達了權限。使用者已經持有該保管箱副本，所以本機設定檔具有嘗試本機解鎖所需的資訊。帳號服務必須授權網路請求，所以它具有驗證雲端身份所需的公開資訊。雙方都不會只因為把所有東西塞進同一個資料庫比較方便，就取得額外材料。

這也讓註冊維持誠實。註冊雲端功能，代表綁定公開身份並記錄服務狀態，不代表把一套解鎖工具寄放在雲端。邊緣服務之後能再次辨識保管箱，卻不會因此知道主密碼如何保護它。

對加密同步而言，這項分離也符合更大的中繼設計。雲端可以驗證保管箱身份、檢查使用權限、接收不透明 replica frame，並回傳加密更新。完成這些工作，完全不需要本機密碼路徑。身份綁定回答誰可以搬運密文；本機解鎖回答誰可以解讀密文。

取捨：客服無法憑空製造存取權

這條界線最有力的證據，就是 NT² 無法做什麼。

客服不能查看帳號資料列、驗證主密碼，再解鎖使用者的保管箱。客服不能寄出一封神奇的 email，就改掉保護本機密文的密碼。如果所有裝置、備份與還原因子都已遺失，客服也無法從 D1 重建缺少的解鎖狀態。

這確實失去了一項便利。大家早已習慣線上帳號在完成足夠的身份檢查後，由客服恢復存取權。對伺服器擁有的資料而言，服務供應者原本就控制權威副本，也能選擇新的帳號憑證。本機加密保管箱則不同：修改帳號紀錄，不會重建一把伺服器從未持有的金鑰。

產品必須改以實際方式，協助使用者延續自己控制的存取權。備份必須容易理解且可攜；裝置交接必須明確；還原因子必須在急需之前就清楚呈現；遺失最後一份可用副本的警告，也不能被淡化成籠統的帳號用語。

客服對話中也應清楚呈現這項區分。客服可以協助診斷帳號狀態、訂閱使用權限、身份驗證錯誤、傳輸失敗，以及加密物件是否已到達服務；也可以說明使用者先前已建立的還原路徑。但客服不能跨越密碼學界線，拿帳務紀錄或身份文件換出解鎖能力。

在最糟糕的時刻，這可能令人挫折。但它仍比一邊宣稱零知識、一邊保留能開啟保管箱的服務供應者還原路徑更誠實。

這筆交換很具體：使用者承擔維護可用還原路徑的責任，服務供應者則放棄日後替使用者建立這條路徑的能力。少了這項能力，也讓所有帳號避開同一種集中式失敗模式。

我們拒絕什麼

我們不會把 KDF 鹽值與密碼驗證資料存進 D1。兩者都不是主密碼，但搭配派生設定後，就能支援離線測試。讓它們離開帳號資料表，可以避免單一資料庫副本變成大量可驗證密碼目標的清冊。

我們不會保存能讓帳號服務在缺少使用者持有因子的情況下，啟動保管箱存取流程的還原神諭材料。加密 blob 不代表一定適合集中保存；如果它能在密碼猜測或帳號接管後提供可靠的下一步，它扮演的角色就比名稱更重要。

我們不會用伺服器持有的解鎖輔助材料，打造「忘記密碼」流程。Email、客服案件或雲端工作階段的控制權，或許能證明某些帳號事實，卻不能取代用來開啟本機保管箱資料的密碼學材料。

我們不會透過客服工具，悄悄重新引入這些能力。能驗證主密碼的私有管理端點，仍然是密碼神諭；只有員工能使用的還原服務，仍然是還原權威。限制危險能力的存取權，不如根本不收集建立該能力所需的材料。

我們也不會因為 replica 儲存內容已加密，就宣稱整套系統是盲目的。註冊、帳號儲存、還原、客服與解鎖，全都參與信任界線。如果後端另一部分能組合出測試使用者機密所需的材料，這項服務就不是零知識。

這些拒絕會縮小 NT² 在災難性遺失後能做出的承諾，也會縮小攻擊者入侵雲端帳號資料庫後能獲得的能力。這正是目的。

結語：讓帳號保持有用，也刻意保持不完整

設計良好的帳號資料表，應該對它支援的服務有用。D1 可以綁定保管箱金鑰 DID、驗證公開金鑰身份、執行帳號狀態，並記錄 NT² Premium 使用權限。它可以協助邊緣服務協調盲目傳輸，而不會成為保管箱的可讀副本。

它也應該刻意保持不完整。

缺少 KDF 鹽值、本機驗證資料與還原神諭材料，並不是遺漏的功能。正因為沒有這些東西，帳號資料庫才不會變成主密碼測試機器或隱藏的託管系統。註冊仍然是身份綁定，而不是存入解鎖所需的手段。

若想進一步了解周圍的安全界線，可以閱讀 KDF 鹽值留在你的裝置上、解鎖本機保管箱，不等於登入雲端，以及在邊緣進行盲目 replica 同步。

如果你希望雲端服務能辨識保管箱並替它中繼資料，卻無法取得開啟它的能力，歡迎探索 NT² Vault。