After you change the password and MFA, who can still walk into the AI session in your browser

A colleague says Claude’s quota just refilled and then emptied, and they never opened a window. The password-manager entry is last month’s rotation. The phone never rang for a code. Two days later the inbox holds an Anthropic notice: unusual usage, a forced sign-out, and the saved payment method removed. The letter says Claude was not broken. An infostealer on that computer copied the login session along with everything else it already collects.

The last piece covered what to redact before you paste a password into ChatGPT or Gemini: that is the path after you put plaintext into a prompt, and whether training switches or a share link can still read it. This one changes the question. After you are already signed in, the proof that says “this is me” still lives in places you can open — and a local program can copy. If a key has to move, use a one-time link in the shape s.html?id=…#…. Create and read both work without an account. MyPassGen’s tools open without sign-up. The rest of this page does not explain how any malware family spreads. It lines up numbers Okta and Anthropic already published, and the rows you can see in a session list.

Why the account still opens after a password change

A site does not ask for the password on every click. After a successful login, the browser keeps a session: a cookie, a JWT, and on a single-page app often a token in localStorage or sessionStorage. Later requests present that still-valid proof. The server is not checking whether you can recite the password right now. Okta Threat Intelligence’s 9 September 2026 note Signing in without actually signing in calls that proof a skeleton key: drop an unexpired token into another browser and the attacker is already signed in. The username field, the password field, and the MFA challenge do not appear again.

That is not the same path as “someone guessed the password.” Passkeys and hardware keys raise the login box. Okta also writes that they make username-and-password takeovers harder, and that they still do not stop a stolen session token or API key. Changing the password on a settings page usually only affects the next person who walks through the login box. Sessions already issued wait for expiry, a server-side revoke, or a kick from the “signed-in devices” list. Changing the password and never opening that list is changing the house key and leaving a still-valid access card on the table.

The clipboard piece covered a leftover after Copy: the password left the generator field and entered the system clipboard, in who else can read the clipboard after you copy a password. A session token leaves the login page and enters the browser profile and memory. Both leftovers sit on this device. Neither one ends because you already clicked Copy or already signed in. After Incognito closes, bookmarks and Downloads can still hold a full one-time URL — that path is in after you close Incognito, the password is still in Downloads, bookmarks, and the clipboard. Sessions more often live in the everyday profile. Closing the window does not revoke them.

Okta: tokens still alive in a 7 GB dump

Okta analysed a free log dump posted to a Telegram channel on 2 August 2026. The archive was about 7 GB, covering 5,871 infected machines in 162 countries. They counted authentication material, then separately counted the batch that was still unexpired on the day the dump went public — the batch a buyer would replay first.

In Netscape cookie format, Google (Workspace and consumer) had 9,829 unique authentication tokens; 9,213 were still unexpired on 2 August, on 4,144 machines. Microsoft (Entra and consumer) was 2,491 / 1,763 / 1,753. Anthropic was 561 / 164 / 404. Cursor was 32 / 16 / 26. The same table also listed Amazon, Gamma, Notion, Character.ai, Poe.com, and Pika AI. Google, Microsoft, and Amazon sit behind a single sign-on gate, so those counts are the primary tokens that gate issued, not a popularity ranking of each product.

JWTs were a second pile. The dataset held 44,791 unique JWTs; Okta marked 555 as likely used for AI-service authentication. A separate search found 2,937 authentication-related JWEs, most of them issued by OpenAI’s NextAuth.js. Without the decryption key you cannot read the body; an unexpired token can still be replayed as-is. Added together, 1,843 JWTs and JWEs were still unexpired on 2 August. Okta also wrote that 17.7% of JWT bodies carried plaintext personal data such as a name, phone number, or email. After the token expires, that identity string does not vanish. It is still useful for phishing.

Short-lived access tokens often last minutes to an hour and are renewed by an HttpOnly refresh token, which is meant to stop page script from reading the long-lived half. Okta is explicit: malware is not bound by that rule. When a single-page app parks a JWT in LocalStorage or SessionStorage, the same copy job picks it up. They did not see stolen Okta sessions in this dump. They did write “re-evaluate the session after an IP or device change” as an enterprise detection idea. A personal account has no such gate. You revoke rows in your own session list.

Anthropic: signing out old sessions does not clean the machine

In late August 2026, Anthropic began emailing some Claude users. BleepingComputer, SecurityWeek, Help Net Security, and Malwarebytes all quoted the same notice. The company wrote that someone used common infostealer malware to steal Claude login sessions from other people’s computers, then used those sessions to enter the account and burn the quota. If usage looked as if it had just refilled and then drained while you were not using Claude, that was the likely path. They also wrote that they had no reason to believe the malware was related to Claude, installed through Claude, or related to anything you did inside Claude. Help Net Security quoted one more line: phones and tablets did not appear to be part of this wave.

SecurityWeek listed the families they named: Vidar, Lumma, StealC, RedLine, and Acreed on Windows, and a smaller set of Atomic Stealer (AMOS) on Mac. Those are general-purpose stealers. They usually arrive with an unofficial download or a malicious app, then copy saved browser passwords, login cookies, and other local credentials. A Claude session was one item in that harvest. Someone later started picking that item out and using it.

On the company side they forced a sign-out of the affected sessions, removed saved payment methods, and refunded charges they classified as unauthorised. The sentence that matters in the notice is this one: signing you out of Claude stops the stolen sessions, but it does not remove the malware. The machine is still there. The next login writes a new session, which can be copied the same way. Their order is: clean the device first, then change the password on the bound mailbox, turn on two-factor authentication, and only then put a payment method back. A sign-out revokes the card. It does not disinfect the computer.

API keys, LocalStorage, and plaintext config are another layer

A session cookie covers the web login. An API key covers a program calling the model in your name. Okta ran TruffleHog on the same dump and found 24 keys that were still valid at publish time, across Google Gemini, OpenAI, Groq, and OpenRouter. They cited three stolen-key bills: nearly $1 million at one organisation, $25,000 for a software architect, and $600,000 in credits at an AI-testing shop. A key in a config file or an environment variable is the fastest way to start. It is also the fastest way for a local program to turn your quota into someone else’s. OpenAI, Anthropic, and others let you put a usage cap and an IP allowlist on a key. Without those gates, a stolen key is treated as already allowed to bill you.

A more stable pattern is OAuth 2.0: the app receives a short-lived access token, the refresh token sits in the system keychain or a password manager, and the scope stays as narrow as you can make it. Okta put “do not drop a plaintext API key into a config file or an environment variable” on the same level as a password. If a colleague still needs the key, do not write it into a plaintext file that will enter Git or a synced drive — that path is in before you drop a file in the cloud, who can read the plaintext — and which path the passphrase should take. A full one-time URL in a config file is still a credential: the slice after # does not enter the HTTP request line, but the on-disk file and object storage still hold the whole string, as in when you send a password once, why the decryption key belongs after # in the URL.

Browsers are adding their own brakes. Okta mentioned Google’s 2024 App-Bound Encryption, and Device-Bound Session Credentials that cryptographically bind a session to a device. They wrote that ABE saw workarounds quickly, and that DBSC is still early — sites have to implement it on the server, and Chrome 145 for Windows has been able to support it since March 2026. Until the site you use actually speaks DBSC, what a person can check is still: does the session list show a device that is not yours, and is a key still sitting in a plaintext file?

What a password, MFA, and a session each actually block

Use the same throwaway account and a browser profile you control. Run “change the password only,” “revoke every session,” and “revoke the web sessions, leave the key file alone.” The pages you can still open are not the same. The table is written from doors you can click, not from marketing names.

Do not mix the fifth row with the first four. Writing a full s.html?id=…#… into a repo or a chat still leaves one credential in the local file and in an infostealer log. The host that parks ciphertext cannot see the key. Split the id and the key and a full-text search cannot find a link that opens. Treat a complete link as the password itself.

Check on the spot

The steps below do not depend on any vendor promise. Use a throwaway account and a test password that will never sign in to real work, such as orange-lake-7. Do not practise with a live master password, a production API key, or a live one-time URL.

1. Register or sign in to a disposable AI or Google account in your everyday browser and stay signed in. Open that service’s signed-in devices, sessions, or security page and note the current row. Sign in again from a second browser or an Incognito window. Refresh the first window: you should see two rows. Revoke the one you are not using. Refresh the second window: it should drop back to the login box. This step checks whether the session list can actually kill a card. It is not a malware test.
2. Stay signed in in the first window. Change only the password. Do not click “sign out all devices.” Watch the second window. Some products kick every session at once. Others only retire the old password and leave open sessions alive. Write down what you see. Do not use that observation to guess every product. Trust the page you just refreshed.
3. If a Google account is the gate for Gemini or Workspace: open Google account device activity and look for a place or a browser that is not yours. Google and Microsoft were the two largest columns in Okta’s table because one SSO token opens a string of apps behind it. After you revoke a stranger, check whether Gemini or mail asks you to sign in again.
4. If you use Claude, ChatGPT, or Cursor: in account settings, find sessions, signed-in clients, or the API key list. Revoke what you can revoke. Delete keys you can delete, then mint new ones. Anthropic’s notice already said that being signed out of the website is not the same as a clean computer. Whether this machine has a stealer is a question for your own system security tools. MyPassGen will not scan the disk for you.
5. Search this machine for the test key string: the project folder, .env, editor local history, shell history. After the web sessions are gone, a plaintext file is still another copy. Handling is in the file-encryption piece. Do not paste a production key you just found into chat.
6. Create a MyPassGen one-time link with the same test sentence, expiry 24 hours, reads left at 1. In chat or a ticket, paste only the part before the hash, s.html?id=…. Speak the key on a call or in person. Opens without an account. With only the id, the recipient should see an incomplete link; both halves are required to decrypt. After reading, overwrite the clipboard. Do not store an address that still has # in a browser profile that syncs.

On a company account, add half a step: ask whether forced SSO is on, whether session-risk detection exists, and whether API keys have a usage cap and an IP allowlist. MyPassGen will not tell you whether a given gateway stored another copy. Trust the windows you just opened.

If you have to hand off a key, split it

For a one-to-one handoff the other person can open now, do not write an API key into plaintext that will enter a repo, a synced drive, or a chat archive. Generate the password on this device, then wrap it in a one-time link. MyPassGen’s password generator uses a random mode of 6–128 characters, default 16, and warns below 8. It opens without an account. The result is not uploaded as business data. On create, the browser encrypts with AES-256-GCM. A single note caps at 32 KB. Reads default to 1 and cap at 10. Expiry can be 1 hour, 24 hours, 7 days, or count-only with no TTL. The server parks ciphertext only.

When a repo or a ticket still needs an entry point, split the channel. The file carries only the owner, the id, and the sentence “key by phone.” A call, an in-person handoff, or a different messenger account carries only the slice after #. Neither half decrypts alone. That is a usage pattern, not a product default. The create page still emits one full link, which is convenient for a one-to-one send. On a channel that draws preview cards, run a test link first and see whether the preview counts a read, as in if you paste a one-time link into Slack or WeChat, does the preview burn it first.

A key pack or export larger than 32 KB does not belong on a one-time text link. Use the file encryption box: streaming AES-256-GCM in the browser, one file up to 5 GB, output .lock / .enc, passphrase sent separately. Encrypt on this device first, then sync; the other side should see ciphertext only. Pushing an unencrypted .env to a drive, or leaving it for a browser extension to read, is the same class of problem as leaving a session cookie for a local program: the proof that says “this is me” left the window you thought it lived in.

After you have checked “does changing only the password kick the second session” and “after I revoke a row, does the other window return to the login box,” you can answer this article’s question: the password changed, MFA is on, and an unexpired AI login session or a plaintext API key can still let someone else in. Anthropic signed out the old cards. Okta counted the tokens that were still alive on the day the dump went public. A session list is a place to check. It is a poor place to assume “I already changed the password, so this is over.”

FAQ

I changed the password. Can the other person still get in?

They cannot use the old password at the login box. That is not the same as every session already issued dying at once. Trust the list you refresh under signed-in devices. Okta describes replaying an unexpired token as skipping the password and MFA. Revoke sessions, then change the password. Do both. Do not do only the step you remember.

Does MFA or a passkey stand in for a one-time link?

No. MFA and a passkey guard the login box. A session token proves “already signed in.” Anthropic’s notice also framed the problem as stolen sessions, not guessed passwords. To check “did the server see anything besides ciphertext,” use a one-time link and Network. Do not substitute “I turned on a second factor.”

How is a full one-time URL in .env better than the API key itself?

Server logs and HTML-only previews usually cannot see the key after #. The local file, editor history, and an infostealer log can still hold the whole URL. Whoever copies it can open it before it burns. Safer: put only the id in the file; send the key on another channel. The key itself still needs a revoke path and a usage cap.

Do create and read need an account? If I send the wrong channel, can support recover it?

No sign-up. Create and read are public to a visitor. After ciphertext burns by count or expiry, there is no server-side plaintext backup and no support inbox that can recover it. Generate a new password and a new link. Do not keep refreshing the same URL to see if it comes back.