I am building a program for myself that will save my passwords. Now I have the following questions. Because I have a lot of computers (one for work, three for myself), I want to keep the passwords in sync with a server. But now my question is what is the safest way to send data over the internet with c#? Is it possible to make the connection so safe that I can send passwords over it? And maybe any suggestions for the app.
Yes, you can make it reasonably secure. First, I would recommend against writing your own protocol stack, simply because it is so incredibly easy to make a simple mistake that would make it trivial to hack the security.
( Obviously there are plenty of already existing services (like 1password, passpack, etc) but I assume you know that already. )
I would recommend that you focus on the syncing and UI and leave the security to alredy proven libraries. One such solution is to use SSH with RSA authentication and known host keys. This is in use on many production sites and AFAIK considered reasonably secure (though there was one hole in one of the most popular implementations, OpenSSH, some years ago that was pretty bad). The SSH protocol can be used as a carrier for all kinds of different protocol, including your own password-syncing protocol (for that you could just use SOAP or JSON-RPC or something similar that there are plenty of libraries for).
You can then integrate directly with C# by using a SSH client library (https://sshnet.codeplex.com was the first Google hit). I have no experience using C# directly to talk SSH, though. What I usually do is to let an existing SSH client (PuTTY, for example) open up a port forward and then use regular TCP sockets. It all depends on how slick you want the sync app, but since you are writing it for yourself only, I would go with the latter.
If you are clever writing your app, you don't need a server part except of your own (for example, SSH implements SFTP for file storage).
A similar idea is to use SSL. If you pre-trust the certificate chain, this can be made secure enough but my experience is that the default SSL socket API in C# is way too much tied into the Windows architecture, making things like custom certificate validation trickier. Using a publicly exposed server to your service (directly of via IIS) also opens up a lot of new attack vectors.
Related
I need some help for a noob programmer. I have an application I built > assetcat.app
I am venturing into the depths of networking and looking to rebuild the app using a host / client system.
I have been building the foundation for this with WCF. But it has been a struggle with roadblocks at every breakthrough, I expected to get simple host/client environment with authentication setup no problems. But I have had issues with the network access on different IP's, certificate issues, and even just finding information on MSDN that shows example that doesn't use the app.config. As I need to do most stuff dynamically for portability.
I'm sure if I continue with WCF I will succeed but I'm starting to wonder if there is something more simple. It seams WCF is more suitable to some kind of in-house development were the company of the app also runs the server.
What I want to be able to achieve:
-User installs and manages their own instance of the server software.
-They create accounts witch anyone who downloads the client can point to.
So Bob wants to make a game and is working in a team, Bob installs the server app and sets up some user logins. Bobs team mates install the client app, set the pointer to the IP of his server app, and login. Everyone in his team enjoys access to content managed by the server app.
In this situation, should I continue with WCF? My concern is also around certificates, from what I have gathered I can just chare a development certificate for everyone to use. Each person who installs the server software is also going to have to create or buy a certificate? That seems like a whole lot of mucking about that nobody is gonna do.
WCF has been around for a long time and before what APIs generally look like today. WCF like SOAP/WSDL allowed for strongly typed contracts and in general (before JSON was a thing) shared messages via XML documents. Many enterprises still have WCF services for integration points.
Today, the modern trend is to have less strongly typed contracts, and share messages via JSON payloads. Rather than SOAP/WSDL endpoints you have basic HTTP listeners that can accept requests (usually POSTs) and parse the JSON to business objects. Many folks prefer to create stateless and Restful (or Rest APIs) as this aids with scalability and fault tolerance.
WCF would seem like the wrong way to go for game development. Restful APIs can still use transport and message encryption, but be a lot lighter weight than WCF which adds a lot of overhead and complications (contracts etc) that you probably dont need.
In terms of encryption, you could add SSL/HTTPS using a Let's Encrypt certificates. These are free to obtain.
Is it possible to implement client/server communication between a C++ program (client program) running in linux OS with a C# program(server program) running in Windows using RMI implementation?Can anyone suggest any possible way...Any kind of helpful reference is welcome
You would need to go along the lines of Google Protobuf. It is available with C++ and C# as well.
A similar answer from MSDN
It does not matter if you send data from java,c++ or c#, when it goes
over the network it's just 1s and 0s. It's a matter of what you do
with it on the client/server side. So, be sure that the data that you
receive corresponds with the structure that you have (that you want to
deserialize to).
Sometimes you need to manually put the bits and bytes together to get
it all working out. However, there is something called "Protobuff"
that can help you get a common structure of the data that you send,
google it and read all about it.
You can implement client server with sockets and serialize/deserialize it using protobuf.
(MSDN link might help in solution)
I think message passing libraries would fit best in to this. Take a look at ZMQ for instance; they have binding for many languages found here
so you may have your event dispatcher in one language and listener in the other language. Also take a look at apache thrift
CORBA is one IPC mechanism that will provide the RPC mechanism that you are looking for.
Here is a link describing communication between C# server and JAVA client.
http://iiop-net.sourceforge.net/dnAdderRmiClient.html
At one of the companies I worked previously, it was used for communication between c++ and java programs in a client/server model.
They used a combination of ACE/TAO libraries.
http://www.cs.wustl.edu/~schmidt/TAO.html
I would recommend that you do not use remote method invocation for communication between a client and a server. In the nineteen-nineties we used to believe that RMI is a good idea, but since then we have realized that there are much better ways for communication between computers.
The most popular way is by using Web Services, and the easiest flavor of Web Services is RESTful Web Services. (Look them up.) This has the benefit of not caring at all whether the runtime environment of the client looks anything like the runtime environment of the server, as the case is with your setup, where your client is C++ on Linux and your server is C# on Windows.
Mozilla's XPCOM might be your bridge. There is also PyXPCOM. Realistically though the easiest way is to have an intermediate VBox. So you run a VBox instance (running Windows) on the linux machine and then use VBox API (from C++) to issue commands within VBox. So you end up with
Linux <--xpCom--> VBox <--COM--> Windows
When working over network it's protocol what matters, not the client/server.
In telecommunications, a communications protocol is a system of rules that allow two or more entities of a communications system to transmit information via any kind of variation of a physical quantity. These are the rules or standard that defines the syntax, semantics and synchronization of communication and possible error recovery methods.
Source Emphasis is mine.
So, in order to communicate your C++ client and C# server you need to choose or define protocol that will be used for communication.
Your protocol can be build above another protocol. For example, you can use HTTP for transportation purposes and define your protocol describing what syntax should be used for messages in HTTP requests and responses bodies. This will help you, because there're many ready-to-use solutions for HTTP communication.
Actually you will build your protocol based on another anyway. HTTP itself build above TCP. You'll need to choose whether it would be low level or high level protocols. They all have their pros and cons.
But you will have to deal with messaging between your client and server yourself.
As an alternative you can use some Remote Procedure Call(or RPC) solution:
Remote procedure call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.
So that means that you only have to follow guidelines how to build your client and server and all communication will be hidden and will look like as just calling object's method.
Source
Here's short list of possible RPC solutions:
Component Object Model with DCOM. Wiki: COM,DCOM. MSDN: COM, DCOM.
Simple Object Access Protocol. Wiki.
Windows Communication Foundation. Wiki. MSDN. SO(credits to Sanju for link).
To wrap it up:
It's not a problem that your client and server are in different environments and are developed using different platforms. You only have to build communications between them using either your own messaging system based on some protocol, or some RPC system.
We could just write a C# program to listen messages from a particular port and write another C++ client program to write message to that port.As thus we could communicate both application.
I am just learning c#, and am programming a Windows client that collects temperature data from the computer and needs to send it to a remote linux mySQL Database.
I was going to program it directly in the c# client, but I want to learn more ways to do this and gain experience. And programming it directly would be less secure and most likely require an extra connector.
Can any of you advise me of other ways, or ways you would do this?
Any way to program a C# program that acts as a web-service on my linux mySQL Server? Where should I look/search to learn more about this. Is it called something special? Or maybe its not done in C#?
Should I program a php script that accepts HTTP SEND/GET requests from my C# Desktop client?
Any other way?
What way is most 'professional' in the real world? Trying to learn on my own! :D
FORMAT:
Windows Desktop: client programmed in C# That retrieves temp data and needs to send to server
Linux Server: Runs Apache and mySQL Server with a database already setup. Closed to outside Connections
My advice is to set up a web service to communicate with your windows client. Directly connecting to mysql server is ok if they both resident in a same lan, but if not, for example your windows client is running on some laptop travelling everywhere or even the mysql server permits local incoming connection only, your should set up a web service. Also the http connection can usually go through firewalls while connections over other ports are blocked.
php is a good way to do this. Since you are learning c#, you may want to use c# to do the server side programming as well, so why not give a try of mono?
Directly exposing a MySQL Server to the internet is strongly dicouraged, Additionally this gives you a rather coarse-grained set of access rights, that might not be enough for your application, so running some sort of server app is the right way to go.
With mono you can run a lot of .Net (and thus C#) based code on a Linux server just fine. Rule of thumb is: If it doesn't have a Winforms GUI and no P/Invoke it will work just fine. Ofcourse this needs mono on the server, which is not given on most commercial hosts.
Running the server in PHP makes it a lot more portable, but has a performance overhead. Additionally it doesn't allow for some of your busines logic objects to be implemented in a DLL assembly and used on both sides.
As for the protocol: Chose your poison. Rule of thumb again is, that predefined protocols such as SOAP tend to need a bit more work (and more learning in the first go), but on the long term tend to be more robust.
For your special use-case I'd personally go with a quick PHP based solution where the protocol is just a simple GET with a few parameters, one being the temperature(s) and the others authenticating the client.
If the temperature sensor generates events, then I would 'push' the data from the Windows box to the Linux box - this will save the latter checking often and finding no updates. However if you are just taking temperature samples, I would 'pull' the data from the Linux machine. Either way, if you want to use HTTP you will need a web service on either side.
Alternatively, you could just connect to your MySQL database remotely from C#, and write the data directly (no web service would then be required). That might be the quickest way to get this working.
The 'which is professional' question is subjective - all three options above are fine. Just make the code clear and concise :)
I need to expose our repository which resides in our server machine to clients. The clients should be authenticated, and read write permissions are enabled. We are having doubts regarding which way to go with the implementation:
We already have client based COM layer so we can wrap it with some C# UI.
Server rest services, and then writing rest services based UI in C#/GWT/etc.
Implement WebDav protocol and get free client (windows, total commander, others)
What do you think is the best approach?
I don't know what kind of repository you are talking about, and what your clients need to do with it. But if it's plain reading and writing of files, I'd say WebDAV is the best way to go: It's supported widely across all platforms, has loads of free clients, can be set up on a Windows machine within minutes, supports SSL (I think) and is very easy to use.
If you need to do more fine-grained things like protocol changes, have you considered using source control software like Subversion, Git or Mercurial? They would give great possibilities, but the learning curve for your clients would be very steep. I wouldn't recommend this for a non-techie audience.
WebDAV or SFTP (SSH File Transfer Protocol) server would work. They offer similar functionality, with SFTP being more widespread.
I'm not sure what you have in the way of infrastructure, but I'd suggest putting the server in a DMZ so if anyone breaks in they can't do too much fdamage to the rest of your network.
How are you going to authenticate users? ASP.NET 2.0+ has some useful libraries that provide some excellent out-of-the-box capability fo managing users which integrates with FormsAuthentication; this will gove you options for identity and access management - assuming you write a asp.net front end.
What ever approach you take, I'd suggest PEN testing it - either yourselves or by a third party security specialist.
I am using C# 2008 SP1
I developed a program that will be run on several user computers, ranging from a few hundred to a few thousand.
What is the best way to download the files to update the user program HTTP or FTP?
Also, are the security issues related to each protocol?
Many thanks
The easiest way to handle this is probably via a ClickOnce deployment. But that isn't an option for everyone.
Either protocol should work most all the time, HTTP might be a bit more likely to be working (i.e. if the only way to connect to the internet on that system is through an HTTP proxy).
As for security, neither protocol ensures that the server is actually the right server... so really, there's not really any. HTTPS would solve that problem, but might not be possible.
If security (not privacy) is a concern, I'd recommend signing the package and verifying the signature with a public key embedded inside your application after downloading, that way you won't need to verify that the protocol is secure.
An FTP stream seems to be more problematic to secure due to its nature. It seems to be more trivial to implement HTTPS to secure the stream itself.
But in general, unless the bits themselves are sensitive, you might be barking up the wrong tree. Protocol is usually not as important as authentication/authorization and other application-level concerns when talking about application updating.