argon2_secret, hmac_secret, jwt_secret

[fdr]

Hello everyone,

I've been wondering about rotation methodology (and consequences) for some of the various *_secret parameters to RodAuth:

• argon2_secret
• hmac_secret
• jwt_secret
• Roda's plugins :sessions, secret: parameter.

Which, if any, of these secrets can be shared between these settings? And in each case, what are the disparate consequences of changing the value? This may inform what level of key sharing, if any, is advisable...plus necessary work to rotate the secret value.

Thanks.

[jeremyevans]

My recommendation would be to use a different secret for each, though I doubt there is any security issue of using the same secret for all. In my own apps, I generally have a base secret and create the other secrets using an HMAC of that.

The Roda sessions plugin secret supports rotation using the :old_secret option. Sessions are short lived by default, so rotation is feasible. None of the rodauth secrets currently support rotation.

It looks like jwt_secret could support secret rotation with minimal changes (since JWT.decode) supports it, and it may make sense for that as JWT is usually time limited anyway.

argon2_secret affects the stored hashes. Without automated closing of inactive accounts (which Rodauth does not implement, though the user can do so), you cannot feasibly rotate the argon2_secret. You could use the new secret for new hashes, but could not stop using the old secret until all password hashes were updated to the new secret. However, assuming you were willing to automatically close inactive accounts (or at least remove the password hash for them), I think it would be possible to support rotation by automatically saving an updated password hash with the new secret upon successful authentication (similar to how the update_password_hash feature works).

hmac_secret is used for a number of separate features. Looking at everything this is used for, it may be possible to support rotation for each of them.

Adding support for rotation is not a trivial change. Every place where a secret is used has to be modified separately to support rotation. However, I'm certainly open to making this change.

[fdr]

Okay, so, I thought about this a little longer. I think the rotation that stands out the most and perhaps is better allowed separately is TOTP.

While it's generally accepted that passwords will be forced to change once a year, and verify links are transient enough to accept some inconvenience for timeliness, the stakes for TOTP rotation are so much higher: nobody expects to do it ever, from what I can tell.

[jeremyevans]

otp_keys_use_hmac? already exists so you can disable the use of HMAC for OTP keys. :)

[fdr]

Can I specify the TOTP hmac secret separately? Then the more-generally-accepted-as-dynamic stuff can be rotated, and TOTP can be rather painfully transitioned somehow (I suppose, like column encryption, this ends up being some kind of versioning, but I can see why this may be too invasive for most users of rodauth?). But the overall result will be more robust to a straight database spill without getting environment variables also.

[jeremyevans]

Currently no, but that's not a difficult change to make. Please submit a pull request if you would like that.

[fdr]

Okay, I'll wait on it for a while, but I'll remember your favorable impression of submitting this change.