If you've lost the database, you've lost accountability for all user actions anyways. Everyone should be forced to reset their credentials.
Meanwhile: storing authenticators of API keys rather than the keys themselves precludes you from doing "request signing" with the keys in the future, since validating a MAC will require the preimage of the hash.
Generally: if you're concerned about survivability of systems after compromise, a better strategy for storing API secrets would be to compartmentalize them in a simple authentication server with a tiny attack surface (you could implement it with minimal state by doing a challenge-response protocol internally, so that the only interface exposed by the authentication server would be "does this message have a valid MAC").
> If you've lost the database, you've lost accountability for all user actions anyways.
Not sure I understand why. Is it because the (hashed) passwords are there too, or did you have an attack against the API keys in mind? Just to be clear, I'm thinking of an unsecured backup scenario, not full blown database compromise.
Regarding signing, that's a good point I hadn't considered, and maybe reason enough not to hash the API keys.
In my mental model, you lose the database to appsec flaws, not to opsec flaws with backups. Both things definitely can happen! I'd suggest though that losing your entire (auth) database to a compromised backup is a "reset all the API keys" moment anyways.
Remember: these services that provide API keys are invariably backed with some kind of login service that uses passwords. Even if you're hashing with scrypt, if you lose the password hashes, everyone's resetting creds.
Meanwhile: storing authenticators of API keys rather than the keys themselves precludes you from doing "request signing" with the keys in the future, since validating a MAC will require the preimage of the hash.
Generally: if you're concerned about survivability of systems after compromise, a better strategy for storing API secrets would be to compartmentalize them in a simple authentication server with a tiny attack surface (you could implement it with minimal state by doing a challenge-response protocol internally, so that the only interface exposed by the authentication server would be "does this message have a valid MAC").