5

I am using Azure's KEY vault to store encryption keys and handle encryption and decryption as we have a specification that requires encryption keys to be kept offsite, however this has left me with the problem of what to do with the access_token I have received from azures Oauth process.

Common sense tells me I should encrypt this token when stored in the database however I cant do that as the encryption function on azure requires the token to perform encryption and decryption therefore cannot be used to encrypt itself.

It seems all I have done is move the goalpost, I no longer have the encryption key stored in a database, instead I have an access token that can be used to decrypt the data anyway. I have to store client_id and client_secret un_encrypted for the same reason.

Am I missing something here?

Improve this question
3
  • Isn't the access_token a session token? It only proves that you authenticated so you shouldn't have to store it. You still have to access the client ID and secret, those should be passed as secrets to your application and not persisted on the machine (eg: keywhiz, kubernetes secrets, etc...).
    – Marc
    Dec 19, 2017 at 15:58
  • You suggest the use of keywhiz, kubernetes etc for storing secrets but this is the whole point of azure, to store secrets and use keys in azure you need client_id and client_secret and access codes etc but how do you protect those as you need them to access the 'secrets' and ;encryption' functionality of azure.
    – Rob Holmes
    Dec 21, 2017 at 14:14
  • They're different. keywhiz and kubernetes secrets are deployed side-by-side with your application. This means that the host you run your application on will have the secrets available to local processes (usually restricted by system username). Even then, the whole point is that you always have some secrets to pass, it's better for it to be tokens that can be revoked rather than encryption keys.
    – Marc
    Dec 21, 2017 at 14:27

1 Answer 1

Reset to default
1

I am not sure whether the access_token that you have received from Azure Authentication has permanent lifetime. I am assuming it is not. Either way, you still need to have client_id and client_secret to get the access_token, and that means you should instead focus on securing the client_secret or finding the alternatives.

Instead of using client_secret to authenticate, you can use client certificate authentication as explained in this documentation: Authenticate with a Certificate instead of a Client Secret.

Key Vault Client Certificate Authentication Image

In the picture above, the developer does not need to know the private key value of the certificate in order for their app to be successfully authenticated to Azure Active Directory. Instead, they only need to know the location of the imported pfx in the Certificate Store.

At least on Windows, you as secret administrator can convert the private key and the certificate into pfx format which is password protected, and then deploy it into the Windows Certificate store. This way no one could know the private key unless they know the password of the pfx file.

The other approach specifics for Azure Compute, is to use Azure Managed Service Identity. Using Azure MSI, Azure will automatically assign your resources such as VM with an identity / Service Principal, and you can fire requests at a specific endpoint that are only accessible by your resource to get the access_token. But be wary that Azure MSI are still under public preview, so please review the known issues before using it.

Azure Managed Service Identity Image

The picture above explain how Azure Resource Manager assign a Service Principal identity to your VM.

  • When you enable MSI in a VM, Azure will create a service principal in your AAD.
  • Azure will then deploy a new MSI VM extension to your VM. This provides an endpoint at http://localhost:50432/oauth2/token to be used to get the access_token for the service principal.
  • You can then use the access_token to access the resources such as Key Vault which authorize the service principal access.
Improve this answer
1
  • 1
    In addtion to protecting the PFX with a password, Windows allows to mark the private key as non-exportable. This means once the client certificate was imported to the local machine, it is very hard to extract. So even if the machine is attacked, it's unlikely that Key Vault credentials get stolen.
    – fernacolo
    Apr 15, 2018 at 7:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .