User:Bluedeck/haystack/committed-identity-protocal
主題：
- 由統一頁面存放所有用戶的committed identity。
細節：
- 此頁面就設置在WP:身份驗證中。用户需要将自己放在用户页面的身份验证散列值移动至此，并视其为唯一有效的值。
- 提交人需使用SHA-256、SHA-512或者其他社群認可的算法（請謹慎認可新算法）將一串保密訊息計算散列值并提交在此頁面。
- 提交人必須同時聲明散列值原像長度信息。長度不足128比特者，應視爲不能驗證身份。
- 有朝一日，提交人失去對自身賬戶的訪問時，可以使用新賬戶宣佈其原像，如果計算后結果和WP:身份驗證頁面的值一致，則認爲該新用戶是原用戶的實際持有人，原用戶將作廢處理（或者交給基金會找回密碼，看情況，可討論）。
- 如果要更新自己在WP:身份驗證的注冊值，必須提供上一個散列的解，才能作廢舊散列。
- 一段時間以後沒有在WP:身份驗證注冊的用戶，自動獲得狀態“不驗證”。這些用戶將不能將自己添加進WP:身份驗證中。
Q 此頁面就設置在WP:身份驗證中。用户需要将自己放在用户页面的身份验证散列值移动至此，并视其为唯一有效的值。
A 在用戶頁的申明很容易被否認。假如用戶S忽然在聲明其丟失了原像，需要更新散列，我們是否應該相信？還是將其視爲成功竊取了S賬號的敵手？由於聲明地點爲用戶頁面，隨意性太强，可移動可刪除，所以很難確認身份。至於究竟是WP:身份驗證还是别的什么，这个并不重要，是個頁面就行。此外，该页面应当适用于“预防性全保护”的保护层级。
Q 提交人需使用SHA-256、SHA-512或者其他社群認可的算法（請謹慎認可新算法）將一串保密訊息計算散列值并提交在此頁面。
A 算法必須可靠，至於有多可靠，需要看執行者的標準。個人認爲SHA-2全系列可用，SHA-1、SHA-1以下、SHA-3、非SHA族散列算法不應信任。不贊成任何其他算法。不過最終算法的決定，仍可討論。
Q 提交人必須同時聲明散列值原像長度信息。長度不足128字節者，應視爲不能驗證身份。
A 如果接受這種散列作爲身份認證，等於直接公開使用者密碼。同時長度這一訊息將極大提高原像攻擊的難度。例：1024位的原像可以有效的將散列實際安全位全部利用。當該原像被驗證時，其長度應該等於當初公佈的長度。
Q 有朝一日，提交人失去對自身賬戶的訪問時，可以使用新賬戶宣佈其原像，... ... ... ...
A 即使當前賬戶持有人反對，也應認爲：誰提供了原像，誰就是賬戶持有者，進而剝奪當前賬戶操作者權限。假設敵手取得T的賬號并開始濫用，該敵手將聲明，“不會有錯的我就是T”。雙方皆如此聲明，此時衹能相信數學。
Q 如果要更新自己在WP:身份驗證的注冊值，必須提供上一個散列的解，才能作廢舊散列。
A 如此才能防止敵手直接宣佈舊散列作廢。
Q 一段時間以後沒有在WP:身份驗證注冊的用戶，自動獲得狀態“不驗證”。這些用戶將不能將自己添加進WP:身份驗證中。
A 如果有人不想使用這個驗證方法，則不應逼迫其使用。但是，可能會發生敵手攻破該賬號，并宣佈使用散列驗證身份的做法。這樣最終驗證的是敵手的身份。爲防止這一點，所有人接有權聲稱，“永遠不會使用這一身份驗證方法”。對於過期不聲明的人，應默認其永不使用散列進行身份驗證，以免錯將敵手驗證。
Q 如果使用者真的丟失了原像，需要更新散列值怎麽辦？
A 丟失散列原像不是密碼學能解決的問題。凡是聲明了身份驗證的用戶應當視原像比密碼更重要。果真丟失的情況，至少應當使用郵件、即時通訊軟件、實地確認、用戶查核等方式多個途徑才可承認其身份。
风险提示：
- 所有选择启用散列身份验证的用户应该知道，散列原像是用于证明账户所有权的，而且比账户密码的可信度更高。如此，绝不应该暴露散列原像。设想下述场景：如果用户的散列原像被敌手知悉，敌手可以谎称是用户本人，且当前用户的操作者（真的是本人的人）盗窃了账号。敌手抢先公布散列原像的行为将使得敌手被认定为账户真正持有者，而用户将被视为敌手，并被剥夺访问。
- 维基百科登录页面提供图片验证码用于预防穷举破解。散列验证不提供这一额外的障碍。敌手可以使用超级计算机尝试所有可能的原像。故此，原像的真实复杂度（有效随机位）应该大于等于128位。这是NIST和大部分人公认的的最低建议。出于安全的角度考虑，可以认为随机在键盘上敲一个数字字母，提供4个随机位（根据Bluedeck敲的样本算得，每字符5比特，安全边际为25%左右。你的敲击习惯可能不同，因此只建议多敲，不建议少敲），因此若要使用胡乱敲击键盘生成原像，应当建议至少敲击32个字符。