I need to secure the communication between two backend servers. A simple api key was rejected by our security policy since attackers would be able to intercept it.
IP restriction also, because it could be spoofed.
I was suggested to use a nonce, but wouldn't this mean that a request requires two roundtrips? I don't really like the idea of having twice the latency.
without your description it's hard to be able to suggest the best way to do it.
If both servers are inside the same Datacenter, you can have some solution to have a private network.
If that's not the case, you can have and authentication system (oauth?) with a token which will be create and validated.
You can use some other techno to sign your data with private and public keys.
The nonce could be good too.
But if your servers are in a DC, they should have the same IP and not move. So why not have a whitelist (IP based) and something else like a nonce or a token
Related
This is my first time writing a public facing web api.
My manager is suggesting not to use API key for a Web API I am writing because we are white listing the ip of the client consuming the api and doesn't think we need to bother with API key (ie extra time and complexity)
I am interested in the opinion of others.
I think we do require API key for the following reasons in DESCENDING order of importance.
Allow tracking and limiting of requests from client based on API key. Their ip may possibly change from time to time but the api key should not. So future reporting of requests would be easier with api key
The whitelisted ip can be spoofed? From the reading I have done I think the fact TLS will be enabled makes this impossible because a handshake between server and client is done so a spoofed ip would cause a failure of this handshake?
He doesn't have a clue and I should ignore him on principle :-)
Does the fact that we are relying on whitelisted ips remove the need for seperate Authentication using the API key (the client has access to all of the api so no need for Authorization)?
Trusting just on ip white listing increases the risk:
1) An operator error can white list a wrong ip or ip range.
2) It increases the security requirements for the client: no insecure software can run from those machines or from machines that can share or hijack that external ip.
I'd say that a safer system would rely on ip white listing and client ssl certificates.
Your case might be special. However, as a general rule, I'd recommend against using only ip white listing.
We have a HTTP endpoint where a form request is posted containing transaction data from a 3rd party https website.
We are investigating ways that our HTTP endpoint can contain code to check that the host that posted the request is the 3rd party website and no-one else (i.e. a hacker).
Is there any way our HTTP endpoint can authenticate with the website where the posted form request originated? Maybe by SSL Certificate Authentication?
Many thanks in advance.
To guarantee that the server on the other side is who they say they are the safest way is to have them use an SSL Certificate. If the they also need to trust who you are then each side should have their own SSL Certificate.
The IP Range solution provided in the comment could be a possible hack but it's quite brittle and it couldn't be applied in a very serious environment.
The Shared Key solution will work and it's reliable but you have to change keys from time to time depending on the volume of traffic between the two servers.
Hope this helps.
It might be better to use message-level security instead of transport-level security (SSL/TLS).
The third party website would sign the message using its certificate (or to be precise, using the private key matching its certificate), and your website would verify this signature.
This could allow for that message to be relayed by the user's browser, without needing a direct connection between the two servers.
This sort of mechanism already exists in the Identity Management world, for example with SAML and Shibboleth. (You can still have direct connections between the servers to get additional information too.)
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.
My client-side code calls the REST WCF service for changing passwords. I defined changePassword with "UriTemplate" set to "?user={userName}&oldPwd={oldHashPwd}&newPwd={newEncryptPwd}"
My question is: how to encrypt the new password on the client side so that we can successfully decrypt it on the server side ? Please be specific. Thanks.
Use HTTPS. If the whole communication is encrypted, you won't even need to encrypt/decrypt the password individually.
Beyond HTTPS, you could use a secure, salted password hash on the client side. That would mean even interception of the URL would be safe - having the hash would allow efficient "proof of ownership", but not discovery of the password.
Yinfang. You don't need to be worry to encrypt your password from client side that would only be decrypted on the server side. Now a days, there are so many channels through which you can protect you personal data like your passwords. One way is to check that whether yo use "HTTPS" for your browsing because it will provide you secure channel to send you information from one place to another.
On the other hand you can get VPN connection. Through which all of your information gets encrypted and provided secure channel to pass your personal sensitive data from client side to server. There are so many providers of VPN connection are available in the market like PureVPN, Hidemyass,switchvpn etc etc. If you want all of your information encrypted ans secure you can use these useful information.
Hope this could help. I use to encrypt data using Rijndael
Sample code here:
Cryptography
You can create logic on backend side and be used by the client side for encrypting and decrypting data.
You have 2 options to go with either "https" or "VPN/Proxy". Going through 'https' won't hazel much while encrypting anything on the web. I will give you smooth path to surf the web and do whatever you want. But the point is that if you are looking to get something more than just encryption then you should try VPN/Proxy. If you can google around then you will find that proxy is not that much safer. However, going through VPN is completely opposite to proxy. VPN is one of the best and most reliable feature that a user can have for their web. VPN absolutely anonymize one's identity and allow the local ISP to surf (encrypt/decrypt) user data with out any threats from hackers.
Hopefully a quick question.
I want to secure my WCF service that will be consumed by a known party. Our organisation trust theirs and vice versa.
This service is already restricted by IP address, so we know the caller must have come from their network.
However I would like it to be protected against malicious developers within that organisation. In theory they could write a Bad App and install it anywhere on this network, and call our service, which would return the data.
I think a way around this would be to also use Client Certificates, which would be validated using Peer Trust. Each request would send this certificate, which we would validate on the WCF service, and send back the data.
My question - is this going to protect against the malicious developer scenario outlined above? We would know that the request would have to originate on the server with the client certificate installed (right?) - and I imagine it should be difficult for a malicious developer to get a Bad App on there. It is a shame we can't tie it down to exactly the client application - or could we?
Any help appreciated - just want to make sure I nail my understanding of this!
If you will be granting access to your service based on the specific incoming client certificate, it should be as secure as the private key of that certificate. That is, if the private key is kept safe in the other organization, your service will be as safe (as safe as that public/private key pair of the certificate in terms of encryption).
If the private key is compromised within the other organization, for example, an attacker has access to it on the remote server, or is able to copy it to another remote server, then that attacker has access to your service. Because, once they have the private key, they can use the client certificate to connect using an SSL connection, and then they just have to pass the IP address check. Protect the client certificate's private key.
You may check on the service side if the client has authenticated itself with specific certificate. You may also write Custom Certificate Validator and validate certificate according to your own needs. However, if you assume that the attacker may be able to use private key of trusted certificate in your environment, then I guess you may assume that the attacker can basically do anything and there is no way you can secure your service.