:)
I want to create a webpage with encrypted text on it which a C# program can decrypt. Could I do this?
I have a WebBrowser on a C# form which loads a page and displays a serial code. I don't want anyone to find out this code, therefore that's why I thought about encrypting it. Maybe there's a better way to do this?
Thanks! :)
Do you mean serial code literally, as in a key for some software that should only be viewable by the intended recipient? If this is the case then kudos for putting more thought and effort in, many places send these around unencrypted.
The answer really is that you need SSL. You need the end-user to be able to read it, so they must have all the information necessary to decrypt it. This means you need an encryption method which still works if someone is listening in (if no one is listening in, why are you encrypting it?), so you must either pre-exchange keys or some secret, use public key cryptography, or use something like D-H key exchange.
The only option that's secure if a third party could make changes to your communications as well as eavesdrop on them is if there is some authentication outside the system, or some transitive trust mechanism. Security certificates for SSL perform this exact function.
You could do this all yourself, but you would be reinventing a whole stack of technologies that's present in every web browser. Buy a cert, send the page over SSL.
Related
Sorry, tried looking for existing thread, lucked out.
Just curious if anyone has tactics to protect a vulnerable game client that basically all anyone has to do is use a flash decompiler to modify hacks into it. Does anyone know how I can upload the "legit" Flash client online and then people can ONLY connect to it by playing on the website its uploaded to, or by using the URL inside of flash projector? If they download the client and try to load it as a file then it rejects, i think its called a "domain lock" or something like that. Or if I can figure out a way for the client to be uploaded to my site, but IMPOSSIBLE to download off of it (like they cant just press CTRL+S and save the file to their desktop), that would be cool too.
Or if anyone has other suggestions involving hardcode to be placed into the C# server or the AS3 client.
Just please help if you can, most likely with that first part of the paragraph, that part seems like a solid plan, as long as they cant download the client, they cant modify it so then I wouldnt even have to care if they can connect or not.
You're focusing on the wrong problem.
You can do a number of things to make life difficult for someone trying to use an unauthorized client. You could, for example, embed a cryptographic one-time use token in the client that's good only for a given session and make the client encrypt any communication with the server with it- until the person designs a mod that downloads the client every time and extracts the token.
You can use javascript to try and make it non-trivial to download the client- until the user writes a Tampermonkey script that disables your protections.
Ultimately, if the code is running client-side there is literally nothing you can do to completely guarantee a determined actor won't be modifying it or even building their own client to connect to your servers. What you should be doing instead is working on your server code to detect actions that an unmodified client would never send. Treat all clients as untrustworthy and validate the data you're receiving from them. Assume your server is going to be receiving inputs that are completely unreasonable and handle edge cases accordingly. (Also, don't immediately assume the unreasonable inputs you receive are deliberate cheating- they could just as easily be the result of bugs in the client or even faulty hardware on the user's end.)
I have the following concern about security in server-client models...
Imagine the following:
I have an C# WinForms client that wants to communicate with a server (PHP GET-POST Requests, Socket or WebSocket in a Console App C# (Net Framework) running on a Debian under Mono, instead of using ASP.NET).
The first problem that arises is that whether the server (written in PHP or C #) must have some kind of control for the anonymous requests that the client generates, for this, we will have to use some type of token generated by the server to every request.
The problem isn't related to the token (my plan is to use HTTPS (PHP) or SSL / TLS + Certificates in WebSockets (C#) for client-server communications at the network level, to avoid Spoofing or MitM).
The problem arises when the server has to give to a "client" (we need to check its validity, that the main concern) a token to allow the client do requests. It would be very easy to any client to give a token from the server (How? Replicating (inverse ingeenering) a client that makes requests to the server to try to obtain valid tokens, at least, as I plan to implement it, hence the need for help).
In what I was thinking, is to generate a md5 or sha hash for the assembly file of the client. So, if anyone tries to replicate those steps, it will be difficult. Because he/she will need to modify the source code of the assembly or make a malicious assembly and obtain the same hash by collision (this is difficult).
I do not know how efficient is this system, so I need you to guide me a bit in this aspect.
I've been looking at OAuth, and I think that this type of implementation is not the one I'm looking for, because this kind of implementations is for the user level (to avoid that another user violates the main user data), not for the client (application).
So if someone can guide on this issue it would be of great help.
You can't authenticate the client, it is not possible. Anything in the client is known to the user (attacker), any secret, anything you have there. The only question is difficulty, but anything you do, it will not be very difficult.
Also in your hashing scheme, what would you do with the hash, send it to the server? Why would a different client have to match the hash, when it can send whatever it wants (ie. the correct hash, as sniffed from the network)?
So again, because the software needs to run on the client machine, anything that runs there or is sent on the network is disclosed to the user, and he can replicate it in a different client. It is not possible to securely prevent this. Also ssl/tls doesn't help here, if you control one of the endpoints (ie.the client).
Imagine if it was possible somehow, software piracy would not be a thing - but it very much is.
I'm writing a C# .NET application that requires a secure Login. I've already got the necessary functionality to store passwords securely with a hash and salt in a database, however, I'm now moving from the testing phase. Before during development (the Login wasn't prioritized) I was just connecting to my database directly. I'm aware this is insecure for a production application as you blatantly store your database credentials in the code. Instead, I'm opting to create a simple Asynchronous TCP Socket server that listens for a username, sends the salt from the database back, then the client hashes the entered password (salt is stored locally temporarily) and sends that back to the server. The server then checks if they match; sends back true/false if the user checks out.
I've done some research and looked into encrypting the TCP Connection, however, is this really necessary, since the password will already be hashed? Or is there a better way of doing things in entirety? I'm open to suggestions on how the client/server architecture should work. The Login doesn't play that important of a role in the application as a whole, but it will be production grade and I do not want to put a poorly designed application out there.
then the client hashes the entered password (salt is stored locally temporarily) and sends that back to the server. The server then checks if they match; sends back true/false if the user checks out.
I've done some research and looked into encrypting the TCP Connection, however, is this really necessary, since the password will already be hashed?
It doesn't matter what you call a "password", the only thing that matters is what the server will accept as valid credentials. If you input a password and the server hashes it there (as #Christian Stewart suggested in the comments), then you password is your credential. If you salt and hash the password yourself, and send the result to the server, then this result will be your credential. Intercepting it is as good as intercepting the original password + salt.
So, yes, you must also encrypt your connection, before sending credentials through it. The SslStream Class, seems to be the easiest way to do that (check the example code at the bottom, both for server and client), and it supports both server authentication and optionally client authentication as well (in case you also want to restrict which machines will have access to the Login server).
1) If you are sending sensitive data, the easiest way to protect it is to use SSL. If this is an internal project, you can generate your own certificate. Also, talk to your IT staff about whether this is even a potential problem. If this is going to be deployed in a properly-configured wired intranet situation, users can't see each other's traffic.
2) Your use of salts and hashes is messed up and it no longer solves the problem that it's meant to. Hashing and salting is meant to render the contents of the database unhelpful for an attacker. That's not the case here, since what is stored in the database is what's accepted by the server as an authentication token. Hashing must be done on the server so that the value the server accepts over the wire is irreversibly (hash) and uniquely (salt) transformed into the value that appears in the user store. Now it's true that an attacked can't reverse it to get the user's password (i.e. what they type in to your client) - which is good - but an attacker doesn't need the password if they know the value in the database.
3) Put on your attacker hat. If you watched your authentication exchange take place, would you be able to log in without knowing the secret? Yes, you would just send the last thing the client sent. So this channel should be encrypted.
4) If you can avoid it, don't write your own crypto. Don't even manage users if you can avoid it. People don't want to manage users and groups in every application they use - and I say this as someone who's made this mistake before. Can you use LDAP or domain authentication or something?
There are ways to authenticate an user with the server without ever transmitting the password, using protocols such as the free SRP used by World of Warcraft.
SRP will perform a serie of challenges to authenticate the user based on what each party knows about the password, without ever leaking sensitive information about it to the network.
Still using WoW as reference, there are open source emulators for it such as TrinityCore that give you a solid exemple of SRP in action.
I know I cant prevent people from reverse-engineering my protocol but I'd like to take a security-through-obscurity approach to make it as hard as possible.
I have a server/client system that communicates through the network with http style packets.
Example:
Header
Attribute: Value
Attribute2: Other Value
Payload
I would like to make it as hard as possible for anything other than my client to access the network. Pushing problems with them decompiling my assemblies aside - what would be some good things I could do to this network spec that would make it VERY DIFFICULT to understand and make another implementation without the source?
I was thinking some kind of strange hashing approach or some kind of encryption algorithm that would be difficult.
EDIT I'm not trying to protect my assemblies or source-code. I'm trying to prevent someone from, for example, watching my protocol with WireShark or similar and then making their own implementation based on that information.
All right, three cases:
Users can't access server code and can't access client code: Easiest way is to use a pregenerated shared secret stored in the binary, and aes encrypt/decrypt.
Users can access client or server code but not both: Use a public/private key method. You can encrypt using the public key but the private one is needed to decrypt.
Users can access both client and server code: You're screwed.
If you want to improve security, this static key should only be used during session initiation, to generate a new shared secret, which is then used for communication.
Edit: actually, a more easy and safe solution is to use ssl and certificates (it's a mantra that you shouldn't implement your own encryption) Each certificate comes with a secret private key. As long as users don't have access to that you're safe if you verify that the peer has the exact correct certificate.
For having reversed a few network protocols (from MMOs), I can tell you that you will never protect your protocol for very long, I'm sorry.
The best you can do is:
Obfuscate it using a custom algorithm (because it takes longer to reverse than a known one). Using a known encryption scheme offers no protection whatsoever.
Add noise. Try to be very, very confusing. Add random values that make no sense whatsoever. Try to use a dynamic layout for packets. Move fields. Send useless packets. Just like if it were garbage.
Version your protocol, so that two consecutive version are incompatible. That can be hard to do, but it obliges the reverser to re-do the work for every subsequent version.
But these are just ways to slow down attackers. It's certainly not going to stop them.
There are three solutions:
TLS.
SSLv3.
Whatever you cook up.
1 and 2 already work.
I am also in the process of writing a network protocol in C#. I have made use of encryption to secure the protocol. Here is the outlay of how I did it, you might find this useful.
As soon as the client connects the server requests a random UUID from the client, the client encrypts this UUID with a password know to both the server and client.
All packets sent thereafter by the server or client will encrypted using that UUID as a key.
Regarding "I was thinking some kind of strange hashing approach", hashing is usually only used for data verification. i.e. to ensure it was not modified en-route to you.
Hope this helps.
I'm trying to write a set of simple client/server applications in C# that should communicate with each other through custom RPC-like requests/responses. I want to have everything symmetrically encrypted with a pre-shared key (which the user supplied to each endpoint beforehand), and nonces against replay attacks.
I initially planned to simply use a TCP socket with my own message format and run the packets through AES by hand... but then I read about Remoting and thought that it could make the whole RPC-stuff much simpler for me. But I can't figure out how to use it with encryption (I know I could encrypt every marshalled parameter manually, but there's got to be a better way).
I've found some links about using it with the "secure=true" property, but I don't understand how that works. There seems to be no place to input a key or choose an encryption method, so I guess it uses some "automatic" Windows-internal magic that has to be set up by an administrator and probably doesn't work between domains.
Is there any way to use Remoting with this simple encryption scheme, or what else would be the best way to do this? I don't want to use overblown protocol stacks (with SOAP or HTTP-tunneling, or complicated key-exchange mechanisms, or certificates) - I want something that just works out of the box at any two hosts when you type in the same password.