Page MenuHomePhabricator

Improve authentication revocation behaviors
Closed, ResolvedPublic

Description

See PHI304. Requests to cycle/revoke credentials have been rare and we have limited support for automating it, but should improve support.

Currently, we have bin/auth revoke but it supports only Conduit revocations. This should be expanded; specifically:

  • Add a temporary token revoker.
  • Add a session revoker.
  • Add an SSH key revoker.

Then:

  • Password hashes are stored on the user object. VCS password hashes are stored in RepositoryVCSPassword. These would probably be better if moved to a central password table with a role column.
  • Passwords can be removed, but can not be revoked (i.e., forcing users to change passwords). This table should also be able to store revoked passwords.
  • Add a password revoker.
  • Add a VCS password revoker.

Additionally (see T7148):

  • When instances are exported from Phacility, we currently do not strip VCS passwords, but should.
  • When instances are exported from Phacility, we currently do not strip Conduit tokens, but should.
  • Ideally, this workflow should just use bin/auth revoke to reduce code duplication.

Errata:

  • Is AuthTemporaryToken->userPHID used by anything?
  • VCS passwords should respect account.minimum-password-length.
  • While I'm here, we could add a rate limit to "Change Password" to stop occasional researcher reports about this.
  • When SSH keys are revoked with bin/auth revoke, the email should probably exclude the "your account may have been compromised" warning.
  • Write some documentation.
  • Carve a pathway forward on the legacy digest algorithms.

Revisions and Commits

Restricted Differential Revision
rP Phabricator
D18929
D18928
D18916
D18911
D18910
D18908
D18907
D18906
D18904
D18903
D18902
D18901
D18900
D18899
D18898
D18897
D18896
D18895
D18894
D18893
D18892
D18891

Event Timeline

epriestley triaged this task as Normal priority.Jan 20 2018, 4:42 PM
epriestley created this task.

See D17458 for the previous, narrower case of token revocation in response to Heartbleed (T12313).

epriestley updated the task description. (Show Details)Jan 20 2018, 4:52 PM
epriestley updated the task description. (Show Details)Jan 21 2018, 11:16 PM
epriestley updated the task description. (Show Details)Jan 22 2018, 12:50 AM
epriestley updated the task description. (Show Details)Jan 22 2018, 12:53 AM
epriestley updated the task description. (Show Details)Jan 22 2018, 1:20 AM
epriestley added a revision: Restricted Differential Revision.Jan 22 2018, 1:34 AM
epriestley closed this task as Resolved.Jan 23 2018, 11:43 PM

Add a temporary token revoker.
Add a session revoker.
Add an SSH key revoker.
Add a password revoker.
Add a VCS password revoker.

These have been added.

Password hashes are stored on the user object. VCS password hashes are stored in RepositoryVCSPassword. These would probably be better if moved to a central password table with a role column.

VCS and account passwords are now stored in PhabricatorAuthPassword and share much more code.

User objects no longer contain password hashes or salts in object properties, theoretically reducing the risk of this material leaking via stack traces and debugging mechanisms.

Passwords can be removed, but can not be revoked (i.e., forcing users to change passwords). This table should also be able to store revoked passwords.

Passwords can now be revoked so that users may not select the same password again.

When instances are exported from Phacility, we currently do not strip VCS passwords, but should.
When instances are exported from Phacility, we currently do not strip Conduit tokens, but should.
Ideally, this workflow should just use bin/auth revoke to reduce code duplication.

We now strip all this stuff and use bin/auth revoke where it makes sense (pending an actual production test).

Is AuthTemporaryToken->userPHID used by anything?

Yes, LFS uses this. This column name is slightly confusing but since it has a legitimate callsite I'm keeping this pecularity out of scope.

VCS passwords should respect account.minimum-password-length.

All password controllers now use the same validation logic and respect account.minimum-password-length (D18902).

While I'm here, we could add a rate limit to "Change Password" to stop occasional researcher reports about this.

This action limit has been installed (D18906).

When SSH keys are revoked with bin/auth revoke, the email should probably exclude the "your account may have been compromised" warning.

This warning is no longer included in the related mail (D18907).

Write some documentation.

Penned thusly (D18911).

Carve a pathway forward on the legacy digest algorithms.

New VCS and Account passwords are digested in a modern, simple way with HMAC SHA256 and a password-specific salt.

Old passwords are automatically upgraded the next time they are used. This is similar to the existing logic to upgrade hashers if a better hasher becomes available.

Old passwords that are never used can not be automatically upgraded via migration (we can't reverse the hashes). For now, we've versioned them and retained the older digest logic so they'll continue working. We may remove this logic and break these credentials at some point far in the future. If we do, users will need to reset any passwords they haven't used in a year or some similar timeframe.

Broadly, with the minor exception of the legacy digests, I think our password infrastructure no longer has any unusual components or odd technical choices. It was more or less satisfactory before and I think we got all the stuff with any real security impact right, there were just a few weird bits -- like usernames as salt for passwords, so that changing usernames broke passwords -- which are no longer weird.