Revoking a Leaked Credential

Rotation and revocation are different jobs. Rotation replaces a credential on a timetable. Revocation ends one immediately because it may already be in the wrong hands. When a leak is suspected the urgent job comes first, and the tidy scheduled work can follow later.

Revoke at the source

Revoke the credential where it is issued, not where it is used. Deleting a local copy or editing a config file leaves the value valid at the provider. Some systems issue short-lived tokens, so also end any session that was minted from the leaked value.

Test that it is dead

A revocation message in a console is not proof. Attempt a call with the old value and confirm it is refused. If the provider caches authorisation, allow a short window and test again before closing the incident.

def confirm_revoked(call, old_credential):
    # a revoked value must now be refused
    result = call(old_credential)
    return result.status in (401, 403)

Sweep every copy

A credential leaks through copies: a script, a config, a chat log, a build file. List everywhere the value was placed and treat each as compromised, then replace the value in those places. Logs that contain the raw value are also in scope.

Tips

• Revoke at the issuer, then retest with the old value before calling it done.
• Keep credentials short-lived so a leak has a small window in which to work.
• Search configs, scripts and logs for the exact value, not just the main host.
• Gotcha: editing a config file does not revoke anything at the provider.
• Gotcha: sessions already opened with the leaked value stay valid until they are ended too.