As explained in the article this wouldn't work, because changing your org means your stored hash is no longer valid (as the org is incorporated in the hmac), and you can't generated your own hashes because you're missing the pepper. So after changing your org all subsequent requests would fail.
Yeah, if user -> org tenancy is stored in the same database without any similar defence in depth then a fresh API key after updating org would work around this.
Would be a interesting topic for them to cover.
I think the same HMAC(pepper, user, org) as a validation column would work.
Better yet, encryption with AAD on any tenancy data if you have a TPM available.
Comments
As explained in the article this wouldn't work, because changing your org means your stored hash is no longer valid (as the org is incorporated in the hmac), and you can't generated your own hashes because you're missing the pepper. So after changing your org all subsequent requests would fail.
But logging in gets you a new hash with your new org id, right?
Yeah, if user -> org tenancy is stored in the same database without any similar defence in depth then a fresh API key after updating org would work around this. Would be a interesting topic for them to cover.
I think the same HMAC(pepper, user, org) as a validation column would work. Better yet, encryption with AAD on any tenancy data if you have a TPM available.