I'm trying to replace an old Java applet that was used for digitally signing data in an ASP.NET application.
I'm trying to access the private key from the client certificate, sign some data, and send the signed data back to the server.
I've been looking at PKI.JS, but if there is a C# way to accomplish this with Blazor that would be one less external dependency.
This is doable with fortifyapp.com
I’m searching the solution for this. My idea is to save the the signing data to a local folder in client machine. My c# signing app,which is locally installed on client computer monitors the folder and perform signing. After that it put the signed data to an Azure blob storage and notify browser via Azure Event Grid.
Everything related to the signing is my c# code.
Related
I have a .net WEB API publicly exposed and also a Xamarin Forms App which uses the API, the app needs to be extremely secure due to the data it manages.
I will create an HTTP Certificate for the WEB API.
The Xamarin Forms app will have a login/password to validate against a local Active Directory. via a /token endpoint, and using an Authorize attribute on all endpoints to assure that every HTTP call has the bearer token in it, I implemented that using this:
I based my implementation on this one:
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
Additionally the customer has asked us for Client Certificate Authentication, I dont understand how this totally works.
1. I need to add a certificate to the Xamarin Project, right? How do I Add it? How do I generate it?
2. In the Web API I need to validate each http call has the certificate attached.
I found this but not sure if it will work:
http://www.razibinrais.com/secure-web-api-with-client-certificate/
However when investigating this, I also found something about certificate pinning, which is basically security but the other way around, it means the Xamarin APP will validate if the server certificate is associated with the right server (or something like that), so there is no way of a MAN IN THE MIDDLE Attack.
I found how to implement it here:
https://thomasbandt.com/certificate-and-public-key-pinning-with-xamarin
Question is:
1. Do I need both ?
Something else that I should research for on this journey?
Certificate pinning and Client Certificate Authentication are 2 very different things. Certificate pinning makes sure your app is talking to the server it expects to talk to. It also prevents eavesdropping, which is known as a 'Man in the middle' attack. I just recently wrote an article about this on my blog.
Client Certificate Authentication works the other way around. It adds an extra layer of security so your server can be sure only clients that have the certificate can communicate successfully with it. However, since apps can be decompiled without a lot of effort, this client certificate can 'easily' be obtained by a malicious user. So this isn't a silver bullet.
From my experience, Client Certificate Authentication is often used in enterprise apps, when there is an Enterprise Mobility Management solution in place (eg. Mobile Iron or Microsoft Intune or others), where the EMM solution can push the certificates to the users device out of band.
Should you use both? That really depends on the requirements of your customer, since they mitigate 2 very different problems.
The Web API link you included looks like it should do the server job properly at first sight. This article also includes how to generate a client certificate with a Powershell command.
Generating a client side certificate:
Use the Powershell command in the article that you referenced in your question.
Otherwise, this gist might help you on your way.
Installation:
Add the certificate file to each platform specific project as a resource. This is usually done in the form of a .p12 file.
Usage:
That all depends on which HttpClient you are using.
If you use the provided Web API solution, you should add the certificate contents as a X-ARR-ClientCert header with each request.
Here's what I am trying to accomplish:
We have files stored in azure blobs and need to secure access to them so that only our installed Windows 8 Store App can download these blobs. My first thought was to use some sort of certificate. When the app is installed, it is installed with a certificate that it then passes in the header of the request to he server to obtain the blob.
I read about Shared Access Signatures and it kind of makes sense to me. It seems like an API that the client could use to obtain a temporary token granting access to the blobs. Great. How do I restrict access to the API for obtaining SAS tokens to only our installed client apps?
Thank you.
Using SAS urls is the proper way to do this, this way you can give up a specific resource for a limited amount of time (15 minutes for example) and with limited permissions (only read for example).
Since this app is installed on the users machine you can assume the user can see whatever the App is doing so there is no absolute way to secure your API to only be accessed by only your App, but you can make it a little more difficult to replicate by using SSL (https) endpoint and providing some "secret key" only your App knows.
My server must receive data from a number of devices who have downloaded my application through an app store or otherwise trusted channel. I need a method to verify that data my server receives is actually from these devices. The server does not have access to a list of these devices ahead of time.
What are some popular ways to accomplish this?
Depends on the platform. The accepted answer to the linked question offers the idea (of using SSL for authentication).
I'd like to add to that answer, that if the client has some API with non-exportable private keys (either hardware-based or encrypted like CryptoAPI certificate storage in Windows), then you can store client certificates there.
I'm building a web application that builds a XML document based on the user input. After the doc is created, it needs to follow an approval path, e.g. a workflow, where several users "sign" the document. The signature from the user point of view is just checking a field and clickin "accept", but what I need is for the document to be digitally signed in each step, to
finally store it signed in a database.
What kind of devices/tools do I need to use? X.509 certificates on the client browser? Public/Private keys generated by the app? Any link to documentation will be appreciated.
Certificates are not normally generated by the application (since PKI is about trust, which is hierarchical in case of certificates). Users acquire certificates with private keys (let's say so for simplicity) and store them in the safe place or on hardware devices (smartcards, USB tokens).
Then those certificates are used to sign information. In case of web application you can either transfer the data itself to the client or send a hash of the data there, but in any case signing takes place on the client side (except rare cases where certificates are stored on central server and access to them is authorized by the client each time the certificate is used).
We offer components for distributed signing of data. This answer contains detailed description of how such signing works. You can use our solution or create your own, that will do the same.
What are the best practices for delivering an Adobe Air app that needs a private key in order to communicate with some online API?
Adobe Air apps seem like they are delivered to the user with full source code, so storing any keys within the source would be a really bad idea. I've read some suggestions saying to download the key from your server, but that has the same problem because the url allowing the download would have to be stored in source code. Also, suggestions saying to store in the encrypted local storage don't make sense to me either, because I still have to obtain the private key somehow.
I think this is a global problem of delivering secret keys in any application, since everything can be reverse-engineered (disasamble for executables, IL readers, etc.)
No matter what you do, if the client application needs to somehow "know" a secret key, then the user can know the secret key.
Assuming that:
You deliver a product ("client application") which relys on some 3rd party web service ("the service").
Your company has just one secret key ("company key") for using the service.
The company key must never be exposed (due to possible abuse)
Every piece of information held by or transmitted by the client application is exposed
A solution might be to use some proxy:
The proxy implements the API of the service
The client application connects to the proxy
The proxy connects to the service using the company key
The proxy delegates all calls from the client to the service and vice-versa