Here's a use case:
I have a desktop application (built using Eclipse RCP) which on start, pops open a dialog box with 'UserName' and 'Password' fields in it. Once the end user, inputs his UserName and Password, a server is contacted (a spring remote-servlet, with the client side being a spring httpclient: similar to the approaches here.), and authentication is performed on the server side.
A few questions related to the above mentioned scenario:
If said this authentication service were to go down, what would be the best way to handle further proceedings? Authentication is something that I cannot do away with. Would running the desktop client in a "limited" mode be a good idea? For instance, important features/menus/views will be disabled, rest of the application will be accessible?
Should I have a back up authentication service running on a different machine, working as a backup?
What are the general best-practices in this scenario? I remember reading about google gears and how it would let you edit and do stuff offline - should something like this be designed?
Please let me know your design/architectural comments/suggestions. Appreciate your help.
The simple answer is: Don't let the authentication service go down!
Make sure your authentication service is running in a clustered, load balanced environment behind a virtual IP. That way, you can avoid downtime in the event that one of the individual servers goes down. This goes for not only the service itself, but any data sources that it relies on.
Obviously no system is completely fail-safe, but you should be able to get your uptime close enough to 100% that there is no need to build a "limited" mode for the desktop client.
Should I have a back up authentication service running on a different machine, working as a backup?
Yes! This would be the best solution. The issue should IMO be dealt with on the network/infrastructure level, not on the client.
If there are useful parts of the application that could still function with no network access (e.g. router down, NIC goes pop), option 1 might be considered. Offset the amount of work necessary against how likely this is and how critical your app is.
If said this authentication service
were to go down, what would be the
best way to handle further
proceedings? Authentication is
something that I cannot do away with.
Would running the desktop client in a
"limited" mode be a good idea? For
instance, important
features/menus/views will be disabled,
rest of the application will be
accessible?
Running the desktop client in a limited way is a very good idea. Imagine if you were unable to write an email, perpare attachments, or do anything in an email client if you were not logged in. A good user experience demands the ability to work offline.
Should I have a back up authentication
service running on a different
machine, working as a backup?
This has been answers very well by others already although I don't agree entirely with dbyrne. Even though all your networks and servers may be running fine, downtime is inevitable and the communication between the desktop client and the server will not always be perfect.
If said this authentication service were to go down, what would be
the best way to handle further
proceedings? Authentication is
something that I cannot do away with.
Would running the desktop client in a
"limited" mode be a good idea? For
instance, important
features/menus/views will be disabled,
rest of the application will be
accessible?
Is the client useful without the server? Are there things the user can do? If so, do you want the user to be able to do these things without authenticating? That's the answer to your question.
It isn't clear what you mean when you say: "Authentication is something that I cannot do away with." what you mean. Do you mean that there are some features that require the user to be authenticated, or that it is a requirement imposed by someone else, or ? (Why can't you do away with it?)
Should I have a back up authentication service running on a
different machine, working as a
backup?
How useful is your client in the situation above? If it is very useful, then you can base this decision and how much to spend on maintaining a backup server on how valuable the authenticated features are alone.
If your application is useless without authentication, then base your decision as to how much to invest in a backup authentication server on how much it costs you when your users cannot authenticate.
What are the general best-practices in this scenario? I
remember reading about google gears
and how it would let you edit and do
stuff offline - should something like
this be designed?
If there is a way to keep useful data offline, I think that's a good idea, but I am biased against keeping my information in the cloud where I can't control it or back it up. It will cost time and implicitly money to develop the ability to do both online and offline versus just one of the two. This is a judgement call on how valuable the application is to your users when offline.
Related
Read an interesting article about securing XP,http://www.expertreviews.co.uk/software/1304965/when-windows-xp-support-ends-this-is-how-you-secure-your-pc-and-save-all-updates.
With these suggestions is building apps for the marketplace ok with this setup to get by w/o headaches.
Here are my noob thoughts and question:
Just learning to code. Do you think I could run a limited setup to learn languages Java and C# while still being able to use my desktop for deployment of apps? A limited login as described only allows certain actions which I believe is different than a typical guest account. I wonder if my comp could still act as a server to retrieve data requested by users away from my machine. I figure I would need to be logged in as an admin to make some changes but, would hope that tasking processes or jobs could still be done.
I guess my question is, do users of a program you made need access to a local machine for some functions and would that work in limited?
I would like to get something portable and keep my desktop for business to be economical and not run the risk of logging on to an unsecure Wi-Fi with a portable that has business use. Ideally, I'd pony up for newer, better. I'm just learning though.
Do users of a program you made need access to a local machine for some functions and would that work in limited.
No. If you need some sort of server backend for your app a personal computer would be a bad choice for several reasons:
It would need to be available at all times: you can't frequently turn it off or restart.
It would require the same ip address.
It could consume a good amount of you're computer's resources, making it difficult to use for personal use
Instead you should probably be using a dedicated server or a cloud based solution, of which several offer free usage tiers.
I wish to connect to a Mysql Database with Java without revealing the password to anyone that may decompile my code? I can efficiently connect to a database, but my ways will openly show my password in the code :( and wish only a response on how to hide the password. Thanks is advance, Josh Aurora
OAuth allows client connection without storing credentials on client ( used widely on mobile devices or to identify tweitte applications ). It also allows to remove access permissions from rogue clients. But I doubt that mysql suzpports this directly,. so you will have to wrap your database with some kind of service layer. One of usable imaplementations of OAuth:
http://code.google.com/p/oauth-signpost/
(IIRC, used by Qipe )
Assuming that the database which will be accessed will be on your machines, two things that come to mind:
Set up a small secure REST service (as shown here) which will, upon a certain request with certain credentials, pass the password to your database. This however might be an issue if your application is sitting behind some corporate firewall since you might need to add firewall exceptions, which is something that not all administrators are enthusiastic about.
You could use a mix of Cryptography and Obfuscation to encrypt the password to the database and then obfuscate all your code.
As a note though, either of these methods can, in time be broken. This is basically the rule about all security related software.
If it where up to me, I would go about this problem using the first approach and make sure that the credentials through which the service is accessed are changed often.
However, databases which are used as part of a client solution contain pretty sensitive data which is in the client's interest not to tamper with, so the client will most likely not mess around with it, he/she will be happy as long as the system works.
If on the other hand, the database is not deployed onto one of your machines then you can't really do much about it. You could recommend that the server will be stored on a remote machine with access only over the intranet, but other than that, I do not think you can do much about it.
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.
I've been thrown in at the deep end a bit here, as I never expected I would have to do something like this and I have no idea where to start; so I'm helping somebody will be able to help me (ideally by providing some java code)...
In my effort to protect my Java software from piracy I have found that it is completely impossible unless I continusely check online - so thats what I want to do. Only, the only details I know are that, my program needs to communicate with some sort of script online and verify the licence key the program is using and then report back accordingly.
However, that's all I know - I am still stuck as to what the server side actually consists of. I'm hoping that the fact I am not hosting the website myself (an using JustHost) will not stop me from being able to do what I need.
So basically, I would like some help in creating a setup that allows my prevent anyone from pirating my software while connected to the internet. I though about having something like a login system; the users licence key would act as a username and password, but to be honest I really have no idea because if I did it that way would have to manually login and logout each time they wanted to use the software.
And not to run before I can walk but what happens when the user is not connected to internet? Even worse, how do I tell if somebody has stealed an legitamate users licence key? etc.
Thanks in Advance,
Andy
PS If it helps, I plan to use PostgreSQL (or maybe MySQL) and I am not paying for a dedicated server with JustHost.com...
Once your code is on their machine they can modify to simply ignore your checks. You can make it as hard as possible but it will never be hack proof.
In general your question is identical to this one which has some good discussion.
Try to delegate part of your business logic to server side. This way some core processes can not complete unless the application license is valid. Of course, if you have some logic that can be delegated. If your application is client-only than this approach is a bad choice.
If your application will be sold for a lot of money, try implementing solution using HASP key approach (which is investment by itself) instead of server authentication I understand this is not what you asked, I am just giving another idea.
try to create security by obfuscation/encryption and you will fail if your application becomes popular, since there will always be someone who will crack it in 5 minutes :(
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.