For our portal development, we have decided to use Apigee to expose the web service to the portal. For which currently I am storing the API Key and Api URL in the properties file of the project. Can anyone help with some pointers on how else can I save the API key apart from the properties file.
Any pointers will be helpful in this case.
Regards
Aswathy
Typically the API key will be persisted by the the API consumer - usually an App of some kind. In case of Mobile Apps, each of them have an API Key or Client ID that is saved inside the app usually in some kind of secure data store. For other kinds of API consumers such as web apps the API Key may be persisted within a secure vault or an database that has some encryption features.
I assume your web portal app resides on a secure machine inside your enterprise and that this machine is access restricted. If this is the case bare minimum security is taken care of
However, If the key is a high privilege key and you can access APIs with key alone(ie without a secret), it is not advisable to keep it in plain text.
You can
1. Encrypt and store it in the config file and decrypt at runtime
2. Encrypt and store in Database or other secure storage you use for storing credentials.
Related
I need a little guidance on how to implement signing of documents in a web based document distribution system we are developing.
At its simplest, user A will be logging into the website and create a Data Package. Word/Pdfs can be added to the package. User A will sign this document(s) using a digital certificate. User A might assign this to other users for reviewing the documents. They may sign the documents as well.
Now I know how to digitally sign data with C#. What I don't know is how to generate a certificate when each user logs into the website. The site is secured with DigiCert certificate.
What approach should I take to generate a digital certificate for each user? Once I have a .pfx file I believe I can store it in the database and use that.. Any guidance on this matter will be greatly appreciated!
thanks
I take to generate a digital certificate for each user? Once I have a .pfx file I believe I can store it in the database and use that..
This is what I call "naive approach" (read simplistic). You consider to store (maybe even generate) keypairs for the users in a web application. The biggest isssue with this approach is that someone with low-level access to the system (admins) or if database is leakt could gain access to the user's private key. To have a secure solution (considering signing), the private key may not leave its user
Doing everything in a web environment, you may consider using SubtleCrypto or other client site libraries, however at this point of time I see no reasonable way to manage the keys for pure web apps. Maybe you can store the user's keys and certificate in a localStorage, but it leaves some space for mallignant scripts to leak the keys.
Many real life secure solutions are working with secure modules (e. g. crypo cards), unfortunatelly the web libraries have no access to the modules (usually exposed as pkcs11 interface). As a solution usually the signing piece runs as custom code on user's computer. Before it was ActiveX, Applet,.. now it is often a "driver" exposed as a web server bound to "localhost" so the signig service can be used as web api from web applications.
I am using .NET Core 2.0 and ASP.NET Core 2.0 for application development. The "test" application is a .NET Core Console application. The core code I am writing is a class library. Once proper testing. I choose to do this since I won't be putting this to use for awhile (it's replacing older ASPNET code).
Anyway, since I have to work with a LOT of API keys for various services I decided to use Microsoft Azure Key Vault for storing the keys. I have this all setup and understand how this works. The test application uses a test Azure account so it's not critical. And since this is replacing legacy code and it's in the infancy, I am the sole developer.
Basically, I'm running into this issue. There's not too much information on Azure Key Vault from what I can see. A lot of examples are storing the Client ID and Secret in a plain text json file (for example: https://www.humankode.com/asp-net-core/how-to-store-secrets-in-azure-key-vault-using-net-core). I really don't understand how this can be secure. If someone were to get those keys they could easily access stored information Azure, right?
The Microsoft MSDN has a powershell command that grants access (I lost the original link, this is closest I can find: https://www.red-gate.com/simple-talk/cloud/platform-as-a-service/setting-up-and-configuring-an-azure-key-vault/) My development operating system is Windows 10 and my primary server operating system is Debian.
How would I approach this?
Yes, you are right, the plain text config file could be used only during development, not for production purpose. And in general, available options depend on where and how you host an App.
If you have an Azure Web App, you have at least next built-in options (from the documentation):
add the ClientId and ClientSecret values for the AppSettings in the Azure portal. By doing this, the actual values will not be in the web.config but protected via the Portal where you have separate access control capabilities. These values will be substituted for the values that you entered in your web.config. Make sure that the names are the same.
authenticate an Azure AD application is by using a Client ID and a Certificate instead of a Client ID and Client Secret. Following are the steps to use a Certificate in an Azure Web App:
Get or Create a Certificate
Associate the Certificate with an Azure AD application
Add code to your Web App to use the Certificate
Add a Certificate to your Web App
You may also find an approach that uses env variables to store credentials. This may be OK only if you can guarantee that it's not possible to do a snapshot of env variable on prod machine. Look into Environment Variables Considered Harmful for Your Secrets for more details.
And the last one thing: there is also a technic that based on the idea, that you need to store/pass only a ClientSecret value while ClientId should be constructed based on machine/container details where the App is hosted (e.g. docker container id). I have found an example for Hashicorp Vault and an App hosted on AWS, but the general idea is the same: Secret management with Vault
In addition to the first answer, with the context of running applications on Azure VM, 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.
In the picture above:
Application is authenticating to AAD by proving that it has the private key of the certificate (which is basically stored in CNG if you are using Windows).
Application get back the access_token and then use it to access the Key Vault.
The developer does not need to know the private key value of the certificate in order for their app to be successfully authenticated. Instead, they only need to know the location of the imported pfx (a container for private key and its certificate) 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.
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.
I have to create a banking application using Spring MVC and MySQL enterprise database. Encryption and Decryption of data are done using keys provided by MySQL Enterprise database. Some of the options that I have found to secure this database credentials are:
Storing credentials in key store - but I want keys to be stored out of service code
Using Azure key store or Azure App Settings - but I am looking for a free source
Using Hashing - Still, the keys are inside service code
Using self-signed certificates - Again these certificates have to be deployed, which may be insecure
Now how can I store this database credentials out of service code?
A common and difficult problem, I recommend https://www.vaultproject.io/ by Hashicorp.
I am developing an asp.net web api app, and using OWIN and identity to implement oauth for my aplication security. For each registered user, I also save a client id and hash as described here. But I dont want other developers be able to use my api and create their own app using the client id (and other credentials) they have.
Is it possible ?
First thing first, you have to encrypt your network traffic between mobile device and API. Because attackers can obtain sensitive data (which is API Token in this case) via proxy . Also you need to do SSL Pinning because of you need to be sure about public key is yours, otherwise attackers manage to get sensitive data again with same method. ( Please check out : https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning )
You shouldn't authenticate users with username/password. I suggest to you use api key, therefor you can send user actions to server side like following patterns.
https://example.com/api/APIKEYOVERHERE/action
Als you can watch this talk about Secure Your API - Tips for REST + JSON Developers.
https://www.youtube.com/watch?v=FeSdFhsKGG0
I am trying to make an ASP.NET MVC Azure-hosted website role that allows third-party authentication.
The client might not want me to add SQL server since it costs money, and I can cut back since all of my data comes from CRM. My problem is that DotNetOpenAuth, the library that supports the authentication, appears to require some database tables for storage. However I do not want to use any storage since I want to put all my data (and the auth token) in CRM.
1) If I don't use DB to persist the token, then is it a good idea to use encrypted cookie/server-side sessions? What do I have to modify?
2) Is in-memory, non-DB sessions from 1)* scalable in Azure?
3) Is there any way to make DotNetOpenAuth (WebSecurity class) work without relying on a db?
DotnetOpenAuth doesn't require database, you provide your own implementations of few interfaces, nowhere db is required.
Tokens are not persisted. Instead, tokens contain username and scopes encrypted with a private key of the authentication server. This way all you need is the public key in the resource server to decrypt the token (the ICryptoKeyStore interface).
You could as well persist keys in the filesystem or elsewhere.