I need to be able to transmit data from a Flash browser application to a PHP file on a web server, both securing and validating the data whilst and at the same time trying to prevent unauthorised creation of the message. (I want to try and ensure that the message comes from the application, not a user sending a message via another means).
In a C++ application I would Salt the data, and send the hash of the data along with it, and then validate the hash against the data to ensure integrity and source.
However, in Flash (& Java), applications can be decompiled so that the source code is viewable. So if I used this method, someone could (relatively) easily find the salt, and then create a 'valid' message of their own to send outside of the application.
Is there any way I can 'hide' this salt code to help secure the transmission? Yes, I know there are code obfuscators, but they don't fully hide the code, just add another layer.
Or is there another method entirely that could be used to transmit data and validate the source & content at the PHP end?
No matter what you do, the code to do it will be there in the client, and all you can do is obfuscate. If you, as Tomasz says, were to have the client authenticate with the server and then receive a salt (or a key from a asymmetric key-pair) you still need to have all the code necessary to connect to that server in the client. So by design, no matter what you do, all the ingredients to do so has to be in the client, and thus on your "hackers" computer. It's just a question of much harder it would be for a hacker to understand it.
It's the same for all kinds of clients, no matter what language they're written in. If a DVD player can show a decrypted DVD disc on your TV, it has to have the key to decrypt it in memory, which you can find. This is why no-one has made perfect copy-protection :)
EDIT:
As all the others are saying. Off-the-shelf obfuscator is probably the best way to go, and you could make the client jump through some extra hoops first aswell.
EDIT2:
Turns out I didn't understand Tomasz correctly. If the user himself has the key to authenticate to the server in order to get the hash, that will indeed authenticate that the message was sent from the user, but still not from the application. If this is a matter of avoiding cheating then the hacker is probably already a customer (buying a product or making an account). If what you want is to authenticate the user, then it's a completely different matter, and that is quite possible. (with it's own problems of-course)
There's no truly secure way to protect programs that run on the client. (C++ can also be decompiled by the way.) It's always going to be possible for users to run clients that have been hacked, and any encryption key will have to be present in the code in some form. You may be able to make it more difficult for casual hackers but that's it. Whatever you implement will amount to another form of obfuscation; you may as well look at the off-the-shelf obfuscators.
Perhaps first authenticate with the server, get a salt key from the server, then use it? This way users wanting to fake messages even if capable of decompiling the app would have to authenticate also.
Other than that - at some time you always need the password, hash, key (or whatever is needed to encrypt or validate data) available to the application and either you get it first from your server or embed in the application, which would be recognizable by decompilation.
EDIT
As others have pointed there is no 100% security, everything can be hacked, the point is to make it not too easy, to prevent casual hackers, that's all. So as Jim stated an off-the-shell obfuscator may be the best compromise.
Related
I'm looking for a way to generate a key on my app to connect to an API on my server, in the past users have decompiled the app and found the key, but with this method they can see how I generate the key but can't generate themselves the same key.
But still not sure if it is safe to use:
getClass().getHash();
Along with HTTPS it should be safe or am I missing something?
No, it's not secure. If one can decompile your code, then he/she can always retrieve any stored or computed information, even if obfuscation takes place (it would be harder to spot it, but again one can dig more and find it).
Check this similar post suggesting Jasypt or some other practices to use/store passwords in your projects.
There is still no safe solution to store credentials, as a successful decompilation can always retrieve it. You could ask from a user to type a password on each run and temporarily keep it on memory, but it seems you are interested in keeping this information secret even from your legitimate users. Also, if you use a client cert, then one could copy/reuse it in another instance of your program.
One could even utilize embedded devices (eg smart cards), where you need advanced hardware intervention knowledge and tools to extract private keys/passwords. But again, you need a sophisticated protocol (eg combining MAC/IP), as an advanced hacker could perform a replay attack (copy/paste/share the encrypted output of the smartcard), so he can use it on another run instance.
That's why there is still software piracy out there! Find a working solution and you'll get rich!
I am going to make an application (iOS and Android) that will use a web service that I am developing. I will use HTTPS and SSL so that the data sent from the app to the server is secured. However how do I stop (or make the life of people who decompile the app hard) "hackers" from decompiling the source code where the URL is written?
I don't want other people to make an application that use my data.
The users of my app will have to register and login in order to use it. I have read something about authenticating the users and pass a key back (the way Facebook does). However wouldn't this mean that a "hacker" could sign up and then use the same key? Would you need to track the usage of each key to look for irregular use?
The server technology is either Java EE or Scala (Lift).
First: There is no 100% security for anything you run on a device that is not under your control (like iOS and Android devices in your case).
You could make "abuse" harder by several measures:
issue a session key after a successfull login with a time-limit so a new login needs to happen after a certain time has passed by
issue an interaction key for every communication step which gets invalidated right after one usage
when a successfull login happens terminate any other session associated with the same credentials that might be active before that login
"throttle" usage (might be impossible depending on the specific application)
IF you really really want to make it very hard you can issue a device-specific client-certificate and use cert-based client authentication (defined in SSL standard) - you can invalidate the cert associated with the device if you see abuse without harm for the legitimate users of other devices...
This is more-or-less impossible. You can use bytecode obfuscation to make decompiling harder, but anyone who tries hard enough can see what the code is doing.
If you are allowing access to the data to people that you can't trust, then the only things you can do are to
ask nicely (please don't abuse my data)
authenticate users so you can monitor individual usage, and maybe apply usage or rate limits (like Twitter does)
make people sign a legal agreement (unlikely to attract many users unless your data/app is very valuable to them!)
Also consider whether you can do more server-side processing so that less raw data is sent to the client. I don't know what your data is like, but taking the example of maps, if you send a pre-rendered bitmap rather than some lat/long vector data, then extracting anything useful is much harder work.
Im about to put my Android app on the marketplace. I recently encrypted all of my server/client communication. What i am wondering is if my data is encrypted using a specialized key, and if a person decompiles my code and extracts the key, then is it even worth encrypting the data in the first place? My communications ran a lot faster when the data wasn't encrypted. With the game being an action game, lag is going to be a huge "fun killer" and from experience i know it is frustrating. I know the encryption makes the app a lot safer, it makes it safer for the gamers and the server but it causes huge lag. Is the security worth the deduction in performance? Is even worth using encryption when your code can just be decompiled? I already use Android Proguard but if someone really wanted to decompile my code, they would take the time to sort through all of that garbage.
I think, it is safe to operate under these assumptions.
Client cannot be trusted. Ever.
Server is authoritative source of information.
Don't trust data that clients send you, make checks and validations against it (like if someone tries to 'teleport' from one map corner to another, by sending modified location).
Accept only data that's valid.
Ban cheaters.
Encryption is ok, but when it does not harm the game or gameplay (in your case it does).
You put the encryption key in the client code? Well that is worthless, encryption on the other hand is totally worth it, the problem is you chose the wrong way of doing it.
I would have probably used authentication instead of encryption (hashing all the data you are sending so that you can verify it at the server end). This will work for ordinary game info, because there is not much need for confidentiality. Unless you are sending in private user info like name, age, credit card info etc., I suggest you use plain authentication which is much faster than encryption. You can go for really simple hash functions or if you think that your game really motivates people to tamper with it, then you can use military grade hash functions like SHA-256 or above. But no matter which hash scheme you use, it should be much less time/resource consuming than implementing a proper encryption scheme.
I'm thinking about encryption in an application. The architecture consists of:
Server
Desktop client
Web client
mobile client
The goal is to allow user to store his data on the server, and access it from all clients, but to guarantee data privacy by encrypting data on the client.
Dropbox is an example of such an architecture, but as far as I know they don't do that - they must store plaintext data on their servers, otherwise they wouldn't be able to save on space by storing the same file only once, even if it was stored by multiple users.
How would you implement such an application? I'm thinking about using Java for desktop client; the same encryption code could theoretically be reused in GWT web client (compiled to Javascript) and in Android client. However, that's only in theory.
Is there an encryption library that's available on all these platforms?
What algorithms to use?
What about private keys? I can ask user for the password every time, but how do I ensure that private keys are the same for the same user in all clients?
I'd like to avoid multiple passwords; but if I use the same password for both data and authentication, how do I prevent server from giving data to a hacker which supplied the wrong password, or server from being able to decrypt user data because it has user's password?
What possible gotchas are there?
You actually need a few different pieces of cryto.
First, you want the client to encrypt the file for upload, and upon retrieving the encrypted payload back decrypt it.
Second, you want some method to transmitting the encrypted file for upload in a manner that insures that only the correct user can access his files.
The first problem requires a symmetric encryption algorithm. There are a bunch out there, but your best bet is probably AES. If you take a look at gwt-crypto at they have a wrapper for the java bouncy castle implementation. That takes care of two of three of your platforms. I don't work with android platform, but I'd be surprised if there wasn't an AES implementation floating around. As for the key, you'll probably end up with a hash of a password. Just keep in mind the possibility of rainbow tables and take appropriate measures. The password used to encrypt the file need never go over the wire, as I understand your model all encryption and deception is done on the client. Since you mentioned system administrators as a potential attacker, you really need to look into key loggers, memory dumps and the like, but that's beyond the scope of the specific question you asked.
The second problem is a solved problem using TLS with client and server side certificates. Clients for such are available for all three platforms you are looking at. Whether you want make your users go through the hassle of installing client side certificates, though, is up to you. There are various fallback options but none are as well vetted.
I'm in the process of developing an application that uses client side code (js to be specific), which needs to be secured. I.e. so that a user cannot steal the code and reuse it. Obfuscation is not an option, as I need the code to be fully secured (with encryption). After extensively scouring the internet for a solution that allows js encryption I have come come to the conclusion that this proprietary code can only be executed server side to ensure its security.
Does any one have any other ideas or solutions, that would relieve the server from having to process things that otherwise could be done on the client with js. Executing some of the code on the server is an option, but resources are limited. Another issue is that it would need to be something like "server side js" i.e. the user experience is not changed.
If the code is client side, they have the code. Period. That's how the internet works.
If you want to protect it from the end-user, then yes, you need to keep that on the server side. Alas, that will change the user experience. There really isn't a way around that, though perhaps via judicious AJAX calls you can find a happy medium.
Nope, it sounds like you've pretty much got the gist of things. Use the server to process anything that needs to be done securely. Use javascript to display the data sent from the server.
I don't know what application you're working on, but typically efforts to offload significant processing onto the client side involve so much data transfer that the server has to do more work in the long run. Can I ask what kind of processing you're wanting to do client-side?
The user experience would have to be changed for a server-side solution, simply by the fact that you'd be running code on a different box, with a network between the two. The latency will be different. It may be good enough, of course, but it's hard to say without knowing what kind of app it is.
The closest I can imagine is hosting some sort of JavaScript engine within an otherwise-secure application... but you can tell from the state of the games industry's attempts how easy they've found it to make unhackable client code. Basically, if it's going to run locally, the code has to be there to execute... and that means it can be inspected. All you can do is make it harder.
You could encrypt your javascript and then decrypt&eval it on the client side. If it´s a private application, you could use a password for the encryption, so anyone without password could not decrypt it. Otherwise you should make it really complex.
Apart from standard JS obfuscation which is discussed e.g. here: https://stackoverflow.com/questions/2285593/how-to-sell-and-protect-software-that-has-easily-visible-source-like-javascript
this is close to impossible to do.
I would tend to question whether there really is a need to protect the client side code in the first place. What makes it so unique that this is necessary? Any kind of sensitive data manipulation should be done on the server side anyway, as every obfuscation method will always be only imperfect protection.