I have 2 servers lets name them serverA and serverFirebase
serverA has no internet access and only accessible in a local network and it hosts a .net application
serverFirebase is google firebase server
i need to send a request from serverA to serverFirebase but i can't because serverA has no internet access
the solution that came to my mind is that since the browser (that shows the web app from serverA) has internet access i could proxy my request using his browser
so it would be like this
serverA -> browser -> serverFirebase
now the way that i wanna do this is like this:
1 - create a rsa key pair and have the private key in serverA and the public key in serverFirebase
2 - in serverA create a sha256 hash of the request payload and padd it and sign it using the priavte key (note that the request payload has an order number that can only be used once)
3 - send the payload and the signed hash to browser
4 - send the payload and the signed hash from borwser to serverFirebase
5 - in serverFirebase decrypt the signed hash using the public key and compare it to the hash of the payload and check that the order number hasn't been used before
my question is that is this method secure enough? and if there are any protocols to handle this situation already.
thanks
I think that depends on your threat model and who you expect your attackers to be and what you are assuming about the environment.
Without making this too complicated, one avenue of attack that comes to mind is man-in-the-middle between the browser and the serverFirebase. An attacker can potentially just read the messages you're generating on serverA and store it. Since he can read your messages (you're only signing the digest and leaving the payload itself unencrypted), he knows what they say and send the messages he wants, in an ordering that he wants, and whenever he wants.
If for example, your first message is buy 200 shares of Penny Stock and your next message is sell 100 shares of Penny Stock. The attacker can potentially only relay the first message and not the second.
Related
I have a game I am working on that is client/server (fully authoritative). The game is not FPS or MMORPG. More like Clash of Clans where you can see other people's attacks, chat, manage your resources etc but no real-time players in the same battle/attack.
Nothing is saved on the client's phone (other than its uniqueID). So when it logs in, the server sends the player's current state/data.
Now, if the client wants to do something (move a unit, collect coins, start building something, etc)
The server will validate everything, of course, to prevent cheating.
However, I see 2 approaches:
1: No acknowledgment from the server
The client decides to do something, it is automatically applied on the client's side and it sends this information to the server.
The server validates the action. If it is legal, store the new information and do nothing.
No acknowledgment is sent to the client
The client was not waiting for acknowledgment either.
If the action was not valid (it means the client was cheating). The server does not save the state and close the connection.
2: Fully acknowledged
The client decides to do something, it sends this information to the server and waits (nothing happens on the client at the moment)
The server validates the action. If it is legal, store the new information.
Server sends the acknowledgment + the new state to the client.
The client then applies the new state.
If the action was not valid, it does not store the new information and sends an "invalid action" to the client. It can also decide to close the connection.
Option 1 reduces considerably the traffic between the client and server, plus the player does not feel "lags" when doing an action. And it does not remove the authoritative validation of the server.
Option 2 makes it more "legit" in the sense the client can never "see" an illegal move and the server always acknowledge something before the client can see it.
I assume most FPS will use something closer to option 2, but since it is not real-time I would assume option 1 would be ideal.
Any reason option 1 would cause an issue and I should go for option 2?
My team wants to build a chat app and so we are researching about all the available technologies available at our arsenal. I am concerned about XMPP. So i was reading the Oreilly's "XMPP: The definitive guide", and came across these lines and i quote
In XMPP, messages are delivered as fast as possible over the network. Let’s say that Alice sends a message from her new account on the wonderland.lit server to her sister on the realworld.lit server. Her client effectively “uploads” the message to wonderland.lit by pushing a message stanza over a client-to-server XML stream. The wonderland.lit server then stamps a from address on the stanza and checks the to ad- dress in order to see how the stanza needs to be handled (without performing any deep packet inspection or XML parsing, since that would eat into the delivery time). Seeing that the message stanza is bound for the realworld.lit server, the wonderland.lit server then immediately routes the message to realworld.lit over a server-to-server XML stream (with no intermediate hops).Page 45
Like email, but unlike the Web, XMPP systems involve a great deal of inter-domain connections. However, when you send an XMPP message to one of your contacts at a different domain, your client connects to your “home” server, which then connects directly to your contact’s server without intermediate hops (see Figure 2-4).Page 13
Can anyone please make me understand how can there be no intermediate hops(unlike email).
E-Mail (SMTP) also has no intermediate hops. I assume you confuse the application OSI layer, where XMPP, SMTP and so on live, with the network layer (IP).
I am interested in the bit-level goings-on of computer networks, and have been using Wireshark to look at outgoing packets my computer sends when I send messages into the message box of a text-based game, which is hosted on an external web server.
Every time I post a message, I can see a TLSv1.2 packet is sent out, the payload of which is encrypted. My question is how would I go about encrypting outgoing packets myself (using C++)?
My only thoughts on this are that, since encryption happens locally and probably inside my web browser process, I might be able to send a message, note the encrypted output, and then use a time-travel debugger to look inside the process memory, watch for when memory was set to whatever was sent out, then go backwards in the assembly code to try to work out what it's doing. I think there is probably a better way.
Equally, when the server sends messages back, how could I use code to decode those?
I am aware my browser has been given a cookie which looks like a private key, would the process use this cookie for encrypting and decrypting, or is that a red herring?
If I connect directly to another computer, I proof my IP. But what if I want to receive a message on paper which proofs someones IP?
For example, client contacts Google for an JSON web signature, prints it out on paper, gives the paper to me, and I can verify the signature of the message containing their IP, without ever connecting over to the client (or to Google) by TCP.
Is there a simpeler or better scheme possible?
If you use encryption, consider using HMAC. If not, then a simple hash or random number is fine for trivial use, as long as it is unique for a given period of time and then expires. Either way, you can send the generated value across both transports so they can be matched to each other. Preferably the server should generate the value to ensure its authenticity, eg:
"Hello TCP client, send me XXX and your IP over the other transport".
"Hello transport client, I see you sent me value XXX and IP YYY, I have a matching TCP client".
Also keep in mind that if your TCP client is behind a router, the other party is going to see your router's public IP, not your client's private IP behind the router. So your client will have to send the router's IP, and maybe also send its private IP as well. Depends on your actual needs.
I don't really see the need to validate the IP, though. Just dealing with the router situation, let alone trying to avoid IP spoofing, makes it almost not worth doing. Just having an authenticated token should be good enough.
Update: If that is not what you want, then you have to include the IP as part of the encryption/hash. The client takes some seed values (sometimes known as nonce values) and its IP and hashes them all together, then the result is given to the other party. That party uses the same seed/nonce values and the IP it wants to validate and hashes them together and sees if it comes up with the same result. If so, the IPs match.
Good morning everyone.
I've been reading (most of it here in stack overflow) about how to make a secure password authentication (hashing n times, using salt, etc) but I'm in doubt of how I'll actually implement it in my TCP client-server architecture.
I have already implemented and tested the methods I need (using jasypt digester), but my doubt is where to do the hashing and its verification.
As for what I read, a good practice is to avoid transmitting the password. In this case, the server would send the hashed password and the client would test it with the one entered by the user. After that I have to tell the server if the authentication was successful or not. Ok, this won't work becouse anyone who connect to the socket the server is reading and send a "authentication ok" will be logged on.
The other option is to send the password's has to the server. In this case I don't see any actual benefit from hashing, since the "attacker" will have to just send the same hash to authenticate.
Probably I'm not getting some details, so, can anyone give me a light on this?
The short answer to your question is definitely on the side that permanently stores the hashes of the passwords.
The long answer: hashing passwords only allows to prevent an attacker with read-only access to your passwords storage (e.g. database) from escalating to higher power levels and to prevent you knowing the actual secret password, because lots of users use same pass across multiple services (good description here and here). That is why you need to do the validation on the storage side (because otherwize, as you've mentioned, attacker would just send "validation ok" message and that's it).
However if you want to implement truly secure connection, simple passwords hashing is not enough (as you've also mentioned, attacker could sniff TCP traffic and reveal the hash). For this purpose you need to establish a secure connection, which is much harder than just hashing password (in web world a page where you enter your pass should always be served over HTTPS). The SSL/TLS should be used for this, however these protocols lie on top of TCP, so you might need another solution (in common, you need to have a trusted certificate source, need to validate the server cert, need to generate a common symmetric encryption key and then encrypt all data you send). After you've established secure encrypted connection, encrypted data is useless to sniff, the attacker would never know the hash of the password.