前言
公司代表跟我說，希望我能學習一種安全性很高的登入方式——通行密鑰（Passkey）。作為一家重視資安意識的公司，也希望把這些實作經驗對外分享出去。
在那之前，我雖然知道通行密鑰這個東西，卻不清楚它到底是什麼。於是我去研究了它的機制，並在公司內部的 tips 分享會上做了發表。
本文會沿用當時的投影片，來說明通行密鑰的運作方式。你可以了解它和既有登入方式有什麼不同、註冊與登入時到底發生了什麼，以及為什麼它能抵抗釣魚網站。
登入方式速覽表
先直接用表格看整理結果。我從是否能抵抗釣魚、伺服器外洩後會怎樣、使用者的麻煩程度、實作上的麻煩程度這 4 個面向，比較了 6 種登入方式。
上面 5 列是既有方式，最下面的是通行密鑰。通行密鑰比既有方式更強的地方，在於釣魚與外洩這兩欄。相對地，在實作難度那欄，還會剩下一項「要設計復原手段」。原因會在後面的章節依序說明。
美國 NIST 的驗證指南 SP 800-63B-4 也指出，像 TOTP 或 SMS 這種需要手動輸入代碼的方式，不屬於能抵抗釣魚的驗證方式（phishing-resistant）。至於電子郵件，則是連拿來做驗證都不應該。
使用者的負擔，從導入企業的數據也能看得出來。認證業界團體 FIDO Alliance 在 2025 年 10 月公布的「Passkey Index」中，收錄了 Amazon、Google、Microsoft、LINE Yahoo、Mercari、NTT DOCOMO 等 9 家公司的調查結果。
登入成功率方面，通行密鑰為 93%，其他方式則是 63%。單次登入所需時間方面，通行密鑰是 8.5 秒，傳統 MFA 則是 31.2 秒。這些數字都是由參與企業回覆的調查結果，再由 FIDO Alliance 與研究公司 Liminal 彙整而成。
既有方式的弱點
把現有登入方式列出來，大致上就是這 6 種。最常用的是帳號與密碼。常見的加強方式，則是 SMS 傳送的驗證碼，以及驗證 App 顯示的 6 位數代碼（TOTP）。
也有不使用密碼的方式。像是輸入寄到電子郵件的代碼的 Email OTP、只要打開電子郵件中的連結即可的 Magic Link，以及使用 Google 等帳號登入的社群登入。
每種方式都有弱點。密碼的弱點有 3 個：
- 會自己輸入到假網站上
- 會從伺服器外洩。即使做了雜湊，短密碼仍可能被暴力破解還原
- 會被重複使用。一旦某處外洩，使用同樣密碼的其他服務也會被入侵
就算在密碼之外再加上驗證碼，有時還是會被突破。作法是讓假網站即時把使用者輸入的代碼轉送到真正的網站，這種手法稱為即時釣魚（real-time phishing）。
Magic Link 和社群登入雖然沒有密碼，但登入安全性取決於電子郵件或 Google 這類帳號本身的強度。Magic Link 還有一個問題：如果郵件安全產品先把連結打開了，等使用者自己開啟時就可能已經失效。
能對付這些弱點的方式，就是通行密鑰。通行密鑰不是靠使用者小心，而是從機制上防止釣魚、外洩與重複使用。
通行密鑰的機制
用裝置上的金鑰驗證本人
通行密鑰是以裝置中的金鑰取代密碼，來驗證使用者身分的登入方式。
金鑰由一組秘密金鑰與公開金鑰組成。用秘密金鑰產生的簽章，會交由對應的公開金鑰來驗證。投影片中的 3 個重點如下：
- 秘密金鑰不會送到伺服器。簽章是在裝置內部產生的
- 伺服器只會持有公開金鑰。公開金鑰不能拿來產生簽章，所以就算外洩也無法用來登入
- 金鑰是為每個網站各自建立的。無法在其他網站使用，因此不會發生重複使用的問題
指紋或臉部不會送到伺服器
「指紋會註冊到伺服器嗎？」這是很常見的誤解。答案是：不會。
指紋或臉部比對是在裝置內完成的。當裝置確認是本人後，就會允許秘密金鑰使用，並產生簽章。送到伺服器的只有簽章，以及「已完成本人驗證」的旗標。生物辨識資訊不會離開裝置。
註冊與登入流程
接下來以 Mac 上的 Chrome 為例，說明在 Google 帳號上註冊通行密鑰並登入的流程。
參與者有 3 個：裝置、瀏覽器、伺服器。在通行密鑰使用的 Web 標準 WebAuthn 中，伺服器被稱為 Relying Party，簡稱 RP。以下流程參考了 W3C 規格、Google 開發者網站 web.dev 的文章「Create a passkey for passwordless logins」，以及開發者說明網站 passkeys.dev。
先看註冊流程。
- 已登入的使用者按下「註冊通行密鑰」
- 伺服器回傳 challenge（一次性亂數）、RP ID（網站網域，例如 Google 的話就是 google.com）、user.id（每個帳號對應的 ID）
- 瀏覽器呼叫
navigator.credentials.create()。此時瀏覽器會確認目前開啟頁面的 origin 是否與 RP ID 相符 - 使用者選擇通行密鑰的保存位置。若是 Mac 上的 Chrome，可能是 iCloud 鑰匙圈，或已安裝的 1Password 等密碼管理工具
- 裝置透過指紋或臉部完成本人驗證，並建立專屬於此網站的金鑰對。秘密金鑰會留在裝置上
- 裝置回傳公開金鑰與 credential ID 給瀏覽器
- 瀏覽器將公開金鑰、credential ID 與 clientDataJSON 一起送到伺服器。clientDataJSON 是瀏覽器寫入的資料，包含 origin 與 challenge
- 伺服器確認 challenge 與 origin 都是自己送出的內容後，保存公開金鑰
第 4 步的保存位置，會影響之後哪些裝置能同步這組金鑰。不論哪種流程，秘密金鑰都不會離開裝置。
接著看登入流程。形式和註冊幾乎相同。
- 使用者按下登入按鈕
- 伺服器回傳 challenge 與 RP ID。challenge 每次都會改變，因此無法重用前一次的簽章來攻擊
- 瀏覽器呼叫
navigator.credentials.get()。可作為候選的，只有用這個 RP ID 建立的金鑰 - 如果候選項有多個，使用者會選擇要使用哪個帳號的通行密鑰
- 裝置完成本人驗證，並用秘密金鑰對包含 challenge 的資料進行簽章
- 裝置回傳簽章、authenticatorData、credential ID 給瀏覽器。authenticatorData 是裝置寫入的資料，包含 RP ID 的雜湊值，以及是否完成本人驗證的旗標
- 瀏覽器把自己寫入的 clientDataJSON 一起送到伺服器
- 伺服器用 credential ID 找到註冊時保存的公開金鑰，並驗證簽章。同時也會檢查 challenge 與 origin，若都正確，登入就成功
伺服器持有的只有公開金鑰。因此，就算資料庫外洩，也無法拿來登入。
用實例看釣魚網站的差異
把 amazon.com 開頭的 a 改成西里爾字母的 а（U+0430），就會變成一個假網域，這件事曾在 X 上引發討論（Polymarket Japan 的 X 貼文）。和英文字母非常像的西里爾字母不只一個（A2CBoston 的 X 貼文），只靠外觀根本無法分辨。
Chrome 會把混有英文字母與西里爾字母的網域，在網址列中顯示成以 xn-- 開頭的形式（Chromium 文件「IDN in Google Chrome」）。不過，光看電子郵件內文的連結文字，仍然無法辨識。
接下來看看，如果在這個假網站上用通行密鑰登入，會發生什麼事。
左邊是真正的 amazon.com，右邊則是使用西里爾字母 а 的假網站。
在真正的網站上，瀏覽器會把這個網域對應的通行密鑰列為候選，因此可以登入。假網站因為 RP ID 不一致，通行密鑰甚至不會出現在候選清單中。瀏覽器比對的是字元碼，而不是外觀，所以 U+0430 的 а 與 U+0061 的 a 會被視為不同字元。即使使用者被騙了，也不會產生簽章，因此假網站也無法轉送到真正的網站。
密碼的世界裡，是由人眼來分辨真假；通行密鑰則是由瀏覽器機械式地比對網域。這就是通行密鑰與既有方式最大的差異。
可同步與不可同步的通行密鑰
前面介紹的機制，其實在通行密鑰這個名稱出現之前就已經存在了。
- 2013 年：成立產業團體 FIDO Alliance，目標是減少對密碼的依賴（成立於 2012 年）
- 2014 年：發布最初的 FIDO 標準 U2F 與 UAF。U2F 是把安全金鑰當作第二因素使用，UAF 則是利用裝置上的指紋等生物辨識，免密碼登入
- 2019 年：制定 Web 標準的 W3C 將 WebAuthn 正式標準化。從瀏覽器開始，就能不使用密碼，而以秘密金鑰簽章來登入
- 2022 年：Apple、Google、Microsoft 聯合宣布，金鑰可以在裝置之間同步
能抵抗釣魚的機制，在 2019 年時就已經齊備了。只是金鑰無法離開建立它的裝置。換到新裝置時，每個服務都要重新註冊；裝置遺失後，也無法再用那組金鑰登入。即使在企業內部可以透過管理工具處理，對一般使用者來說仍很難普及。
因此在 2022 年，出現了讓金鑰可以在裝置之間同步的宣布。這種可同步的金鑰，開始被稱為通行密鑰。現在則是把不會離開裝置的金鑰也一起稱為通行密鑰。也就是說，機制早就存在，而通行密鑰只是把它變得更好用。知道這個名稱是在 2022 年才出現後，我也覺得通行密鑰其實是相當新的概念。
目前的通行密鑰分成 2 種。
可同步的通行密鑰是指在手機上建立後，會透過 iCloud 鑰匙圈、Google 密碼管理工具或 1Password，同步到同一帳號的其他裝置。上面時間軸中 2022 年的同步指的就是這個。即使裝置遺失，也能用其他裝置登入。
不會離開裝置的通行密鑰，則是在像 YubiKey 這類安全金鑰內建立的金鑰。因為秘密金鑰無法複製到外部，所以更安全；但若遺失，就無法再用那組金鑰登入。伺服器端可以透過驗證器回傳的旗標，辨識是哪一種類型的通行密鑰。
補充：通行密鑰的弱點
通行密鑰最大的弱點，是復原流程。
弄丟手機的本人，會從「無法登入的那一方」去點開寄到電子郵件的復原連結。只要在新裝置上重新建立通行密鑰，就能再次登入。
但如果攻擊者入侵了本人的電子郵件，也能走完全相同的入口。即使通行密鑰本身對釣魚與外洩很強，帳號整體的強度也會下降到復原手段的強度。如果復原是用 SMS，那強度就和 SMS 一樣。
對策有 2 個：
- 請使用者註冊 2 把以上的通行密鑰。即使手機遺失，也能用 PC 上的通行密鑰登入，避免走復原入口
- 復原後通知本人。即使攻擊者完成復原，只要本人裝置或電子郵件收到通知，就能察覺異常
這兩點也寫在 NIST SP 800-63B-4 裡：建議使用者持有 2 種以上的驗證手段（SHOULD），以及在復原後通知本人（SHALL）。
另一個問題是跨作業系統時的情況。在 iPhone 上建立的通行密鑰，會透過 iCloud 鑰匙圈同步到同一個 Apple 帳號的 Mac 或 iPad。不過，在 Windows PC 上，有時不會直接出現在候選清單裡。支援情況會依作業系統與版本而異。
這種情況下，可以用電腦上顯示的 QR Code 讓手機掃描，再用手機上的通行密鑰登入。前提是手機必須在附近。也可以把通行密鑰存到像 1Password 這種跨作業系統的密碼管理工具中。
根據使用者裝置的情況，有時也需要考慮不要只依賴通行密鑰，而是保留其他登入方式。
最後
通行密鑰是一種由裝置中的秘密金鑰簽章，並由伺服器用公開金鑰驗證的登入方式。因為瀏覽器會比對網域，所以在假網站上金鑰不會出現。即使伺服器上的公開金鑰外洩，也無法用來登入。
在被代表提醒之前，我並不知道通行密鑰這個概念。實際查過之後才發現，這套機制其實從 2019 年就已存在，而通行密鑰只是讓它變得更容易使用。
如果你要在自己的服務中加入通行密鑰，建議先想好兩件事：要在哪個畫面引導使用者建立通行密鑰，以及當使用者遺失裝置時，要如何幫他復原。
參考資料
- 規格
- 解說
- 歷史
- FIDO Alliance「Charting an Accelerated Path Forward for Passwordless Authentication Adoption」2022 年 3 月 17 日
- Apple Newsroom「Apple, Google and Microsoft commit to expanded support for FIDO standard to accelerate availability of passwordless sign-ins」2022 年 5 月 5 日
- 數據
- FIDO Alliance「Passkey Index」2025 年 10 月
- 外型相似字元的假網域
- Polymarket Japan 的 X 貼文（像 Amazon 的假 URL）
- A2CBoston 的 X 貼文（與英文字母非常相似的西里爾字母）
- Chromium 文件「IDN in Google Chrome」
Cynthia 股份有限公司
在 Cynthia 股份有限公司，我們會招募沒有實務經驗的工程師與學生工程實習生，一起工作。
※ 關於 Cynthia 的工作方式，請參考這裡
我們公司每年會收到 100 人以上沒有實務經驗者的應徵，並進行技術面試。
如果這篇文章對你有一些幫助，也歡迎你看看 Wantedly 的故事，我們會非常開心！
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
