這套登錄方案把12個單詞變成身份，服務器卻永遠不知道你是誰

傳統身份驗證有個死循環：想證明你是你，得先交出能定位到你的信息。郵箱、手機號、密碼——全塞進數據庫，然后等泄露通知。

但加密貨幣錢包早就跑通了另一條路。服務器不存任何能追溯到真人的數據，用戶照樣能證明身份。這篇文章把這套機制拆給你看。

從助記詞到密鑰對：瀏覽器里發生的全部事情

用戶拿到的不是賬號密碼，而是一串12個英文單詞。這叫助記詞（seed phrase），硬件錢包Ledger和Trezor用的同一套標準——BIP-39。

128位隨機熵映射到2048個固定單詞中的12個，每個單詞約11位信息，整串助記詞的安全強度約128位。用@scure/bip39庫生成，零依賴、經過審計。

從這12個單詞，瀏覽器本地派生出一對密鑰。私鑰用HMAC-SHA256處理助記詞種子，加上應用專屬的標簽（比如"your-app-name-ed25519"），確保同一串助記詞在不同應用生成不同密鑰。Ed25519曲線算出32字節公鑰。

公鑰變成用戶在服務器上的匿名身份標識，私鑰和原始助記詞永遠不出瀏覽器。

注冊時服務器只收到：一個隨機生成的用戶ID（如"a1b2c3d4"）、公鑰哈希、以及助記詞中特定位置的單詞哈希。

登錄時的"零知識"挑戰：服務器連完整哈希都沒見過

登錄不索要完整助記詞。服務器隨機挑3個位置，讓用戶提供對應單詞。用戶在瀏覽器里先把這3個單詞哈希，再上傳比對。

服務器數據庫里存的是這樣的結構：

用戶名：隨機字符串
公鑰：8f7a9b2c1d3e4f5a...
助記詞哈希：[位置1的哈希, 位置2的哈希, ...]

沒有郵箱。沒有密碼。沒有姓名。沒有任何能關聯到真實個人的信息。

這套機制的核心假設是：攻擊者就算拖庫，拿到的是一堆無法逆向的哈希和隨機公鑰。用戶側的損失止于"這12個單詞別讓人看見"，而不是"我的手機號又在黑市流通了"。

為什么這套方案現在才有人認真寫教程

技術棧其實成熟。BIP-39是2013年的標準，Ed25519是2011年發布的曲線，@noble/ed25519和@scure/bip39都是經過審計的純JavaScript實現。

但產品化阻力不在技術。用戶教育成本極高——12個單詞丟了就是永久失聯，沒有"忘記密碼"按鈕。企業端更難接受：無法做用戶畫像、無法精準推送、無法配合監管調取實名信息。

加密貨幣錢包能跑通，是因為用戶群體對"自己保管密鑰"有預期，且監管框架對鏈上身份另有定義。普通互聯網產品照搬這套，等于主動放棄大部分商業化手段。

作者提供的代碼示例是概念驗證級別，生產環境還需處理密鑰備份、設備遷移、社交恢復等場景。

一個細節值得玩味：登錄挑戰的3個單詞位置是隨機選的，但用戶每次輸入的哈希值固定。這意味著如果某次登錄被中間人截獲哈希，理論上可重放。更嚴謹的實現應該加入時間戳或隨機數做鹽。

這套方案最誠實的定位，或許是"特定場景的備選"——比如臨時賬號、敏感內容發布、或任何用戶寧愿丟失訪問權也不愿暴露身份的場景。它不會取代微信掃碼登錄，但給了一群人一個真正的選項。

文章結尾沒有總結升華，只有一行代碼注釋："witch collapse practice feed shame open despair creek road again ice least"——這是示例用的12個單詞，按BIP-39標準生成，對應一個真實可計算的密鑰對。你可以把它當成一個開放式問題的起點：如果這就是你的全部數字身份，你會怎么保管它？