記憶密碼總是一件痛苦的事情，對於絕大多數不使用密碼管理器的人來說「一個密碼走天下」是密碼問題上最容易的解決方案了。但一個密碼到處用總會帶來各式各樣的安全問題，比如：這個密碼因為其他問題導致了外泄，那麼所有的帳戶都會受到威脅。
密碼這件事一定會讓不少人頭疼，圖源：1Password
為了解決這個情況，日常登錄網站和應用程式要你兩步驗證，比如 SMS 簡訊驗證碼、郵箱驗證碼或是基於時間的一次性密鑰等方式加強安全性。從我們日常使用來看，等驗證碼這個步驟反而可能是整個登陸流程里最麻煩的一件事。
兩步認證
Apple 在 WWDC 2022 中向開發者介紹了「通行密鑰（Passkeys） 」這項新的「希望可以替代密碼」的新技術，並期望通過這項新技術來解決上面的問題。
看到這裡，你可能會擔心這項 Apple 的新技術可能別的網際網路公司並不會參與。但事實上通行密鑰是通用技術標準 WebAuthn 下的一個關鍵技術，不僅可以簡化登錄的流程，還可以提高安全性和增加跨設備授權登錄的功能。只不過 Apple 在今年 WWDC 上高調地宣布了而已，微軟、Google 等大公司也已經宣布將支持這項 FIDO Standard 技術標準。
那通行密鑰是如何替代密碼進行身份驗證的，通行密鑰能完全取代你的密碼嗎？本篇文章就來帶領大家一探究竟。
▍通行密鑰是如何工作的？
目前完整支持通行密鑰的應用程式還不多，但我們可以從 WWDC 後續面向開發者的視頻中窺探到通行密鑰的使用方式。登錄介面中只需要用戶提供用戶名（User name）這一信息，然後點擊登錄按鈕，最後完成生物認證便能完成登錄。使用通行密鑰整個過程，就和我們目前使用 iCloud 鑰匙串或是支持自動填充的密碼管理器一樣自然、直觀。
使用通行密鑰登錄帳戶
在傳統登錄環節中由簡訊驗證碼、兩步驗證器所扮演的身份驗證功能，也將由通行密鑰代勞；儘管通行密鑰和登錄密碼的功能存在差異，但在整個註冊和登錄的過程中無需我們主動創建、記憶或輸入密碼。這種一鍵登錄、幾乎不會增加學習和使用成本的身份驗證機制，顯然也要比我們現階段主要使用的大部分身份驗證方式更加無感。
使用自動密碼填充登錄帳戶
01用非對稱加密證明「你是你」
不過通行密鑰並不是什麼新鮮的玩意，它其實是密碼學中「非對稱加密」在登錄認證中的一種應用。
單個通行密鑰由一對密鑰組成，分別是 公鑰（Public key）和 私鑰（Private key）。
我們可以把公鑰類比於帶「防盜」鎖的傳統信箱，把私鑰類比於信箱的鎖的鑰匙。郵遞員投遞的信件就是我們要加密的信息，通過投遞到信箱中加密起來，然後也只有信箱的主人才有鑰匙能夠打開信箱讀取信件的內容。如果一個人手上沒有鑰匙，那就需要用暴力開防盜鎖，整個過程不僅耗時耗力，最後也往往沒辦法打開那把防盜鎖。
與之對應的，如果某些內容被公鑰加密了，則該內容能且僅能被私鑰解密，非對稱加密的可靠性正來源於此——若無私鑰，在有限的算力和有限的時間內我們一般無法完成極大整數的因數分解；如果加密內容能被解密，則說明對方擁有私鑰。
非對稱加密的這種唯一對應性，顯然是非常適合用於登錄認證的。
實現通行密鑰最基本的原理
以 WWDC 中的例子進一步展開說明，在用戶完成第一次登錄以後，服務端和用戶終端分別持有由用戶終端生成的公鑰和私鑰。如果這時用戶再需要登錄，用戶將用戶名發送給伺服器以後，伺服器用用戶名對應的公鑰創建一個「口令（challenge）」發送給用戶終端，放到上面的例子裡就是郵件投遞到了用戶的傳統信箱裡；用戶這時可以使用私鑰解答該「口令」並將對應的「答案（solution）」再發送給服務端，放到上面的例子裡就是用戶取出了這份郵件並根據這份郵件給發信人返回了一個正確的信件。如此，服務端便能通過比對答案是否正確從而驗證終端是否為公鑰的主人了。當然，上述的通訊過程都是通過 HTTPS 加密的。
所以這也是為什麼 通行密鑰可以替代各種形式的驗證碼進行身份驗證。
關聯閱讀：瀏覽器上那把「小鎖」是什麼？隨處可見的 HTTPS 怎樣保護你的網絡安全
02服務端如何獲得用戶的公鑰？
細心的同學可能會疑惑，上述過程中的假設是如何成立的？換句話說，服務端最初是如何獲得公鑰並與我們手裡的私鑰產生對應關係的？
目前，從 WWDC 的視頻和 Google 開發者文檔中的信息來看，我們需要先行通過傳統的密碼方式註冊一個帳號，然後再綁定通行密鑰到該帳號中。
使用密碼初次登陸
在完成用密碼的登錄過程後，帳戶設置裡面會有選項添加通行密鑰，且通行密鑰完全由用戶終端生成、需要經過終端的生物認證，然後公鑰上傳到服務端，私鑰保存在鑰匙串里。這樣就完成了用戶名和通行密鑰信息的綁定。
這裡打個不完全正確的比喻，和前面所說的一樣公鑰是傳統郵箱的話，我們要向郵政公司提前登記「這個郵箱屬於你」，提前登記的過程就是使用傳統密碼註冊帳戶的過程。
▍通行密鑰還有什麼優點？
作為一種用於用戶身份認證的替代方案，通行密鑰最直接的應用場景顯然就是跨設備登錄了。
微信桌面版
上圖就是很貼近生活的一個例子，在這類場景中，我們以往一般需要通過簡訊驗證碼或兩步認證來確認登錄者身份，國內比較常見的例子就是：微信登錄電腦端時，需要通過已登錄的手機進行掃碼來完成身份驗證。
通過手機掃碼驗證
而在通行密鑰的應用場景中，當用戶打算在一個陌生電腦上臨時登錄自己的帳號的時候，也是可以通過手機掃碼來安全地授權完成認證登錄的。
同樣是掃碼行為，通行密鑰不同的地方在於它可以脫離對具體服務端、客戶端的依賴，變成一種純粹的身份認證工具。因為它本質上是 FIDO 對通行密鑰的擴展——客戶端到認證器協議規範（Client to Authenticator Protocol，CTAP），也就是外部認證器通過中繼網絡（Relay Network）向用戶的網際網路接入設備局部傳遞認證證書—— 我們需要做的，就是通過設備上的生物信息驗證機制將通行密鑰認證結果傳遞給其他設備。
建立安全通道
通行密鑰的掃碼操作的背後，一般則會將手機作為認證器與電腦通過 USB、NFC 或藍牙等方式進行通訊。具體而言，電腦端會根據 FIDO 的協議生成一個隨機字符串並編碼為二維碼展示，然後手機掃碼該二維碼獲取該隨機字符串（key input）並作為對稱加密密鑰，並建立一個近距離通訊的網絡發布，電腦端使用相同的字符串連接上該網絡。如此，手機和電腦便能安全地互相通訊。
電腦需要驗證時，可以先將口令安全地傳遞到手機上，再在手機上用私鑰解答出有關的答案，最後再將答案安全地傳回電腦端，並由電腦端和伺服器進行通訊完成上述的認證登錄過程。
除了跨設備登錄，通行密鑰也將為傳統的登錄驗證流程帶來額外的安全性保障。
一方面，任何基於物理設備生成的身份驗證手段，在設備被盜或丟失後，都將面臨密碼泄露的風險，但通行密鑰要求每次訪問私鑰的時候都經過設備的生物認證，安全性相對更好。且一個帳號可以綁定多個設備的通行密鑰，設備丟失後還可以在服務端刪除對應的通行密鑰以進一步加強安全性。
另一方面，釣魚網站攻擊主要依靠偽裝目標網站的方式來騙取用戶主動輸入帳號密碼。通行密鑰方案的原理則決定了釣魚網站首先需要擁有用戶的公鑰——我們在上面已經提到，公鑰從生成開始便儲存在目標網站的伺服器上，除非這些釣魚網站直接攻破這些網站的伺服器，否則無從獲取公鑰，但如果真的可以攻破伺服器為什麼又要採用釣魚手段呢；另外，在通行密鑰的認證流程中，我們也從來不需要向任何人發送自己的私鑰，僅通過二維碼等近場通信手段交換答案，這兩點可以在很大程度上阻止當前釣魚網站的攻擊。
▍通行密鑰有什麼潛在不足？
通過上面的介紹，我們也不難看出通行密鑰的不足——它並不能像某些網絡報道中所宣稱的那樣，完全取代你的密碼。
在通行密鑰的設計中，伺服器需要用戶先行使用密碼創建一個帳號，然後才能將用戶的公鑰綁定到該帳號上，當設備損壞或丟失時，密碼依然是通行密鑰的容災策略。這一點可以在 Xbox 幫助文檔中「忘記密鑰」的部分得到體現。
密鑰的優勢
同時，通行密鑰私鑰的同步和遷移也存在成本，畢竟我們總有更換設備的那天。而在 FIDO 和 W3C 的標準中，都沒有描述當用戶打算更換平台的時候如何遷移通行密鑰的私鑰，比如如何從 Apple 設備換到 Android 設備。當我們保存在手機的密鑰數量不斷增多，需要在新手機上重新綁定新的公鑰也會花費大量的時間。如果作業系統服務商不開放相關權限給第三方服務，那遷移成本肯定不小。
最後則是密碼遺忘問題。由於通行密鑰本身極大的便利性，人們會很容易使用並依賴它。但別忘記，通行密鑰無法完全替代密碼本身。年輕人或許能學會使用密碼管理器，但是長輩們可能會由於長期沒有間歇性使用密碼便完全忘記了當初設定的密碼，通行密鑰的普及將會放大這一現象。
通行密鑰很好地解決了記密碼的難題，從 Apple 實現的方式上而言也很優雅；雖然目前仍有一些機制上的不足，但隨著這項技術的完善還是可以解決的，畢竟誰又能不喜歡一個「無密碼」的世界呢。最後，關於通行密鑰這項技術你還有什麼想法的也歡迎在評論區進行討論。
原文連結：
https://sspai.com/post/73937?utm_source=wechat&utm_medium=social
作者：正弦定理
責編：廣陵止息
/ 更多熱門文章 /