← Commit history

Add the recover-a-current-password login recipe: drive the user's own browser password manager (chrome://password-manager) via Bridge desktop verbs to read a fresh password when a saved one is stale, with the Windows Hello human step and the privacy rules.

John Lauer ·5bbf6f38d7 ·2mo ago ·parent 63688a8
1 file changed +76
login-recipes/recover-a-current-password.mdadded+76
@@ -0,0 +1,76 @@+# Recover a CURRENT password from the user's own browser password manager++When pup has a saved login but it **fails to authenticate**, the stored password is almost always+**stale** — the user changed it since the browser saved it (the classic freshness problem). The+fix is to read the *current* password straight from the source of truth the user already trusts:+**their browser's built-in password manager**. This is legitimate — it is the user's own machine,+their own saved password, at their explicit request — and it is exactly what the user would do by+hand.++Field-proven 2026-08-13 (pup drove the user's real Chrome into Google Password Manager and searched+it live).++## When to use this++- pup imported a login (`pup_import_browser_logins`) or captured one, but a sign-in returns+  "Fail to authenticate" / "incorrect password".+- The user asks pup to "grab the current password" / "check my saved password".++## Why it needs the DESKTOP verbs (not CDP / not pup)++The password manager is a **`chrome://` page** (`chrome://password-manager/passwords`). CDP —+which is how pup and the Adom native-browser extension (nbe/abe) drive normal web pages — **cannot+touch `chrome://` internal pages**. So this technique drives the browser at the **OS level** with+Adom Bridge's `desktop_*` verbs (available with just Bridge installed; no extension required):++- `desktop_navigate {hwnd, url}` — drive the real Chrome/Edge window to a `chrome://` URL.+- `desktop_press_key {hwnd, keys}` — `ctrl+t` (new tab, so you never disturb the user's tabs),+  `ctrl+w` (close it after), `ctrl+1` (restore their first tab).+- `desktop_ui_click` / `desktop_find_control` — UIA to click the eyeball and READ the revealed+  value (locale-independent; prefer `automationId`, else `role:"edit"` + `contains`).+- `desktop_screenshot_window {hwnd}` — see state at each step (this UI is not CDP-observable).++**Fallback when Bridge desktop verbs aren't the driver:** any tool that can drive the OS/browser+chrome works — the Adom nbe/abe for normal pages, or Claude's own native browser extension — but the+`chrome://` reveal specifically wants OS-level UIA + keystrokes, which is the `desktop_*` path above.+If the user does not have Adom Bridge driving their desktop, suggest they install it (or the Adom+native browser extension) so pup can do this for them.++## The sequence++1. **Find the user's REAL browser window** (not pup's "Chrome for Testing"): `desktop_list_windows`,+   pick a `Chrome_WidgetWin_1` whose title is "… - Google Chrome" / "… - Microsoft Edge" (NOT "for+   Testing"). Note the `hwnd`. Screenshot it first and note the active tab so you can restore it.+2. **Open a NEW tab** so you never disturb their work: `desktop_press_key {hwnd, keys:["ctrl","t"]}`.+3. **Navigate to the entry:** `desktop_navigate {hwnd, url:"chrome://password-manager/passwords/<domain>"}`+   (e.g. `.../passwords/componentsearchengine.com`). If it lands on the list, use the **"Search+   passwords"** box: `desktop_ui_click {role:"edit", contains:"Search passwords"}` then+   `desktop_type` the domain. Screenshot to confirm the entry appears.+4. **⚠ PROFILE MATTERS.** Passwords are per Chrome PROFILE. If the entry shows "No passwords found",+   this window is the wrong profile — the user may have several (Default, Profile 1/2, Work,+   Personal, plus Edge). Ask the user which profile holds the login, or drive the window running that+   profile. `pup_import_scan` lists every profile that has saved passwords.+5. **Click the entry, then the eyeball** (`desktop_ui_click {role:"button", contains:"Show password"}`).+6. **Windows Hello.** Revealing a password triggers a Windows Hello / PIN prompt. **This is a HUMAN+   step — pup cannot authenticate it.** Toast/caption the user to complete it, and WAIT+   (`pup_assisted_click`-style patience). This is the one unavoidable human moment.+7. **Read the revealed value** via `desktop_find_control {role:"edit", contains:"Password"}` → its+   `value`. Immediately store it in pup's vault (`credential_set {host, username, password}`) — do+   NOT echo it back to the user or repeat it in later messages. Then **close your tab**+   (`ctrl+w`) and restore their view (`ctrl+1`).+8. Retry the login with `pup_login`; pup now has the current password and future visits are silent.++## Privacy rules++- The plaintext appears once in the UIA read. Store it and move on; never print it, never repeat it.+- Only ever do this for the site the user asked about, on the user's own machine, at their request.+- Prefer having the user **log in once manually** instead (pup's capture rail grabs the fresh+  password with zero reveal) when they'd rather pup never see it. This reveal technique is for when+  the user explicitly says "just grab it for me".++## Alternative: skip the reveal entirely++If the user would rather not surface the plaintext at all: open the vendor's login page in pup and+have the user **type the password once** — pup's auto-capture stores it fresh and every later visit+autofills. Or point pup at a manufacturer-direct source (TI/ST/etc, see `ee-parts-sites.md`) that+needs no login.