Azure KeyVault client should support SecureStrings

Although it is unlikely an app inside of Azure would be compromised at the process memory level, it still would be nice if the Key Vault client supported returning a SecureString for the value of the secret.

var secret = await _keyVaultClient.GetSecretSecureAsync(secretId);

var value = secret.SecureValue;

[daviburg]

@kamranayub We have certainly considered this, however it might simply be theatre; the AKV SDK is built on a number of layers, including .NET HttpClient, the Hyak layer, JSON.NET and each of these “touch” requests and responses in one or more ways, as either byte[] or string, in the process’ memory. As you note, today, you should consider the process to be the security boundary and secure it appropriately.

Dear colleague, layered security principle is that security risk mitigations complement each other, rather than the argument that o-well-other-layers-didn’t-plug-the-hole-so-why-would-we? If the assemblies you are using don’t have native support for SecureString serialization, that’s exactly where you Key Vault as a service for secrets need to pass them only an encrypted payload which when you do decrypt is kept immediately in a SecureString (CryptoStream byte by byte to SecureString followed by dispose to purge the buffers from memory).

[danutzplusplus]

Also, what’s even more interesting is that the DocumentClient (for cosmosdb) constructor accepts the masterKey as a SecureString. Is there a different way of getting the cosmos masterKey as a SecureString that I’m missing? (from Azure Key Vault, I mean). Not locally via Service Fabric.