I need to know how to make a trial version(e.g 30 days trial) of a client-server application which is implemented using Spring RMI(server side) and Java Swing(client side).
I'm thinking of doing this in client side by checking current date against first login date. But it might be hackable easily. What are the best options available to do this in a reliable manner?
Thanks.
If you have client-side configuration, add couple of new keys with the date when the client is first launched. People usually won't look into the application configuration for expiration dates.
And, choose the key that doesn't say that it is related to licensing and encrypt your value if possible.
If one key is tampered, you can use the other key to check whether it is tampered or not and block the access.
A better and safer solution would be to implement it on the server side.
You can make the client request for a token the first time it runs, and keep track of the token on the server. This has a drawback though,i.e. If someone deletes or reinstalls, you will never know.
You can also send a request for token with some identifying characteristics, i.e. MAC address. So that you will know if the client is making duplicate requests.
Even better, instead of tokens, keep track of the MAC addresses.
Related
I've have an application which send request to server side. my concern is that, a hacker could snoop traffic and resend the request after doing some modification in request itself.
I know the best way to solve this problem is to use SSL, but I think that will be an over killer for simple application like my application, I'm thinking to go with simple thing like MD5 algorithm.
This way if hacker tried to modify the request and resent it, at least I will discover that.
my question is that:
do you think this a good a approach, or you think there is a better way?
does the MD5 that is generated on iOS using objective C, will have the same value that is generated in Linux server using Java?
Traditionally you would need to make a hash from your payload + timestamp + secret token. Since only client and server know the token, you should be able to verify the hash correctly. And don't forget to include the timestamp in the transmission!
You may also want to encrypt the whole thing before sending - if the information is sensitive (like passwords, etc).
I believe MD5 will match if made on different systems (if done correctly).
I am making app, which would send value to php script. Then php script would conncect to Mysql database and return JSON array. And then the app would read it. How to ensure safety? For now I am not using any safety measures.
It depends, this is such a huge topic that a true answer would take a books worth of material.
What 'safety measures' are you asking about?
If you're talking about involving a web server, then you first need to secure your web server and build an API that is smart enough to protect against most common methods of attack. You need to make sure that other people - just by entering something in URL - cannot do the same thing your intended user can do. This means that you need to validate the user before giving them access to API.
Most common method of doing this is sharing a 'secret key' that only the server and client knows. So your user, with a phone, has a specific key and server has a key. Now user sends data to the server and also sends a validation hash (like sha1(KEY+DATA)). Server then receives data and makes sure that the hash is the same. Never send the key itself together with the request.
Another thing you need to test for are replay attacks. If someone listens in on the communication, then you have to limit the damage. This is usually done by you also sending a timestamp with the request and the server checking if the timestamp is within accepted range, so if someone sends that same request again later, it would fail due to timestamp being different. Server checks for this since timestamp is also taken into account for input data validation.
Then you have to make sure that the data returned from server is correct. So server will ALSO build a validation hash that your phone will check, making sure that someone didn't change the data while it was sent back to your phone.
As an added layer, you can also encrypt data that is sent (and received from API) with a heavy cryptography algorithm like AES/Rijndael 256bit encryption. This will encrypt data with a key that is required to open the data. If phone and server know the key and no one else does, then data can be sent securely.
Then the connection should be HTTPS/SSL, which helps protect communication from being listened in. But this does not help if someone already has access to your phone, so it is recommended to use the other mentioned methods as well.
As for your phone, it is pretty secure by itself as long as you don't have apps installed on it that might compromise that security. Also, if you think you can secure your web server less, thinking that since only phones communicate with it that it is safe, then a hacker can easily listen in on communication on their own phone and figure out the basics of your web service API and then open all the doors. So make sure your security layers go from biggest to smallest: web server is by far the biggest entity in your system.
As you can see, this is a MASSIVE topic that can take a long time to learn. But without knowing what exactly you were asking about, I cannot really help you any further.
I'm building a Flash-based Facebook game with a Java backend, and I'm planning to use a RESTful approach to connect the two of them (not a persistent socket connection). I'm using the AS3 library to connect the client to Facebook, so that's where I have my session information stored. However, how do I authorize client connections back to the server? I can't leave the callback URLs open since that'd let people manipulate game state without playing the game. I need to make sure that the calls are coming from a valid client and through a valid session.
At the moment, users have no direct login to the backend server -- it's all handled through the client frontend. Can I pass the Facebook OAuth2 access token to the backend in a way that the backend can verify its validity? Should that be enough to trust a valid frontend connection?
I could do a two legged OAuth signed request or just use a simple shared secret, but the keys would have to be packed in with the flash client, which makes that almost useless for this use case.
Somebody has to have solved this problem, but I can't find it.
If you are using Java as a backend, I would consider using BlazeDS. It is a great library for doing AMF connections (which are async so fit your non-persistent socket requirement). If you are using Spring on the backend at all, I'd highly recommend using Spring-Flex as well. It adds a bunch of goodies that make exposing AMF services a breeze. Also, it adds hooks to allow 'easy' integration of Spring Security.
For the oAuth stuff, I would move the oAuth portion to the web side instead of the flash client (which I think I understand is what you do now). This way you can authenticate the web session on the server side and secure the page that contains the .swf. Then when your user loads the .swf in your code (assuming you're using spring security integrated into BlazeDS) you can call cs.authenticated on your cs:mx.messaging.ChannelSet. This will work, but may be more reword than you want to do.
We had similar problem in one of our project. What we ended up doing was used the following token passing method:
1) Fresh client connects to the server and get a token that's valid for x amount of time.
2) The client has an obfuscated part of code that uses an algorithm to change the token (and this algorithm changes at some frequency in sync with the server). The client uses the algorithm to change the token and includes it in the next request to the server.
3) The server knows the original token and the algorithm so now it can check to see if the new token in valid and it's from a valid client.
4) The cycle continues.
This is no 100% secure, since someone can really spend time and analyze the communication and eventually understand the pattern, but you can play around with the algorithm so much and change it often enough to make it hard for someone to guess it.
Hope this helps.
P.S. The application that I'm talking about that uses this has been in production for past 5 years and gets ~300k unique users a day and no one has broken in yet.
I'm developing a server component that will serve requests for a embedded client, which is also under my control.
Right now everything is beta and the security works like this:
client sends username / password over https.
server returns access token.
client makes further requests over http with the access token in a custom header.
This is fine for a demo, but it has some problems that need to be fixed before releasing it:
Anyone can copy a login request, re-send it and get an access token back. As some users replied this is not an issue since it goes over https. My mistake.
Anyone can listen and get an access key just by inspecting the request headers.
I can think of a symmetric key encryption, with a timestamp so I can reject duplicate requests, but I was wondering if there are some well known good practices for this scenario (that seems a pretty common).
Thanks a lot for the insight.
PS: I'm using Java for the server and the client is coded in C++, just in case.
I don't get the first part, If the login request is https, how can anyone just copy it?
Regarding the second part, t This is a pretty standard session hijacking scenario. See this question. Of course you don't have the built-in browser options here, but the basic idea is the same - either send the token only over a secure connection when it matters, or in some way associate the token with the sending device.
In a browser, basically all you have is IP address (which isn't very good), but in your case you may be able to express something specific about your device that you validate against the request to ensure the same token isn't being used from somewhere else.
Edit: You could just be lucky here and be able to rule out the IP address changing behind proxies, and actually use it for this purpose.
But at the end of the day, it is much more secure to use https from a well-known and reviewed library rather than trying to roll your own here. I realize that https is an overhead, but rolling your own has big risks around missing obvious things that an attacker can exploit.
First question, just to get it out there: if you're concerned enough about nefarious client-impersonator accesses, why not carry out the entire conversation over HTTPS? Is the minimal performance hit significant enough for this application that it's not worth the added layer of security?
Second, how can someone replay the login request? If I'm not mistaken, that's taking place over HTTPS; if the connection is set up correctly, HTTPS prevents replay attacks using one-time nonces (see here).
One of the common recommendations is - use https
https man in the middle attack aside using https for the entire session should be reliable enough. You do not even need to worry about access tokens - https takes care of this for you.
Using http for further requests seems to introduce some vulnerabilities. Now anybody with a network sniffer can intercept your traffic steal the token and spoof your requests. you can build protection to prevent it - token encryption, use once tokens, etc. but in doing so you will be re-creating https.
Going back to the https man in the middle attack - it is based on somebody's ability to insert himself between your server and your client and funnel your requests through their code. It is all doable i.e. in case the attacker has access to the physical network. The problem such attacker will face is that he will not be able to give you a proper digital certificat - he does not have the private key you used to sign it. When https is accessed through a browser, the browser gives you a warning but still can let you through to the page.
In your case it is your client who will communicate with the server. And you can make sure that all proper validations of the certificate are in place. If you do that you should be fine
Edit
Seconding Yishai - yes some overhead is involved, primarily CPU, but if this additional overhead pushes your server over board, you have bigger problems with your app
I'm writing on a Java EE project which will have everything from 3-6 different clients. The project is open source, and I wonder what security mechanisms one could/should use. The problem is: Because it is open source, I would believe that it is possible for anyone with a user to write their own client (maybe not realistic, but truly possible) and make contact with the server/database. I've tried to go through all the scenarios of reading/writing different data to the database as different roles, and I conclude with that I have to have some security mechanism on a higher level than that (it is not enough to check if that account type is allowed to persist that entity with that ID and so on...). In some way I have to know that the client making contact is the correct client I wrote. Could signing the Jar files solve this entire problem, or is there other ways to do it?
-Yngve
I really think that if restricting the available activities on the server side (based on role) is not sufficient, than you've got a bigger problem. Even if a user doesn't write their own client, whatever mechanism you are using for your remote calls is likely to be vulnerable to being intercepted and manipulated. The bottom line is that you should limit the possible calls that can be made against the server, and should treat each call to the server as potentially malicious.
Can you think of an example scenario in which there's a server action that a particular authenticated user would be allowed to take that would be fine if they're using your client but dangerous if they're not using your client? If so I'd argue that you're relying too strongly on your client.
However, rather than just criticize I'd like to try to also offer some actual answers to your question as well. I don't think signing your jar file will be sufficient if you're imagining a malicious user; in general, public-key cryptography may not help you much since the hypothetical malicious user who is reverse-engineering your source will have access to your public key and so can spoof whatever authentication you build in.
Ultimately there has to be someone in the system you trust, and so you have to figure out who that is and base your security around them. For example, let's imagine that there may be many users at a particular company who you don't necessarily trust, and one admin who oversees them, who you do trust. In that scenario you could set up your client so that the admin has to enter a special code at startup, and have that code be kept in memory and passed along with any request. This way, even if the user reverse-engineers your code they won't have the admin code. Of course, the calls from your client to your server will still be vulnerable to being intercepted and manipulated (not to mention that this requirement would be a royal pain in the neck to your users).
Bottom line: if your user's machine is calling your server, than your user is calling your server. Don't trust your user. Limit what they can do, no matter what client they're using.
Well the source may be available for anyone, but the configuration of the deployment and the database certainly isn't. When you deploy the application you can add users with roles. The easiest thing to do is to persist them in a database. Of course the contents of the table will only be accessible to the database administrator. The database administrator will configure the application so that it can access the required tables. When a user tries to log in, he/she must supply a username and password. The application will read the table to authenticate/authorize the user.
This type of security is the most common one. To be really secure you must pass the credentials over a secure path (HTTPS). For a greater degree of security you can use HTTPS client authentication. You do this by generating a public key for every client and signing this with the private key of the server. Then the client needs to send this signed key with every request.
EDIT: A user being able to write his/her own client doesn't make the application less secure. He/she will still not be able to access the application, if it is required to log in first. If the log in is successful, then a session (cookie) will be created and it would be passed with every request. Have a look at Spring security. It does have a rather steep learning curve, but if you do it once, then you can add security in any application at a number of minutes.