mirror of
https://we.phorge.it/source/phorge.git
synced 2024-12-24 06:20:56 +01:00
d450a08890
Summary: Ref T12509. This adds support for HMAC+SHA256 (instead of HMAC+SHA1). Although HMAC+SHA1 is not currently broken in any sense, SHA1 has a well-known collision and it's good to look at moving away from HMAC+SHA1. The new mechanism also automatically generates and stores HMAC keys. Currently, HMAC keys largely use a per-install constant defined in `security.hmac-key`. In theory this can be changed, but in practice essentially no install changes it. We generally (in fact, always, I think?) don't use HMAC digests in a way where it matters that this key is well-known, but it's slightly better if this key is unique per class of use cases. Principally, if use cases have unique HMAC keys they are generally less vulnerable to precomputation attacks where an attacker might generate a large number of HMAC hashes of well-known values and use them in a nefarious way. The actual threat here is probably close to nonexistent, but we can harden against it without much extra effort. Beyond that, this isn't something users should really have to think about or bother configuring. Test Plan: - Added unit tests. - Used `bin/files integrity` to verify, strip, and recompute hashes. - Tampered with a generated HMAC key, verified it invalidated hashes. Reviewers: chad Reviewed By: chad Maniphest Tasks: T12509 Differential Revision: https://secure.phabricator.com/D17630
8 lines
366 B
SQL
8 lines
366 B
SQL
CREATE TABLE {$NAMESPACE}_auth.auth_hmackey (
|
|
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
|
|
keyName VARCHAR(64) NOT NULL COLLATE {$COLLATE_TEXT},
|
|
keyValue VARCHAR(128) NOT NULL COLLATE {$COLLATE_TEXT},
|
|
dateCreated INT UNSIGNED NOT NULL,
|
|
dateModified INT UNSIGNED NOT NULL,
|
|
UNIQUE KEY `key_name` (keyName)
|
|
) ENGINE=InnoDB, COLLATE {$COLLATE_TEXT};
|