So I've made a simple C# application and I'm currently using HTTPrequests to login to my phpBB forum, using a custom PHP file to check the post count of the user, and consistently resends HTTPrequests every 30 seconds. Unfortunately, I fear that this can easily be cracked despite the obfusculation. I've heard of serialization, but I don't know what that is.
Any suggestions for consistently validating the post count/login or optimizing it?
Some things that may help:
Are these on the same server or different servers? PHP has solid built in COM support, so there is no reason to use any kind of sockets if they are on the same server.
I can think of two options here: (a) Provide no authentication and make the data such that if someone gets it there is no downside (b) encrypt the data / authentication yourself.
(b) may be easier than you think. PHP has solid built in encryption:
$iv = mcrypt_create_iv (mcrypt_get_iv_size (MCRYPT_RIJNDAEL_128, MCRYPT_MODE_ECB), MCRYPT_RAND);
$key = "ThisIsYourKeyOfDoomAndPower";
$encryptedData = base64_encode(mcrypt_encrypt (MCRYPT_RIJNDAEL_128, $key, $dataToEncode, MCRYPT_MODE_ECB, $iv));
Hopefully this helps you get on the right track...
First of all serialization is not a method to protect your code. You can read more about it on Wikipedia.
The problem you may likely have is that you may pass your forum credentials in insecure way (without SSL/TLS encryption). This way anyone using a HTTP sniffer can get that data with little effort. If you are worried that someone may decompile your app and steal your code then there are some ways of making that harder (like obfluscation that you've mentioned) but you can never be 100% safe.
If I'm missing the point here please provide more details about your app vulnerability.
Related
I've looked high and low and am quite surprised to find absolutely nothing that answers this question:
How can one implement SSL/TLS (or similar) encryption when using SocketAsyncEventArgs? I did read that one could theoretically use a SslStream and "cheat" by creating a go-between to coordinate data in and out of the stream, to and from the socket. That all seems ridiculous...
I Looked into BouncyCastle but they don't seem to have support for server-side encryption. Admittedly, the source for this info is almost 10 years old, but my own research turned up nothing.
I'm not interested in changing my server architecture, so please refrain from telling me "I don't really need the performance of SocketAsyncEVentArgs and should just change to TcpListener".
I'm interested in any method of implementing reliable encryption between client and server using SocketAsyncEventArgs.
There is no direct way to attach SAEA to encryption. They don't share an API in common, so everything is bridges.
The easiest way to do this is - as you know - SslStream, but: that isn't usually compatible with SocketAsyncEventArgs. There are alternatives - I can think of at least 3 different ways of doing this with "pipelines", for example; but all of them would be a major architecture change from naked SAEA. So if the difference between SAEA and SslStream is too large, the difference between SAEA and IDuplexPipe is even larger. However, "pipelines" is designed for high scalable perf, so... maybe it'll suit your tastes anyway? I've blogged about pipelines a lot recently, if it would help; plus I have github examples of client/server code, including a 2.5M+ ops/second redis-like server.
I wrote some code where I establish a TCPIP-Connection between a server and a client and managed to send data from the client to the server.
Now i want to encrypt the data, with RSACryptoServiceProvider, which will be sent between both, so that the client encrypts the data and the server decrypts it for further work. Unfortunally I don't find anything how to manage this on the internet especially when it comes to the keys, because most of it runs on the same machine inside the same programm. Can somehelp me to solve my scenario in vb.net or c#?
My math teacher gave me something that is very smilar to this but that was in danish and i don't think it's a good idea to let you play with google-translate. But this is just as good :-)
Just note (stolen from my math teather, I'm not sure if the link tells it):
The number that you use need to be really big to get you the security level at a acceptable point. Actually, to be secure, you would need at least 1024 bit (preferably 2048), which corresponds to between 307 and 614 decimals.
Hope that helped :-)
In fact, private methods are implemented in C# that can still be searched with Reflection.
What I am going to do is to write public string Encrypt(string data) and private string Decrypt(string cipher) methods to perform encryption and decryption.
Unfortunately, if someone knows .NET framework, he can use Reflection to find Decrypt methods and it decrypt everything that is encrypted.
It seems that is not that secure. So I want to make Decrypt method to truly private method.
But how to do that?
Updated 09 Jan 2012 10:52PM Sydney Time
bdares provides the technical explanation of this question
Eric Lippert provides the political explanation of this question
Thanks both experts!
You can't. If the attacker has access to your code, compiled or source, he can trace your program and find where it's being encrypted or decrypted.
You can add a layer of security by storing the key in a separate location, but generally if the attacker is executing code on your server, you're already screwed.
(You're only worried about this if the attacker is executing code on your server, because otherwise it doesn't matter whether or not the method is private. Also, he can't use reflection to find method names unless he's executing code on your server. In short: you're worrying about the wrong thing here.)
Your fundamental problem is that you've got the trust model wrong. If someone can use reflection then they are the user. You are the software provider. You work for them. Trust flows from them, not from you. They are the person who has to trust you, not you them.
If you don't trust the user then do not sell them your software in the first place. Don't sell weapons to people who you believe plan to attack you.
I believe you are referring to obfuscation, which is an attempt to hide/disguise code from being read by humans when opened in program such as Reflector.
Supplied within Visual Studio is a community use license for PreEmptive Solutions dotfuscator which will provide this functionality on small projects, and also for Windows Phone projects (if you download the add-on). There are also commercial platforms available too, from the same vendor and others .
This blog post explains a little more.
If you're creating your own encryption method, you're doing it wrong. People who know way more about encryption than you or I have already come up with excellent methods for encryption, and MS has implemented most of them already.
For good encryption, it's the keys, not the method, that makes encryption secure. Keep the keys safe and the algorithm can (and should) be published for all to see.
If you're trying to distribute both content and keep it encrypted, aka DRM, you're most probably doomed to failure unless you can keep the keys very well hidden in hardware, and even that will only buy you some time -- maybe months, maybe years.
I am not sure about your exact application. But if you are selling a product to a customer who will be doing both the Encryption and Decryption on their own system, then there is no way to keep the encryption secret from them. But you can instead allow them to generate a new Private Key for their own use. In this way each customer's data is 'secure' in regards to other customers; though obviously still not so secure within the same customer's site. In other situations where you control the encrypted content you can also look into creating a private master key to be generated on your side and only allow the customer to have a public key.
I am wondering if its possible to encrypt the ReturnURl before it's displayed to the end user.
I am pretty new at .NET, but I have tried using the PostAuthenticateRequest in the Global.asax. But that doesnt seem to ever fire.
I would be using my own encryption logic if this is even possible.
The only reason you would want to do this is if you have sensitive information in the URL.
And if you have sensitive data in the URL --
Don't.
And also, don't use your own encryption logic. Someone else has already done the heavy lifting for you. This is definitely one area you don't want to reinvent the wheel.
.NET includes plenty of ways to encrypt your data.
A .NET Cryptography Primer
I am about to sell a program I have written in C# and I want to control licenses for it, strictly. That means I want to let the client connect to my server every single time it starts. This also gives me the ability to disable keys (in case of chargebacks on paypal or distribution of the code). Of course this might be a hassle for other users, but it is necessary in this case.
Since I was unable to find any good .NET Licensing systems that are uncracked, I wanted to take the approach of writing a little one myself.
My plan was to do the following:
Generate a key.dat containing 1024 characters that gets shipped with the software (individual to each user)
In the application entrypoint add a httprequest to my server that sends the key.dat + current timestamp, encrypted.
My HTTP server (running PHP) decrypts the request and checks if the key is valid (in my database) and replies with the "access level" (license type). If the key is invalid or disabled it replies with an errorcode. Just like with the request, the reply is being salted with a timestamp, so someone can't validate his program by sending a valid packet to himself. The timestamp is being checked in the client. The reply is encrypted with RSA and a previously generated public key.
Client receives response, decrypts with private key and reacts.
Is RSA the correct approach for this, so I can assure that the packets are sent by me and are not crafted (by noone else having the public key)?
Is there a better approach for solving this problem?
Someone who wants your software bad enough will just decompile it and remove the part of the code that phones home on startup.
If you were to add a checksum to the app that checks whether the code has been altered, someone can just change the checksum the program checks against (or remove the check entirely).
People who want your application enough will find ways around any type of protection you can conceive. You're better off sticking to something simple, having a product that is worth paying for (and easily) and make sure it's worth the price you're asking.
EDIT
Given that protection is important, the fact that the users will have code running on their machines is a risk you can avoid. If the users don't have the code, they can't crack it. They can't copy it and share it.
Now, it might not apply to the application you intend to write, but you should consider writing a web, Flash or Silverlight application instead of a regular client application. That way you don't have to distribute the code to customers. All you have to do is manage credentials into the application, which should be a lot easier than your round-about RSA system.
It's also easier to push out new versions of the software in a centralized model, and you won't have to worry about theft at all. Of course, load will become an issue when it wasn't before. And not all applications can be centralized easily (or at all). I'm just proposing this to make sure you consider it because it is a valid solution to your problem.
A web-based application will have the same issues as your application (i.e. it will be down whenever the user is offline, whenever the network is down, whenever your server is down, etc). So there's no added risk in that regard.
Is RSA the correct approach for this?
I do not think RSA is your best choice.
One of the capabilities of PKE (Public Key Encryption) is that it lets parties talk to each other who previously have never exchanged information before (eg. strangers).
I do not see this applying to your case. Your software knows your server well. They are not "strangers".
Consider instead Shared Secret Key encryption, where each copy of the software you distribute is given a unique secret key, and your server knows each user's secret key as well. The keys are never sent, and must be protected, but can still be used to encrypt, sign, and validate communications.
Edit After considering the comments and other answers.
Anyone who wants your software badly enough will be able to bypass the authentication completely. RSA does nothing to prevent that.
The real question is: Does breaking a single license make all licenses vulnerable/worthless. In both cases, (RSA and Secret Key), the answer is No. Just because one copy of the software got hacked and got its key exposed, or the licenses system bypassed, other copies are no more exposed. PKE and SSE seem equal in that respect to me.
Because Shared Secret Key is easier to implement, and computationally faster to execute, I think it is preferred in this case over RSA/PKE. That is not to say RSA is "wrong". It will accomplish what you are after, to the same degree that SSE will (no more, no less). But I think SSE is the smarter choice.