recaptime.dev
@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.)
hq.recaptime.dev/wiki/Phorge
phorge
phabricator
1@title Revoking Credentials
2@group fieldmanual
3
4Revoking credentials, tokens, and sessions.
5
6Overview
7========
8
9If you've become aware of a security breach that affects you, you may want to
10revoke or cycle credentials in case anything was leaked.
11
12You can revoke credentials with the `bin/auth revoke` tool. This document
13describes how to use the tool and how revocation works.
14
15
16bin/auth revoke
17===============
18
19The `bin/auth revoke` tool revokes specified sets of credentials from
20specified targets. For example, if you believe `@alice` may have had her SSH
21key compromised, you can revoke her keys like this:
22
23```
24phorge/ $ ./bin/auth revoke --type ssh --from @alice
25```
26
27The flag `--everything` revokes all credential types.
28
29The flag `--everywhere` revokes credentials from all objects. For most
30credential types this means "all users", but some credentials (like SSH keys)
31can also be associated with other kinds of objects.
32
33Note that revocation can be disruptive (users must choose new passwords,
34generate new API tokens, configure new SSH keys, etc) and can not be easily
35undone if you perform an excessively broad revocation.
36
37You can use the `--list` flag to get a list of available credential types
38which can be revoked. This includes upstream credential types, and may include
39third-party credential types if you have extensions installed.
40
41To list all revokable credential types:
42
43```
44phorge/ $ ./bin/auth revoke --list
45```
46
47To get details about exactly how a specific revoker works:
48
49```
50phorge/ $ ./bin/auth revoke --list --type ssh
51```
52
53
54Revocation vs Removal
55=====================
56
57Generally, `bin/auth revoke` **revokes** credentials, rather than just deleting
58or removing them. That is, the credentials are moved to a permanent revocation
59list of invalid credentials.
60
61For example, revoking an SSH key prevents users from adding that key back to
62their account: they must generate and add a new, unique key. Likewise, revoked
63passwords can not be reused.
64
65Although it is technically possible to reinstate credentials by removing them
66from revocation lists, there are no tools available for this and you should
67treat revocation lists as permanent.
68
69
70Scenarios
71=========
72
73**Network Compromise**: If you believe you may have been affected by a network
74compromise (where an attacker may have observed data transmitted over the
75network), you should revoke the `password`, `conduit`, `session`, and
76`temporary` credentials for all users. This will revoke all credentials which
77are normally sent over the network.
78
79You can revoke these credentials by running these commands:
80
81```
82phorge/ $ ./bin/auth revoke --type password --everywhere
83phorge/ $ ./bin/auth revoke --type conduit --everywhere
84phorge/ $ ./bin/auth revoke --type session --everywhere
85phorge/ $ ./bin/auth revoke --type temporary --everywhere
86```
87
88Depending on the nature of the compromise you may also consider revoking `ssh`
89credentials, although these are usually not sent over the network because
90they are asymmetric.
91
92**User Compromise**: If you believe a user's credentials have been compromised
93(for example, maybe they lost a phone or laptop) you should revoke
94`--everything` from their account. This will revoke all of their outstanding
95credentials without affecting other users.
96
97You can revoke all credentials for a user by running this command:
98
99```
100phorge/ $ ./bin/auth revoke --everything --from @alice
101```