Hiding HMAC-SHA256 in source code and configuration file

Question

Would it make sense or provide an advantage of sorts to break a HMAC-SHA256 secret key into two components and hide one component in an applicable server side configuration file and the other component in (closed source, server side) compiled code?

I would choose both half's to be long enough that they individually contain enough entropy to ensure that even if the other half of the key is compromised, the other half of the key remains too long/complex to be brute forced. For example, each half is 32 crypto-sudo-random bytes that are concatenated to form the full secret key.

I understand generally it is not recommended to hide secret keys in source code as source code is difficult to keep secret, but I cannot see anything but advantages by employing this. If the source code key is stolen, the configuration key is still hidden and too long to be brute forced. Alternatively, if an attacker manages to steal the configuration key but does not keep a copy of the compiled source code's key, they still cannot forge the JWT tokens signatures.

Therefore my question is: Am I over looking some sort of obvious flaw in this design or does it truly provide at least a little bit better security? Furthermore, if there is no obvious flaw, is it reasonable to believe this truly does add to the protection of the secret key?

Answer 1

Based on your description you essentially split the secret into multiple pieces and place these in different locations. And these parts are complex enough so that an attacker needs to find all pieces to succeed, i.e. it is not possible to find only some parts and then guess the remaining secret.

If in this scenario at least one of these location is protected with the same strength as you would traditionally protect the full secret then this split-secret system is not less secure compared to the traditional full-secret system and it might be even more secure. If instead you think that just by splitting the keys the system gets more secure and care less about securing each piece than you would have cared for the full secret then the split-key system might actually be less secure.

From your description it is impossible to know how well the parts of the secrets are protected. Source code might be stolen depending on how well protected it is or the code might be reverse engineered depending on how much effort was taken to obfuscate the secret in the code. Similar a configuration file might be easily accessible or not. It is also not known how critical the secret actually is and how much protection it needs. For example in some use cases it makes more sense to change the secret often than to invest too much effort into the long-term protection of the secret. And a secret which depends in part on the source code might be less flexible in such cases.