I'm facing the classic chicken/egg problem of where to store the keys to the kingdom.

I'm building an application for retail distribution that will rely on receiving a cadence of regularly-issued Let's Encrypt certificates via a central website's REST API. The website will perform the regular task of renewing and storing the certs in an Azure Key Vault, and then the individual installations will use the API at the appropriate intervals to download and store the certs locally. The application will be running as a Windows Service, and the connect/download sequence must be fully automated and without user intervention.

This arrangement presents two hazards:

  1. The vault's Client Secret
  2. The REST API credentials

I suppose the odds of an attacker obtaining for decompilation my Azure-hosted website's assembly are pretty slim, so hard-coding the Client Secret there might not be the worst thing in the world. But then again, it might be. I'm far from being a security expert, I must admit.

But it's the REST API credentials that've got me all worked up.

I certainly don't want to hard-code those at the application. However, the application is going to need them to connect to the website's REST API. What to do?

I thought for a moment about using client certificates, but that idea faces a similar problem—how to make sure the cert is getting into the hands of the correct person initially?

It's worth noting that each installation will be identified by a pre-assigned, unique, 7-character mix of digits and upper case letters, to be entered by the user at setup time. Perhaps I might be able to make use of that construct somehow.

Given this architecture, how can I reliably secure my application, website and key vault against a determined attacker wanting to obtain these secrets?

  • Your scenario isn't quite clear to me. If I understand correctly, you have a central server and customer-managed clients. You want to provision credentials like API tokens on the clients. What is your threat model here? Are you concerned about customers extracting credentials and using it for additional clients? Are you concerned about third parties hacking the customer's systems? While unfortunate, that shouldn't affect the security of your server.
    – amon
    Dec 11, 2023 at 9:19
  • "What is your threat model..." It seems you've identified a shortcoming in my presentation. Thank you. "Are you concerned about customers extracting credentials..." Yes, and using them to make unwanted REST API calls. "Are you concerned about third parties hacking the customer's systems..." Not as much. The biggest exposure to malice here is the Internet-facing field that accepts the 7-character code. The biggest risk is access to the Azure Key Vault, but as it turns out I can mitigate that with IAM.
    – InteXX
    Dec 12, 2023 at 1:48
  • If you give an API key to the customer (potentially by embedding that key into a binary) you cannot prevent the customer from using that key directly. Your security boundary must be server-side, not within an environment that is controlled by an adversary (and it seems you're treating customers as a potential adversary, which is wise). IAM might be part of such server-side checks. Also be careful of that 7-character key. That's only about 40 bits. This is OK for a PIN when combined with other checks like rate-limiting, but not for cryptographic purposes. API keys often use 256 bits.
    – amon
    Dec 12, 2023 at 17:22
  • Good advice, thanks. I'll take all of that under serious consideration.
    – InteXX
    Dec 13, 2023 at 5:04
  • I've been struggling with this one. A big problem: how can the API know whether it's my app or a malicious actor calling? I could embed some sort of unique ID in my code, but that's easy to defeat/discover via disassembly (.NET). I could further obscure that by putting the sensitive code into a native assembly, but then there has to be an entry point where execution flow leaves my app and enters the black box. Again, discoverable via disassembly. Even IAM suffers from this vulnerability—how to securely store the key locally and then prove that my app is the caller? It's a tough nut to crack.
    – InteXX
    Dec 14, 2023 at 21:03

2 Answers 2


As you say, you have a circular dependency - you want to store a password, but to do it securely, you need to protect it with a password. What do you do?

To break the chain, you need human intervention, but you can have that human intervention not be a part of the main data path, but as part of the setup path: have your service run in the context of a service account.

You specify the password once, when setting up the service - or better yet, you give your regular user account permissions to act as that service account, I'm not 100% what the Azure terminology for that is, but it's probably something along those lines - and protect your key vault using IAM permissions, not password authentication. The service now has permissions to access the key vault by virtue of the identity it's running under, and there are no passwords in play in your code or in the communication with the key vault.

  • I'm not sure which you're discussing here, the Azure side or the application/client side. When you suggest running the service under a service account, that sounds like Windows. But then you talk key vaults. Are you addressing both sides of the coin here?
    – InteXX
    Dec 11, 2023 at 7:52
  • 2
    Vault is used as a general "storage" here. Service is a general term for non-user facing software.
    – Basilevs
    Dec 11, 2023 at 18:55

OK, I believe I have the solution for the REST API problem.

As already established, the customer will be receiving his 7-character code via the US mails. This ensures correct identity.

The website will require that he enter his code during creation of his new account. Once the account is created—with email verification of course—he'll be prompted to download a license key file, which will contain the API credentials (or client cert, I haven't decided yet). I'll encrypt it using a combination of the code and something else (also TBD).

A setup dialog will prompt for the file, and the application will know how to decrypt it.

I believe that solves problem #2. Problem #1 remains.

What techniques do folks use to secure their Azure Key Vault credentials (esp. the Client Secret) for fully automated processes?


I believe I've found my second answer:


Cautionary comments from those who are better at this than I are welcome.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.