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

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

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

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

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

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

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

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

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

登錄時的"零知識"挑戰(zhàn)：服務(wù)器連完整哈希都沒見過

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

服務(wù)器數(shù)據(jù)庫里存的是這樣的結(jié)構(gòu)：

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

沒有郵箱。沒有密碼。沒有姓名。沒有任何能關(guān)聯(lián)到真實個人的信息。

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

為什么這套方案現(xiàn)在才有人認真寫教程

技術(shù)棧其實成熟。BIP-39是2013年的標準，Ed25519是2011年發(fā)布的曲線，@noble/ed25519和@scure/bip39都是經(jīng)過審計的純JavaScript實現(xiàn)。

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

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

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

一個細節(jié)值得玩味：登錄挑戰(zhàn)的3個單詞位置是隨機選的，但用戶每次輸入的哈希值固定。這意味著如果某次登錄被中間人截獲哈希，理論上可重放。更嚴謹?shù)膶崿F(xiàn)應(yīng)該加入時間戳或隨機數(shù)做鹽。

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

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