# Passkey：最安全的密碼是不使用密碼

*區塊鏈社會學 #160 2024.07.11*

By [DHK dao](https://paragraph.com/@dhk) · 2024-07-10

zh, security

---

上週的漂流教室有 11 位來客，抱歉我沒法跟每一位好好聊。在 Happy Belly 宣告關門前一刻聚會實屬巧合，我無意蹭熱度，送別不是壞事，但我認為在日常生活支持所相信價值會更理想，別等到快將結業才行動，愛得太遲。

本週五（7.12）17:30-19:30，我會漂流到[葵青劇院的牧羊少年咖啡館](https://maps.app.goo.gl/FcPE8FPwduWaknYF9)，有朋友來的話我們一起開錢包和送 DHK，要是沒有，我就終於可以讀半年前在台北書展買的推理小說了。

[Connect Wallet](https://paragraph.xyz/@dhk/lzrworkj7n814gRVOH21)

* * *

為防止電話騙徒冒認身分，你可以跟阿嬤約定致電時以「123」核實身分，你小心保管這個密碼，但沒法防止阿嬤不慎把密碼洩漏。有辦法不向阿嬤披露密碼，卻能讓阿嬤核實身分麼？這就好像說，當阿嬤問「床前明月光」，雖然並未約定暗號「疑是地上霜」，阿嬤卻能透過回覆確認你的身分，這聽來不合邏輯，然而數學家卻找到完美答案，那就是不對稱加密的公私鑰。

不對稱加密
-----

假設 Alice 跟 Bob 約定，通訊時把每個字母按順序 -1 加密，比如「KTMBGZSMNNM」，要解密就得反過來 +1，得出「LUNCHATNOON」，這種雙方都知道加密和解密方法的機制（-1、+1），稱為「對稱加密」。

對稱加密的弱點顯而易見：有多少人需要解密，就有多少人知道加密的方法。假如你和其他 999 人打算反清復明，並以對稱加密方式通訊，組織內的 1000 人全部都得知道加密與解密的方法，不但容易因洩漏而被清政府解密訊息，還會被清政府的大內密探零零發冒充同路人，發放假訊息。

相對起來，不對稱加密則使用公私鑰組合，公鑰開放給對方，私鑰只有自己保管；公私鑰最重要的特性是，任何以私鑰加密的訊息，只能以對應的公鑰解密，反之亦然。這個約五十年前誕生的神奇發明，成就了日後各種保護私隱和核實身分的應用，並廣泛應用於比特幣及所有其他區塊鏈。

即使你毫不認同密碼貨幣，也不使用主打端對端加密的 Signal、Protonmail，只要你有在用 WhatsApp、iMessage、FaceTime、Google Meet，甚至只是瀏覽任何 https 的網址，就代表受惠於公私鑰的加密機制，只是你不一定知道。如果你有上網但真的沒有用不對稱加密，我只能說，你一直在網上裸奔。

公私鑰加密有兩大用途：

1.  核實身分。Bob 要確認 Alice 身分，可請對方「簽署」——即以私鑰加密一條特定訊息——「床前明月光 123」，然後使用 Alice 的公鑰解密簽署訊息，若然得出「床前明月光 123」，代表對方的確是 Alice（當然也可以是盜取了 Alice 私鑰的賊人，這就是為甚麼保管好私鑰那麼重要）。
    
2.  加密訊息。Bob 給 Alice 發私訊，可先使用 Alice 的公鑰加密訊息才發送出去，Alice 收到訊息只要使用對應私鑰就能解密，其他人即使攔截到訊息，沒有 Alice 的私鑰，也只能讀到一堆亂碼。
    

以往我多次強調密碼貨幣安全但不私密，是因為比特幣、以太幣、Solana、Cosmos Hub、LikeCoin 等絕大部分區塊鏈，只利用公私鑰核實轉賬用戶的身分，確保持有私鑰才能動用資產，但並沒有加密交易的內容。雖然著重私隱的區塊鏈如 Zcash、Monero、Mobilecoin 等能把交易雙方和金額等細節加密，但這些私隱幣是政府的眼中釘，全都被強力打壓，出入金非常困難。

萬千寵愛在 passkey
-------------

家裡使用一般密碼無法避免阿嬤不慎洩密，在互聯網也一樣，無論用戶多謹慎都沒法避免網站數據外洩。要避免被豬隊友拖累，就要改用不對稱加密認證身分，這就是 passkey 的核心。

Passkey 由全球資訊網聯盟（W3C）及快速身分驗證聯盟（FIDO）制訂，2022 年 5 月 Apple、Google、Microsoft [共同宣布](https://www.apple.com/fi/newsroom/2022/05/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard/)支持，passkey 開始受到關注，畢竟，科網巨頭不支持的標準，自稱標準也是多餘。

雖然我經常吐槽 Apple 封閉，但三大巨頭中它最早也最完整地支持 passkey，值得一讚。宣布支持 passkey 後才一個月，Apple 就在年度開發者大會 WWDC [公開](https://developer.apple.com/videos/play/wwdc2022/10092/) passkey 的細節，開發商如何接入等，passkey 正式進入大眾視野。2023 年，Google [開始支持](https://blog.google/technology/safety-security/the-beginning-of-the-end-of-the-password/)並鼓勵用戶改用 passkey，到了上月，Microsoft 也[宣布](https://www.microsoft.com/en-us/security/blog/2024/05/02/microsoft-introduces-passkeys-for-consumer-accounts/)普通用戶帳號支援 passkey 登錄。三大平台背書，兩年多以來，大量網站也逐漸支援 passkey，以 Google 為例，已有四億用戶開通 passkey，建議還沒著手的都去[體驗一下](https://myaccount.google.com/signinoptions/passkeys)。

![](https://storage.googleapis.com/papyrus_images/07950bc6ee374eaf4d8cd9c77b567809.png)

Image credit: [FIDO Alliance](https://fidoalliance.org/how-fido-works/)

相對於由用戶自行創造帳號和密碼，使用支持 passkey 的應用時用戶只需要定義帳號，系統即會在設備生成一組公私鑰，私鑰保存於用戶的設備，即 iPhone、Android 手機、Windows PC 等，公鑰則由服務商保管，由於無需去想和填密碼，比傳統註冊方式便捷。登錄時，passkey 利用公私鑰的原理核實用戶身分，在大部分支援的設備，用戶使用生物認證就能以私鑰簽署，整個過程不牽涉密碼，方便快捷之餘，還比傳統密碼安全得多。

便捷跟安全通常「對著幹」，越便捷越危險，越安全越麻煩，既方便又安全似乎有違常理。不過，一本通書不能睇到老，比如說，若你的帳號使用十層密碼，每次登錄超級麻煩，但由於只用上一個因子，搞不好十個密碼全都寫在同一記事本，麻煩了很多，卻只安全了一點，「性價比」很低。相反，passkey 的私鑰只儲存於用戶設備，符合「what you have」，其次簽署前必先通過生物認證，符合「who you are」，兩個因子加起來，安全性提高一個維度，但由於拿起手機掃指紋或刷臉用不到兩秒，不會讓人感覺麻煩。

除了較為便捷，也杜絕因服務商數據外洩流出密碼，由於簽署前系統會先核實服務商的網址等元資料，passkey 也能有效杜絕釣魚。可以說，無論是便捷還是安全性，passkey 各方面都完勝密碼。

沒有密碼的世界來了...麼？
--------------

話雖如此，以為 passkey 會迅速取代密碼也未免天真，把事情想得太簡單，要是優勝劣敗是唯一原則，這世界還會有人看 TVB 麼？用戶習慣抵得上很多缺失，慣性不容忽視。

對於一般用戶，安全不過是一份感覺，只要保安措施貌似完善，用戶就會感覺良好。反過來說，如果措施看來很簡陋，即使只是錯覺，用戶都會缺乏安全感，這正是 passkey 當前面對的窘態，也是我大花篇幅，一連四期解釋 passkey 如何做到既方便又安全的原因。

再說，即使完勝密碼，passkey 遠遠還沒做到無懈可擊，最明顯的問題是丟失 passkey 時如何處理。丟失密碼就重設是誰都懂的互聯網常識，而 passkey 則主要以兩種方法應對丟失，首先，一個帳號可以綁定多組 passkeys，存放於用戶的不同設備，比如一組在電腦、一組在手機，萬一丟失其中一組，不但仍可使用另一件設備的 passkey 登錄，還能設置丟失的 passkey 失效，避免賊人登錄。另一種方式是雲端同步，最廣為使用的是 Apple 的 iCloud keychain，只要一開通就會把加密後的 passkeys 同步到雲端及其他以同一 Apple ID 登錄的設備，換言之，只要還能登錄 Apple ID，就不怕個別設備丟失。問題雖然是解決了，但是否過於中心化就見仁見智，不過，目測樂於全面依賴 Apple 的人非常多。

除了丟失引起的問題，歷史尚短的 passkey 雖然標準清晰，但細節還未完全沉澱和統一，光是各個應用如何向用戶解釋 passkey，又如何翻譯，就已經莫衷一是，容易讓用戶困惑。理解到 passkey 的戰略位置，各家廠商都爭取成為用戶儲存 passkeys 的預設選擇，最好是唯一選擇，也因此帶來惱人的體驗。

我就試過，MacBook 插著專門用於 2FA 的 Yubikey，使用 Chrome 瀏覽器，裡面安裝了 Proton Pass，作業系統、周邊硬體、瀏覽器、插件，每一層都有儲存 passkey 的功能，有些雲端同步，有些只存於本地，不同網站的 passkeys 有時儲存在不同地方，有時多組 passkeys 分別儲存在各個地方，雖然登錄時系統會自動偵測，管理起來還是搞得我頭暈轉向。如果有用戶遇上類似情況舉手投降，乾脆用回密碼，我想我能理解。

即使不算多年來的積累，三大巨頭宣布支持 passkey 至今已經超過兩年，但目測身邊聽過的人不算多，理解原理的就更少，我身邊尚且如此，遑論是普羅大眾。我們不可能責怪用戶不懂就不用，反倒是不求甚解，便捷流行就使用才是大問題。Passkey 要逐步取代密碼，服務商必須從引導、文案等著手，讓用戶理解機制如何兼顧便捷與安全。

沒有人會反對科研重要，但要是缺乏科普，民眾沒法理解，輕則新技術不獲採納，重則被妖魔化，passkey 如是，區塊鏈更加如是，讓科技得以服務公民社會需要，是我致力於 web3 普及教育的初衷。

後記
--

資安系列從 [2FA](https://ckxpress.com/substack-2fa/)、[密碼管理器](https://ckxpress.com/password-manager/)、[公私鑰](https://ckxpress.com/stateless/)，來到今期的主角 passkey，暫吿一段落。雖然還有番外篇的打算，但訊息量有點大，還是先讓大家歇歇消化一下好了，況且，下週我更希望能騰出版位分享一個消息，敬請期待。

* * *

p.s. 九十年代有齣英國電影小品 _Four Weddings and a Funeral_，我對當中的愛情線並無共鳴，倒是出席四個婚禮、一個葬禮的日常，跟我當時的生活很接近。近日我忽然意識到，過去一年，我出席了一個婚禮、四個葬禮，最近一位逝者是封面圖中小店的東主。我想，這大概就是人生階段吧。

---

*Originally published on [DHK dao](https://paragraph.com/@dhk/passkey)*
