I am developing and application in vb.net winxp+ (windows xp upwards). The application has to receive backup data from clients software located at different pc over the Internet. but am concerned about security of this application on the Internet.
what would be the best way to implement security in vb.net 2008 to make sure that the data is not sniffed or interfere with?
am thinking of encrypting the data before sending, saving it that way until it need to be viewed before decrypting.
what type of encryption would you suggest?
Is there any other way you would suggest this data be sent?
First of all your Server Application has to be a Windows Service. I imagine that your server will be always up, so a Windows Service is the right thing to implement.
Here you can find a reference on how to implement a Windows Service using .NET languages (it's very easy).
Then to secure the channel you have to do a choice about the type of encryption you want to use:
Symmetric: AES, 3DES, BLOWFISH, etc.
etc.
Asymmetric: SSL or your home
made protocol
The symmetric option (here is an example) has an hard key management because you have to store all the client's keys onto the server. Or you can use the same key, but it's not secure because you have to protect very well the client key. If an attacker gets the client's key, whole security infrastructure is in the hands of the enemy.
But you can have a different symmetric key for every client and the server chooses the right one. Anyway you have to protect the client's code and key (obfuscation and so on)
The asymmetric option (here is an example) is the best choice for me because you can have:
client authentication to the server
(the server has all the client's
public key and verify the sign)
server authentication to the client
(the client have the server's public
key)
channel encryption (channel is
encrypted with the symmetric session
key handshaked by the clients and
server through the public and private key)
The best and well-known protocol implementing the last one is SSL. You have to find APIs that implement it or you have to do by yourself (it's very hard to implement without bugs and security concerns).
Remember that you need certificate for SSL communications. X509 made via OpenSSL are good for your requirements and are easy to create.
There are two different things you should consider here.
Is it a requirement that the backup data are encrypted on the server, in which case clients should encrypt data using a symmetric cipher (e.g. AES) before doing the transfer.
For the transfer itself, SSL (https) would be a solid solution, with server-only authentication.
Related
I'm looking at how to set up a secure connection between a WCF service, and a non-.NET client running on RHEL, so I expect Windows authentication is not feasible. This is just for an internal network, so I'm hoping to avoid the management headaches of X.509 (e.g. needing to closely monitor certificate expiry dates), but I'm not clear on whether it's technically possible to do so.
Is it possible to configure a WCF service with e.g. BasicHttpBinding or WsHttpBinding so that it has encryption (either transport or message layer, I'm not picky), but without using Windows authentication support or X.509 certificates?
Every scenario I've read for secured WCF services seems to use one of those two technologies. The only ones which don't require any X.509 certificates all use Windows authentication. I'm not sure if this is a fundamental consequence of the underlying technologies or if it's just a property of the "common scenarios" that Microsoft has chosen to document. At the moment I'm assuming that if Windows authentication isn't available, then X.509 is the only way to deploy public/private key pairs for the non-Windows-specific message encryption algorithms to use. Is this understanding correct?
well ... it's just that "common" property ...
x.509 is the common way to do this in your scenario, since the most things needed for this are already there ...
but you are not limited to either windows auth or x.509 ...
take a look here: http://www.codeproject.com/Articles/165844/WCF-Client-Server-Application-with-Custom-Authenti
the article describes how you can introduce your own authentication and encryption schema ...
i've already done that (simple AES encryption, one key among all clients), but i don't have the code at hand ... it wasn't that hard, but if you really run into trouble here, i'll have a look if i still have that stuff somewhere...
I have multiple tiny Linux embedded servers on Beaglebone Black (could by a RaspberryPi, it makes no difference) that need to exchange information with a main server (hosted on the web).
Ideally, each system talks to each other by simple RESTful commands - for instance, the main server sends out new configurations to the embedded servers - and the servers send back data.
Commands could be also issued by a human user from the main server or directly to the embedded servers.
What would it be the most "standard" way of authentication of each server against each other? I'm thinking OAuth, assuming that each machine has its own OAuth user - but I'm not sure if that is the correct pattern to follow.
What would it be the most "standard" way of authentication of each server against each other? I'm thinking OAuth, assuming that each machine has its own OAuth user - but I'm not sure if that is the correct pattern to follow.
Authenticating machines is no different than authenticating users. They are both security principals. In fact, Microsoft made machines a first-class citizen in Windows 2000. They can be a principal on securable objects like files and folders, just like regular users can.
(There is some hand waving since servers usually suffer from the Unattended Key Storage problem described by Gutmann in his Engineering Security book).
I would use a private PKI (i.e., be my own Certification Authority) and utilize mutual authentication based on public/private key pairs like SSL/TLS. This has the added benefit of re-using a lot of infrastructure, so the HTTP/HTTPS/REST "just works" as it always has.
If you use a Private PKI, issue certificates for the machines that include the following key usage:
Digital Signature (Key Usage)
Key Encipherment (Key Usage)
Key Agreement (Key Usage)
Web Client Authentication (Extended Key Usage)
Web Server Authentication (Extended Key Usage)
Or, run a private PKI and only allow communications between servers using a VPN based on your PKI. You can still tunnel your RESTful requests, and no others will be able to establish a VPN to one of your servers. You get the IP filters for free.
Or use a Kerberos style protocol with a key distribution center. You'll need the entire Kerberos infrastructure, including a KDC. Set up secure channels based on the secrets proctored by the KDC.
Or, use a SSH-like system, public/private key pairs and sneaker-net to copy the peer's public keys to one another. Only allow connections from machines whose public keys you have.
I probably would not use an OAuth-like system. In the OAuth-like system, you're going to be both the Provider and Relying Party. In this case, you might as well be a CA and reuse everything from SSL/TLS.
I think you need to Implement Mutual Authentication between servers using SSL for your requirement.
I do not know much about M2M environment , but using OAuth for Authenticating your Servers is OverKill .
https://security.stackexchange.com/questions/34897/configure-ssl-mutual-two-way-authentication
Also Encrypting your Communication Channel while Sending commands would make it more safe from Attacks
I am looking for a way to encrypt messages between client and server using the WCF. WCF offers a lot of built in security mechanisms to enrcypt traffic between client and server, but there seems to be nothing fitting my requirements.
I don't want to use certificates since they are too complicated, so don't suggest me to to use certificates please. I don't need confidentiality, so I though I'll go best using plain RSA.
I want real security, no hardcoded key or something. I was thinking about having a public/private keypair generated every time the server starts. Both keys will only be stored in RAM.
Then wen a client connects it should do exactly like SSL. Just as described here.
1.exchange some form of a private/public key pair; the server generates a key pair and keeps the private key to itself and shares the public key with the client (e.g. over a WCF message, for instance)
2.using that private/public key pair, exchange a common shared secret, e.g. an "encryption key" that will symmetrically encrypt your messages (and since it's symmetrical, the server can use the same key to decrypt the messages)
3.setup infrastructure on your client (e.g. a WCF extension called a behavior) to inspect the message before it goes out and encrypt it with your shared secret
That would be secure, wouldn't it?
Is there any existing solution to archive what I described? If not I'll create it on my own. Where do I start best? Which kind of WCF custom behaviour is the best to implement?
EDIT:
As this is NOT secure, I'll take the following approach:
When Installing the server component a new X509 certificate will be generated and automatially added to the cert store (of the server). The public part of this generated certificate will be dynamically included into the client setup. When running the client setup on the client machine the certificate will be installed into the trustet windows certificate store of the client.
So there's no extra work when installing the product and everything should be secure, just as we want it.
You've said you don't want to use certificates. I won't push certificate use on you, but one thing you are missing is that certificates serve a purpose.
A certificate proves that key you are negotiating an SSL connection with belongs to the entity you think it belongs to. If you have some way of ensuring this is the case without using certificates, by all means, use raw keys.
The problem is, in step 1:
1.exchange some form of a private/public key pair; the server generates a key pair and keeps the private key to itself and shares the public key with the client (e.g. over a WCF message, for instance)
How does the client know that the public key it received from the server wasn't intercepted by a man-in-the-middle and replaced with the MITM's key?
This is why certificates exist. If you don't want to use them, you have to come up with another way of solving this problem.
Do you have a small, well-known set of clients? Is it possible to preconfigure the server's public key on the client?
Alexandru Lungu has created an article on codeproject:
WCF Client Server Application with Custom Authentication, Authorization, Encryption and Compression
No, it would not be secure!
since there's no confidentiality, an attacker could do a men in the middle attack, and all the security is gone.
The only real secure way of encrypting messages between server and client IS to actually use digital certificates.
I'm sorry, the only two methods of providing secure communications are:
Use a public key infrastructure that includes a chain of trust relationships, a.k.a. certificates
or
Use a shared secret, a.k.a. a hardcoded key.
Nothing else addresses all of the known common attack vectors such as man-in-the-middle, replay attack, etc. That's the hard truth.
On the other hand I can offer you an alternative that may alleviate your problem somewhat: Use both.
Write a very, very simple web service whose only job is to generate symmetric keys. Publish this service via SSL. Require end user credential authentication in order to obtain a symmetric key.
Write the rest of your services without SSL but using the symmetric keys published via the first service.
That way your main app doesn't have to deal with the certificates.
I am implementing an app where I don't have a system requiring username and password. What I do require is a name and a phone number.
The scenario is like this:
1) user opens the app for the first time
2)app makes a request to my server and gets a unique UserKey
3)from now one any request the app makes to my REST service also has a signature. The signature is actually a SHA(UserKey:the data provided in the request Base64Encoded)
4)The server also performs the same hash to check the signature
Why I don't use SSH:
not willing to pay for the certificate
I don't need to send sensitive data like passwords, so I don't see the benefit of using it
I just need a simple way to call my own WCF REST services from own app
I understand that there is a flow of security at step2 when the UserKey comes in cleartext, but this happens only once when the app is first opened. How dangerous do you think this is?
What would you recommend? Is there any .NET library that could help me?
Actually, there are several problems with that approach. Suppose there's man-in-the-middle whenever you make a request to the server. By analyzing, for example, 100 sent packets he would recognize similar pattern with signature in your requests. Then he would forge his own request and add your signature. The server checks the hash - everything's alright, it's you and your unique user key. But it's not.
There's a notion of asymmetric keys in cryptography which currently is really popular and provides tough security service. Main concept is the following: server generates two keys - public and private; public key is used to encode texts; they can be decoded only with the use of private key, which is kept by the server in secure location. So server gives client the public key to encode his messages. It may be made double: client generates public key and gives it to the server. Then server generates keys and gives encoded with client's public key his own public key. This way it's almost impossible for man-in-the-middle to make an attack.
Better yet, since the problem is really common, you could use OAuth to authorize users on your website. It is secure, widely used (facebook, g+, twitter, you name them) and has implementations already in variety of languages.
Since you control both the application itself and the webservices, you can do this with SSL (which gets rid of the problems with your current approach) without paying for anything. You can create a self-signed certificate and install that on your webserver; configure the SSL context of your client application to only trust that one certificate. Then, create a client-side self-signed certificate and install that within your application. Set the server up to require mutually-authenticated SSL and only allow your self-signed certificate for access.
Done. You client will only talk to your legitimate server (so no one can spoof your server and trick the client in to talking to it) and your server will only talk to your legitimate clients (so no one can steal information, ID, etc). And it's all protected with the strong cryptography used within SSL.
I have a WCF service and client which is going to be deployed to several companies (hundreds). Some companies will run the software in their network and some will run it over the Internet (WCF server at on office, WCF client at another).
We want to encrypt the communication between the WCF server and client. We don't have any need to authenticate the cient / subscriber using WCF security, because we have our own username/password log-in which the clients will use to log on the server.
We can't rely on Windows auth because some of the users will run it over the Internet, and the WCF server may not be on the same domain as the WCF client.
If we use "real" certificates*, companies running the software would have to purchase certificates from a CA and install it, and then configure our software to use it, but this is too complicated for most of them.
We could auto-create certificates during installation of the WCF server, but then we would have to automatically install it into a certificate store and somehow automatically grant IIS permissions to read the certificate. This is more complicated than we would like.
In short, we want a simple solution where the encryption is just based upon a shared secret, in our case the username / password the user is logging on with. I do understand that this won't give the best available encryption, but we're willing to trade some of the security to make the software easier to deploy.
Is this possible?
*With "real" certificates, I mean certificates purchased from a certificate authority, and not one I've created myself / self-signed.
If you want to encrypt the messages on the transport (which is a really good idea!), there has to be some shared knowledge between the sender (the client) and the server. This can be hardcoded, but that's really not a good idea at all - if that "common shared" knowledge is ever compromised, an attacker could decipher and read all your messages.
Also, since it's definitely not recommended practice, there's no support of any kind in WCF to simplify using a shared secret. You're on your own - you have to roll your own 100% of the way.
The only viable way to have a common shared secret exchanged in a safe way is to use a certificate. No way around this, sorry. The certificate doesn't even have to be used for user authentication or anything - but it establishes a shared secret between the caller and the service and thus allows the caller to encrypt the messages in such a way only the intended recipient can actually decrypt and use them.
So I really don't see any way you can get around having certificates on your servers - doesn't need to be on every client, but on every server where your service runs.
Marc
PS: if you really want to investigate the "hardcoded shared secret" approach, you'll need to think about this:
how do you store a shared secret safely on each and every single one of your clients?
how do you use information from that stored shared secret to encrypt your messages?
Typically, the approach would be two-fold:
exchange some form of a private/public key pair; the server generates a key pair and keeps the private key to itself and shares the public key with the client (e.g. over a WCF message, for instance)
using that private/public key pair, exchange a common shared secret, e.g. an "encryption key" that will symmetrically encrypt your messages (and since it's symmetrical, the server can use the same key to decrypt the messages)
setup infrastructure on your client (e.g. a WCF extension called a behavior) to inspect the message before it goes out and encrypt it with your shared secret
All in all, it's really not trivial - anything simpler than that is not worth being called "security" at all.
If you look at all that work you will have to do - wouldn't it be easier to just use the WCF built-in certificate mechanisms??
Decent security worth its salt is hard - so why not leverage what's available instead of doing all the work yourself, or worse: come up with a half-baked solution that's so easy to crack you could just as easily send everything in cleartext..... don't under estimate the complexity and amount of code needed to handle even the most basic security scenarios - WCF does this all for you - for free and in a reliable and safe manner - use it! You won't regret it!
Well, with WCF you could use Password credential at message level and SSL at transport level, which I think would be enough in your case.
See here.
For message security, your client provides some credentials and server provides some credentials. For this setup and with your scenario could you not use the client username and password with a Custom Username Validator, and a server certificate to provide the server credentials. This Application Scenario provides a fair chucnk of the configuration setup you would need to achieve this, except the aspNet membership sections, which you would have to replace with your custom validation config.
You would still need valid certificates on your servers (no certificates required on the clients), but I can't see any way around this.
Take a look at the following sample:
http://www.codeproject.com/KB/WCF/wcfcertificates.aspx
It uses certificates but without a certificate store - so no setup is necessary.
Hmm.. maybe something simple could be used. Move the encryption from software to hardware. VPN from each client network to your own and then you can do whatever you like for WCF transport. The line is not clear text and the problem is solved.
Of course this is easier said than done, but most network vendors provide a pretty easy VPN config and it maybe easier than trying to develop an installer for SSL certs and configure the client.
I hope it helps!