WCF supports to use certificate to authenticate Client. If a malicious user steals client's certificate and creates connection with Server. Can Server know this? If we install certificate to Microsoft Certificate Store, how to make sure it is safe? I could easily read the certificate in store by code.
Can Server know this?
no.
If we install certificate to Microsoft Certificate Store, how to make sure it is safe?
you can't.
Certificates themselves don't solve secret leaking problem. They provide better security on a transport, better UX when authenticating on remote server, but they can leak as easy as passwords (ok, not that easy, but can). Such issues are solved using different techniques, like storing the certificate on a smart card where you need to have both, a card itself and PIN/Password to access the card. These are out-of-band solutions the certificate is not aware about, thus you can't tell whether the key is secure or not.
Related
I'm aware that a self-signed certificate is not a good idea to encrypt SSL traffic between a server and a browser. But does it matter in the context of IdentityServer4?
And where is the difference between that and AddValidationKey() which seems easier to me?
By all means, I'm not a security expert and unfortunately nobody in my team, so we are a bit confused here and I would like to avoid opening up a big security hole. At the same time, I don't want to complicate something that is not necessary.
First of all, when dealing with IdentityServer you have several keys/certificates to deal with.
You have the certificate for the SSL/TLS(HTTPS) traffic, and this one should not be self-signed.
You have AddValidationKey/AddSigningCredentials that both deals with the signing of the tokens. This needs a separate public/private key. This can be done using a self-signed certificate. See this article
You have also the Data Protection API to deal with, this is responsible for encrypting the session cookies issued. To avoid issues during redeploy, you should make sure the signing key (keyring) is persisted during redeploy.
Hope this is a starting point :-)
Sorry I'm not a cyber security expert but I'm looking for some insight! I would like to encrypt a standard TCP socket communication and thought about using SSL. Both devices might not be connected to the Internet and cannot communicate with a root CA to validate their certificates. This should do the trick to prevent sniffing the communication but doesn't protect agains man in the middle attack.
Alternatively, devices could generate and sign each other certificates but how to make this procedure secure?
Since it's pretty easy to hack, it probably doesn't worth the effort to implment ... Right? Or what encryption mechanism would you recommend?
Both devices might not be connected to the Internet and cannot communicate with a root CA to validate their certificates. This should do the trick to prevent sniffing the communication but doesn't protect agains man in the middle attack.
Not true. If a device is unable to reach internet, it would be unable to check certificate revocation (CRL/OCSP) . The client would still be able to validate the other's party certificate and its validity.
Alternatively, devices could generate and sign each other certificates but how to make this procedure secure?
You don't really need to sign each other's certificate, the parties just need to trust them.
As already commented, you can use a self-signed CA or a self-signed certificate and then there's a question how do you protect the generated and CA private keys (isn't that always the case?). IMHO - even without any internet access using the qualified certificates (signed by a trusted CA) is a good /best option.
pretty easy to hack.. Or what encryption mechanism would you recommend?
No, not really "easy to hack" provided you keep the private keys private.
I'd say SSL is the best option for ensuring confidentiality and integrity of the transport channels.
What is the best means to verify that a server is who it says it is.
I'm guessing using signed SSL certs is the best route, but was wondering if there was any programmatic means to do this..
EDIT: This is for a an app where servers deal with other servers (authenticating each other) in order to exchange user info. (sorry if I forgot to mention that)
SSL certificates signed by an authorized CA (certificate authority) is the only way to be sure. Anything else can be faked, and especially any "programmatic means" would be particularly unreliable. Short and simple: an authorized SSL cert is the only thing a browser will recognize as reliable, regardless.
You don't need certificates to prove your identity (or a server's for that case) to someone. You can use pre-shared keys for that purpose, and avoid any public key infrastructure. The TLS (or SSL) protocol supports that. Find a TLS library that allows you to use TLS-PSK and use it.
I'd recommend HMAC or RSA. HMAC is pretty secure and much easier to implement. HMAC could get unwieldy if you have 5 servers that all need to communicate with each other directly.
What are you trying to secure? It sounds like a web application, and if it is one, then you should go with SSL certs.
I have a WCF Server Deployed through IIS. I want to Create a Certificate for it. I could do this by making the server a certificate server.
But then when the client connects to that server I want the client to automatically trust the certificate without having to register that the server as a "trusted authority".
Is this possible?
All this seems a lot of work to put username password protection on a WCF Service!
The short answer is no the client will need to add the server cert root as a trusted authority.
The slightly longer answer is that there is a workaround for needing to implement transport security in WCF when using message based authentication - this workaround is usually used when you want to rely upon another security mechanism that the WCF server is not aware of, like an ISA server providing SSL.
Have a look at Yaron Naveh's post. The essential idea is that you create a transport binding that pretends that it is secure.
With all that, you still need security (you don't want to send your creds in the clear) and so will still need a trust chain for your cert. So, it may not actually help you, but hopefully it gives you some options to consider.
Edit
Sorry if my answer was misleading. The server certificate root cert must by in the client trusted store. My additional detail was giving another option for providing the security (you can use an ISA server with a trusted cert to give your SSL connection)
In a similar situation to yours (needing secure communication when pushing client applicaitons to non technical customers) I have programatically installed the needed root certs.
Here is an SO post that details how to do that: How can I install a certificate into the local machine store programmatically using c#?
You can if you add this to your code but be aware of what you are doing!
System.Net.ServicePointManager.ServerCertificateValidationCallback += ( se, cert, chain, sslerror ) => { return true; };
Well if there would be such a way, it would be a security hole.
If a certificate is not linked to a trusted authority it is easily forged. So your choice is either to link it one way or another (directly or through a parent certificate you control), or configure your client so that it does not require the certificate i.e. using http rather than https.
Just keep in mind that it leaves your clients open to a variety of attacks
Edit
One of the possible attack scenarios is a man in the middle attack - a program inserts itself between your service and the client and channels the information though itself. This way the intruder has complete control over the information flow.
It can make copies of passwords or it can "adjust" the results in both directions any way it wants. The only thing which prevents this from happening is the certificates. But if they are not rooted, they can be forged.
I have a client/server WCF application that needs some sort of user authentication against a database. The application (both client and server together) is being developed to be sold to dozens of customers, for use on their intranets. We're not too worried about encrypting most of the data moving across the wire, except of course during authentication.
Thinking about WCF security, I keep coming back to the idea that we should be making use of x509 certificates. However, our customers will definitely not want to know about any of the details of having to apply for, purchase and install these certificates.
I'd like to know first of all what the preferred method is of implementing username/password authentication in this scenario. If it will require using certificates, must the customer apply for their own certs from a trusted CA, or can we as the software provider generate certificates for the customer to use?
Really I'm looking for a best practice, with the least friction to our customers.
Thanks!
Edit: I'm using NetTcpBinding, and my server is running as a Windows Service.
So username/passwords does not require client certificates as I'm sure you're aware, it simply requires an HTTPS certificate on the server hosting the WCF service - once you have that you can happily use the standard username/password auth bits (WCF will not allow message based authentication without HTTPS).
If you wanted to head down the client certificate root you get the advantage of non-repudiation - you can be sure that the machine sending is who it says it is (unless someone has stolen the certificate, which is less likely than a username and password combination going walk about). You as the software provider could act as your own certificate authority and generate your own client certs (there are a few ways to do this depending on your infrastructure) but then you need to configure the clients to trust your root CA.
If the server and client are running in a domain environment you could use transport security with Windows authentication (you're using tcp binding, so interoperability is out the window anyway!) The added bonus to this is the authentication is transparent and you don't need any certificates anywhere. If you want verfication of the server identity then message security with Windows authentication will do the trick.
I've got project in production which is similar to your scenario. I have a Windows Service hosting endpoints via netTCPBinding and I used x509 certs... although in my case, the intent was to encrypt both the transport and message layers, as I was crossing over untrusted security boundaries. I was less concerned with providing authentication/authorization other than requiring the certificate be present.
Similar to your intranet scenarios (I'm assuming), I had authority over the server and client machines at installation time... or at least could dictate some of the terms of installation.
Rather than purchase the x509 certs and burden the client with that expense, I opted to roll our own. We set up one of our Win2003 servers to be a CA, issuing our own Certification Authority cert. We then generated an x509 cert for the server, as well as individual x509 certs for the clients.
The client and server certs were installed on both clients and server (as appropriate) into the personal user store at the computer level. We also installed our CA cert directly into the Trusted Root Certification Authorities section, thus making our client and server certs trusted.
Because I was less concerned with authentication/authorization, I don't know what to recommend as a best practice for dealing with binding certs to individual users and going more granular than machine-level (my solution was windows service to windows service communication -- completely unattended). I would think you'd need a cert for each user, installing it into their personal user store in the certificates MMC. The runtime implementation will be guided by how you configure WCF to do the cert lookup, so it should be fairly easy.
Throughout the process, I relied heavily on what I'd learned from this great CodeProject article: Securing WCF Services with Certificates. It walks you through generating/installing the certs. The sample WCF applicatoin is IIS-hosted, but I was able to pretty easily translate the config sections from web.config to app.config.
In my case, I exposed the Web interface for requesting certificates in Win2003 to the web itself, so the client could request certificates directly in the future. We have approval control, so it works well. I haven't had a need to generate new certs yet, so I can't say how much friction that would entail.
If your going to be crossing firewall boundaries then certificates are going to be your best solution. I don't know much about the specifics about applications for certificates or your application. Unfortunately, as far as i know, i think you will have to help them apply for certificates or they will have to do it their self unless they want to undertake in the process of installing their own certificate server. If the app will be internal then windows authentication will work and is VERY easy but if you think your going to have clients that user your application across firewall boundaries then you might as well invest the time in using certificates because certificates will work everywhere. Now there is something called federated security where you delegate the permission of authentication to another entity. I think this is used if say you have to domains and you want to delegate permission say of someone on another domain that is not on your domain to their domain but its pretty complex and my understanding of its very limited but by the sound of your requirements certificates is the way to go.
Security is not supposed to be easy :)