閒聊
12 月份完成好幾項目標，其中一項就是催生 GDG Hsinchu 12 月份的 Meetup 線下聚會。這次活動跟著 Google 在 12 月時舉辦的 Chrome Dev Summit 2020 一同推出，取自 CDS 中的部分 SMS-OTP 內容，並結合既有的 password-based authentication 與未來有可能普及的 FIDO 2 認證機制，整理出一份 Web Authentication Security 的技術分享。其中對我來說，比較有趣的地方在於理解機制的實現原理，包含資料溝通和驗證，以及可能會產生的安全問題。其實標準規範對於開發者來說相當重要，透過分析 protocol 的行為，可以讓開發者在開發整合性功能的時候，更清楚這些 library 要在什麼時機點使用，以及為什麼要使用這些 functions，這也是我每次進行技術分享時，最希望能夠帶給與會者的內容。
Meetup Slides
Slides: Improve Your Web Authentication Security
議程問題
- WenAuthn 中的 Credential ID (指 authenticator 所產生的 public key identifer) 對應關係？
每個 Authenticator 被視為一個 user，因此如果是多人使用同一個 Authenticator ，則會被視為同一個 user。其中 Authenticator 在儲存 Credential ID 時，會依據 Relying Party ID 來分類，因此，每個 user 在一個網站 (Relying Party) 可以有多組 Credential ID，如果其中一個 Authenticator 裝置遺失（例如手機或是其硬體設備掉了），則可以使用其他已註冊的 Authenticator 來登入。
In general, an authenticator is assumed to have only one user. A cryptographic entity, existing in hardware or software, that can register a user with a given Relying Party and later assert possession of the registered public key credential, and optionally verify the user, when requested by the Relying Party.
- 如果我們使用 haveibeenpwned.com 這類網站的 API 去驗證用戶密碼是否有被盜，這樣是不是有安全疑慮？
我們在傳遞參數給 haveibeenpwned 這類網站進行帳號密碼洩露查詢的時候，只會傳遞 user account 或是 password 資訊給 API，如此一來 haveibeenpwned 就不會知道用戶帳號密碼之間的對應關係。也可以到 haveibeenpwned 網站下載所有洩露的資料，再透過自定義的方式來驗證使用者所輸入的帳號密碼是否已被盜。