安全專家 Scott Helme 發表文章反駁近期在 Hacker News 上流傳的「通行密鑰是陷阱，請不要使用它們」一文。該原文建議非技術用戶停用通行密鑰，改回使用 TOTP 代碼和密碼，理由是擔心網站會透過 attestation（認證聲明）機制，逐步限制用戶只能使用經核准的軟體與作業系統登入，從而剝奪用戶的自由（如無法使用 LineageOS 或共享 Netflix 密碼）。
Helme 指出，原文的核心論點與實際技術運作不符。首先，大多數用戶使用的同步通行密鑰（儲存在 iCloud Keychain、Google Password Manager、1Password 或 Bitwarden 等軟體中）根本不會提供 attestation 聲明，網站若要求，收到的回應為 'none'。若消費級網站強制要求 attestation，將立即鎖定幾乎所有用戶，且業界指引多年來一直建議消費級網站不要請求 attestation。
其次，Helme 澄清 attestation 的定義。WebAuthn 的 attestation 僅透過 AAGUID 揭示驗證器的製造商和型號，並附有供應商憑證鏈，它不會透露作業系統、瀏覽器、擴充功能、手機是否 Root/Jailbreak、韌體版本等資訊。原文建議使用 YubiKey 硬體安全金鑰以「避免全系統 attestation」是矛盾的，因為 YubiKey 恰恰是會提供 attestation 的驗證器，企業 attestation 機制正是為了讓組織能強制要求經核准的硬體金鑰。
關於安全性，Helme 指出 TOTP 雖然比純密碼好，但容易受到釣魚攻擊（如 Evilginx 等釣魚套件可即時轉發代碼並竊取會話），這是目前帳戶被接管的主要原因之一。相反，通行密鑰綁定於建立時的網域，瀏覽器不會在錯誤的網域（如 examp1e.com）使用 example.com 的通行密鑰，從而有效防止中間人攻擊。原文作者在附錄中也承認通行密鑰具有網域綁定特性並能抵抗中間人攻擊，但仍建議讀者避免使用，Helme 認為這是將抗釣魚憑證換成易受釣魚攻擊憑證的糟糕交易。
Helme 建議用戶繼續使用通行密鑰，並將其儲存在信任的密碼/通行密鑰管理器中。若擔心 attestation 未來可能滲透到消費級登入，應大聲反對，但目前這並未發生，且迴避通行密鑰只會讓用戶暴露在釣魚攻擊風險中。
事件背景
WebAuthn 標準中的 attestation 機制允許依賴方（網站）驗證驗證器（authenticator）的真實性。當存在時，它透過 AAGUID 標識驗證器的製造商和型號，並提供供應商簽發的憑證鏈作為後盾。企業 attestation 機制允許組織強制要求使用經核准的硬體金鑰。TOTP（基於時間的一次性密碼）是一種雙因素驗證方法，用戶需將代碼手動輸入網站，這使其容易受到中間人攻擊（如 Evilginx 等釣魚套件），攻擊者可即時轉發用戶的密碼和代碼到真實網站，並竊取會話。通行密鑰（Passkeys）基於 WebAuthn 標準，在密碼學上綁定於特定網域，瀏覽器不會在不匹配的網域上使用該憑證，從而提供抗釣魚保護。
社群觀察
評論區討論集中在用戶體驗的碎片化和對未來政策變化的擔憂。用戶 bonzog 指出，通行密鑰在不同設備和平台（Google、Samsung、iCloud、Windows）間的儲存和管理令人困惑，跨設備認證可能存在問題。用戶 coaksford 認為，原文的擔憂並非 attestation 本身，而是未來可能因 attestation 而帶來的限制（「轉大限制旋鈕」），並認為 Helme 的反駁未能完全解決這種對未來自由受限的擔憂。用戶 NoidFonsense 認為，雖然目前通行密鑰不要求硬體和 OS attestation，但技術很容易被擴展以強制要求這些條件，並舉例銀行已開始這樣做，認為這是技術發展的必然趨勢。用戶 PaulHoule 則對「信任的密碼管理器」提出質疑，指出企業環境中的密碼管理器曾發生被駭客攻擊的事件，用戶對將所有憑證託付給單一服務感到不安。用戶 Vexs 對 Helme 關於 attestation 僅揭示驗證器型號而不揭示 OS 細節的說法提出疑問，認為這與原文描述的「驗證器是什麼」與「驗證器能做什麼」之間的區別有關。
