mirror of
https://we.phorge.it/source/phorge.git
synced 2024-11-24 07:42:40 +01:00
9c00a43784
Summary: Ref T13043. Currently: - Passwords are stored separately in the "VCS Passwords" and "User" tables and don't share as much code as they could. - Because User objects are all over the place in the code, password hashes are all over the place too (i.e., often somewhere in process memory). This is a very low-severity, theoretical sort of issue, but it could make leaving a stray `var_dump()` in the code somewhere a lot more dangerous than it otherwise is. Even if we never do this, third-party developers might. So it "feels nice" to imagine separating this data into a different table that we rarely load. - Passwords can not be //revoked//. They can be //deleted//, but users can set the same password again. If you believe or suspect that a password may have been compromised, you might reasonably prefer to revoke it and force the user to select a //different// password. This change prepares to remedy these issues by adding a new, more modern dedicated password storage table which supports storing multiple password types (account vs VCS), gives passwords real PHIDs and transactions, supports DestructionEngine, supports revocation, and supports `bin/auth revoke`. It doesn't actually make anything use this new table yet. Future changes will migrate VCS passwords and account passwords to this table. (This also gives third party applications a reasonable place to store password hashes in a consistent way if they have some need for it.) Test Plan: Added some basic unit tests to cover general behavior. This is just skeleton code for now and will get more thorough testing when applications move. Reviewers: amckinley Reviewed By: amckinley Maniphest Tasks: T13043 Differential Revision: https://secure.phabricator.com/D18894 |
||
---|---|---|
.. | ||
PhabricatorAuthMainMenuBarExtension.php | ||
PhabricatorPasswordDestructionEngineExtension.php |