Any idea if store and retrieval (export the symmetric key out of keyvault) of symmetric keys is supported in Azure Kev vault or possible? I referenced Azure Keyvault documents here and it mentions the Symmetric keys are not supported and may be supported in future (not sure though if the documentation I read is current).
If it’s not supported, is there a way to simulate this using other interfaces like Secrets? Could you share a sample code to do this using Azure Keyvault REST API?
You are right about storing the symmetric keys as secrets.
REST API
Here is a detailed article around the code involved to do this using REST API
http://thuansoldier.net/7329/
.NET SDK
Here is the nuget package
https://www.nuget.org/packages/Microsoft.Azure.KeyVault/
You can use the KeyVaultClient class and GetSecretAsync method.
Here is an example on Microsoft Docs - https://learn.microsoft.com/en-us/azure/key-vault/key-vault-use-from-web-application
Similar SDKs are available for Node.js, Java and Python
Related
I have few API keys in my Xcode project, for ex. google API keys, fabric key, contentful SDK key, etc.
I'm worried about those keys to be leaked from my build, Because they are not free versions, I've been paying according to it's usage.
I found on research that some people can do reverse engineering on IPA file (XCode build) and they can extract API keys from code/plist files, and use them.
Que-1. Is there a better way I can protect my all API keys?
Que-2. Is there other place to put my API keys, instead of .plist file.
Que-3. Does Firebase provide features to store all API keys to cloud and access them directly. if yes, please guide me.
Thanks for your help in advance.
Hardcoded keys can not be extracted by Reverse Engineering. So, hardcode your API keys in your code
Hardcoded keys can not be extracted by Reverse Engineering
If you want, you can use Firebase Remote Config to store API keys on Firebase
My current customer has secrets stored in Blob Storage and we want to propose them to migrate to KeyVault. May I know what are the benefits or storing secrets into KeyVault as compared to Blob?
When I read the documentation, KeyVault uses the HSM to protect the keys and secrets but Blob also uses the encryption which is also secure. so what are the other advantages?
I'd say that in general they look very similar, however I'd say the most important difference between the two would be the authorization model.
Access to a storage account is done by one of the two available connectionstrings/keys. Access to a KeyVault can be assigned directly to users or groups (from AAD) and the access to resources within the Key vault can be configured with more granularity. Next to that it is very easy to limit the type of resources from within azure that may or may not retrieve data from a KeyVault, reducing the attack service.
Storage accounts do have AAD integration currently in preview, but what i gather is that that is mostly focusing on the Azure file share functionality (https://learn.microsoft.com/en-us/azure/storage/files/storage-files-active-directory-overview).
Another nice differentiation is definitely the integrations that are already available when using KeyVault (i.e. Retrieving Azure DevOps secrets directly from a KeyVault or automatically retrieving Certificates for VMs)
FYI, i'm by no means a KeyVault expert but that's just my 2 cents :)
I'm attempting to make online predictions using https://ml.googleapis.com/v1/projects/<project>/models/<model>/versions/<version>:predict?key=<mykey>
I created a service account with full ML Engine Admin access, then generated an unrestricted API key. Many of Google's online docs mention ?key= as a valid auth method for their APIs. Can anyone confirm that this is supported by ML Engine today?
I was able to make the same request using Authorization: Bearer <access token> with my own personal access token, but I do not want to do that. Additionally, the request will ultimately be made via PHP, and the client libraries for PHP currently do not support ML Engine yet.
Thanks
It's not supported by CMLE Online Prediction.
There is a list of supported GCP services here: https://cloud.google.com/docs/authentication/api-keys
I'm creating an app using yodlee api, so far everything good, but right now, I'm having this block related to the PKI feature of yodlee. I'm not able to encrypt the data using "RSA/ECB/PKCS1Padding" as they request, all I found so far are java examples, anyone with a snippet of code, or a reference to make this possible on ruby?
I guess you are referring to this manual to integrate Yodlee API with PKI feature.
Have a look into the ruby's OpenSSL classes. Encryption using RSA is possible with the OpenSSL::PKey::RSA class, see also this intro doc. Basically you have to load the public key returned from the API, and use the public_encrypt method to encrypt the data and hex-encode it in the end. The encryption uses the PKCS1_PADDING by default which is just what you want.
A complete example is available in this SO answer.
I am looking into creating a desktop app in an interpreted language that accesses Google's APIs. From what I can tell, there is a security hole. The client secret would be exposed within the code, and even if I created the application in C++ or Java, the code could be decompiled\disassembled and the secret could in theory be found. Is there anyway around that besides obfuscating the code? I'd like to be able to distribute the code for others to use.
OAuth 2.0 Threat Model and Security Considerations(rfc6819) has listed Obtaining Client Secrets as a threat.
And as Google doc Using OAuth 2.0 for Installed Applications says:
These applications are distributed to individual machines, and it is assumed that these applications cannot keep secrets.
So there are no Client "Secrets" in fact. Trying to obfuscate a secret in installed applications is a futile effort as the secrets can always be recovered using the abundance of reverse-engineering and debugging tools.
Of course, you should do your best to protect secrets but at the end, a highly motivated hacker can always get it in an installed application. So it's the value of the secret vs. difficulty of extraction. The value of the client secret is impersonating the application. It doesn't give any access to user data.
My suggestions:
Just take the risk go ahead and obfuscate it. Or you can
consider using the proxy pattern(move the secret to a web server acting as an API proxy).