Azure-sdk-for-net: Azure KeyVault client should support SecureStrings

[kamranayub]

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.

``` c#
var secret = await _keyVaultClient.GetSecretSecureAsync(secretId);

var value = secret.SecureValue;
```

[herveyw-msft]

@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.

[danutzplusplus]

I don't mean to revive this thread from the grave, but I'm just wondering about the provided answer.
I'm no security expert, which is why I'm asking, but shouldn't security be built in layers, in depth? Meaning you need measures in place if the security boundary of the process is breached.

In the scenario where the client that calls into AKV is hosted on a server, I guess those risks are better managed, but what about a scenario where the client is hosted on a regular desktop machine? I think that scenario would benefit from not having the key-vault values in the clear, in memory.

And of course, you could make the argument that in that case the developers could just as easily mismanage the SecureString and expose them as regular strings. But I'd imagine having more safeguards is better. Having the AKV API return a SecureString and not a string would definitely be an alarm bell for me, in that I have to be careful how I manage that.

[danutzplusplus]

Also, would you see any strong reason not to wrap the in-the-clear string in a SecureString on the abstraction that I'm writing over the AKV API? Even with all the caveats mentioned above, I still particularly like the deterministic garbage collection you can trigger with .Dispose() on SecureString, and find that a minimal, but very cheap improvement. Do you think that I shouldn't even bother?

[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.

[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).