簡介: 解析 Windows Hello PIN 視窗、2026 年安全變更,以及登入工作階段、官方 API 和虛擬 WebAuthn 的可行性。
機器人做了九成,最後竟然叫人上班
瀏覽器自動按登入、填好表單,一路順暢。接著 Windows 跳出「請輸入 PIN」。你以為自動化能幫忙值夜班,結果自己變成 PIN 輸入員。
結論: 一般瀏覽器腳本沒有標準且可靠的方法,能讓既有的 Windows Hello 密碼金鑰完全無人通過 PIN 驗證。不過,沿用網站允許的登入狀態、使用官方 API,或在合適情況下另行註冊虛擬憑證,可以減少手動操作。[1][2][3]
PIN 並不是網站密碼
Windows Hello 在裝置上保護私密金鑰,以 PIN、臉部或指紋確認使用者,再用金鑰簽署網站的認證要求。網站不會把 PIN 數字當成普通密碼接收。[1][4] 自動填寫網頁和控制 Windows 安全視窗之間存在不同的安全界線。
2026 年安全更新的影響
Microsoft 表示,自 2026 年 1 月 13 日起的更新限制不可信的遠端與自動輸入進入 Windows 認證視窗。實體鍵盤、具特定權限的應用程式與一般模擬按鍵,待遇不一樣。[5]
Power Automate Desktop 無法控制部分認證視窗的問題也有官方說明。文件建議從 Edge 改用 Chrome 或 Firefox,只針對該工具的特定問題,不是保證任何 Windows Hello PIN 都能無人通過。[6]
五條實際路線
重用登入工作階段: 第一次由本人登入,再保留網站允許的狀態。Playwright 可儲存 Cookie 等資訊,但到期或要求追加核驗仍要人工處理。不要把工作階段檔案提交 GitHub。[2]
官方 API: 若服務提供專為程式設計的登入方式,通常比模擬點擊更適合無人作業。Web 的密碼金鑰與 API 認證可能不同。
虛擬 WebAuthn: Chrome DevTools 與 Playwright 可以模擬密碼金鑰註冊及使用,尤其適合測試。它們不能直接匯出原有的 Windows Hello 私密金鑰。正式網站是否允許新增另一個金鑰,必須確認。[7][3]
臉部或指紋: 省下輸入 PIN 的動作,卻仍需要本人。[4]
模擬按鍵: AutoHotkey、PowerShell 或 USB 鍵盤模擬器可能受到保護視窗限制。將 PIN 以明文保存也會增加風險。[5]
判斷順序
重複工作先檢查登入狀態能否維持;長期無人執行先找官方 API;測試自己的網站則使用虛擬驗證器。若第三方網站規定每次本人核驗,就設計暫停及通知。重開機、工作階段過期與重要操作前要分別測試。
結論
重點不是讓機器人學會按 PIN,而是改用本來就能自動化的認證途徑。不然全天候工作的機器人,還是需要人類 PIN 夜班同事。
參考資料(7筆)
- Microsoft Learn: Support for Passkeys in Windows learn.microsoft.com
- Playwright: Authentication and session state playwright.dev
- Playwright: Virtual WebAuthn credentials playwright.dev
- Microsoft Learn: Passkey verification on Windows learn.microsoft.com
- Microsoft Support: Credential autofill restrictions, Windows January 2026 update support.microsoft.com
- Microsoft Learn: Power Automate desktop Windows credential dialog issues learn.microsoft.com
- Chrome for Developers: Emulate WebAuthn authenticators developer.chrome.com




