This free password security checker finds the credentials that authenticate without your second factor — Gmail app passwords and Apple app-specific passwords. They hide for years in ~/.bashrc, old .env files, CI configs, and notes. And now attackers have a formal playbook: the October 2026 MITRE ATT&CK v20 release added a technique for stealing application-specific passwords. Thirty seconds to check your exposure.
xxxx-xxxx-xxxx-xxxx, never on real values.Short answer: if you ever created an app password and didn't store it in a secret manager, assume a copy is sitting in a file you forgot about. Revocation takes two minutes per provider — the five questions below tell you whether you need to.
Answer for the accounts and machines you control.
Type a redacted placeholder in the same shape as a password you found (use x for every character you hide — never type the real value). This check runs 100% in your browser; nothing is transmitted.
| Fact | Detail |
|---|---|
| The bypass | App passwords are scoped credentials that authenticate without triggering 2FA. A leaked one signs in as you — no authenticator prompt, no SMS, no passkey. |
| Gmail format | 16 lowercase letters, shown as one run or four space-separated groups. Used for IMAP/SMTP access by apps that cannot do Google OAuth. |
| Apple format | Four groups of four lowercase letters/digits joined by hyphens (xxxx-xxxx-xxxx-xxxx), generated at appleid.apple.com for mail/calendar/contacts sign-in on third-party apps. |
| MITRE ATT&CK v20 | October 2026 release added nine new Enterprise techniques, including one for stealing application-specific passwords — the playbook is now formalized. |
| Where they leak | Dotfiles, .env files, CI/CD configs, notes apps, chat history, screenshots, old backups. They persist for years because nothing reminds you they exist. |
| The fix | Revoke at the provider — deleting the line from your file is not enough; the password stays valid until revoked. Then rotate downstream services and move secrets to a secret manager. |
Source: letsdatascience.com — "MITRE Adds AI Attack Techniques to ATT&CK" (Oct 2026) — cited as news coverage, not independently verified. App-password formats are Google's and Apple's publicly documented formats.
Go to myaccount.google.com/apppasswords (signed in; it will ask for your 2FA), find the app password by creation date, and remove it. Prefer OAuth sign-in for the app afterwards; store any replacement in a secret manager.
Go to appleid.apple.com → Sign-In and Security → App-Specific Passwords, and revoke — or revoke all if you cannot tell which is which. Store any replacement in a secret manager or the macOS Keychain.
Rotate every downstream service that used the password (CI jobs, mail clients, backup scripts) — revocation breaks them by design. Move secrets to runtime-injected environment variables or a secret manager. A .env file copied around is a credential leak waiting to happen.
A long, machine-generated password issued by Google or Apple so a third-party app (an old mail client, a backup script, a CI mailer) can sign in to your account. Gmail app passwords are 16 lowercase letters; Apple app-specific passwords are four groups of four letters/digits joined by hyphens.
By design: app passwords are scoped credentials that authenticate without triggering your second factor. If one leaks, whoever holds it signs in as you — no authenticator prompt, no SMS, no passkey. That is why they are high-value targets.
Per October 2026 news coverage, MITRE ATT&CK v20 added nine new Enterprise techniques including one for stealing application-specific passwords — formalizing what red teams already knew: these credentials are a distinct, prized attack target. (Reported by letsdatascience.com; cited as news coverage, not independently verified.)
Dotfiles (~/.bashrc, ~/.zshrc), .env files, CI/CD configs, password-manager exports, notes apps, chat history, screenshots, and old laptop backups. They persist for years because nothing reminds you they exist.
Go to myaccount.google.com/apppasswords while signed in (it will ask for your 2FA), find the app password by its creation date, and remove it. Then update the app: prefer OAuth sign-in, and store any replacement in a secret manager — never back in the file.
Go to appleid.apple.com, open Sign-In and Security, then App-Specific Passwords, and revoke the password — or revoke all if you cannot tell which is which. Generate a replacement only if an app still needs one, and store it in a secret manager or the macOS Keychain.