GeeCON Prague 2014*
The moose likes Security and the fly likes Security for 2 Products. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Security
Bookmark "Security for 2 Products." Watch "Security for 2 Products." New topic
Author

Security for 2 Products.

Aman Mohd
Greenhorn

Joined: Feb 26, 2009
Posts: 13
I am working on a new product which needs to be developed and finally integrated into an existing product. The integration model of these 2 products needs to be planned in such a way that based on what the customer has purchased the appropriate tabs, links and pages show up. If a customer purchases just one of the interfaces; that is the only interface available to be seen by the customer and he can see links pertaining to that application. If there is a situation in which the customer has purchased both the modules, both of them should show up seamlessly without any changes to the application.

Possible solution: Configuring the applications through the database. The information is stored in the database about which application the user can see based on what has been purchased.
Pros: Easily configurable during deployment. Need to set a flag which would render and show certain tabs\links\pages based on permissions
Cons: Less security and easy for the customer to figure out if they are tech savvy. Leaves a lot in the database which is available to the customer.

I am using JBOSS AS 5.1. Is there something that can be done in the jndi.properties file? Just wondering if that can be done and can be encrypted and left.

Are there any good solutions to problems like these? Appreciate any help from your side.
Thanks!



Arshad Noor
Ranch Hand

Joined: Oct 06, 2011
Posts: 34
Probably the best way to do this is to use digitally signed objects and store them in the database or a properties file. If the user buys feature-1, then the digital signature on a "Feature-1" object can be verified by your Public Key at run-time. If they buy feature-2, then send them a tool that will import "Feature-2" into the database; this can be verfiied by your software at run-time. They will not be able to create such a digitally signed object by themselves. But, if the signed object is not tailored for each customer, all it takes is one customer to put out that signed "Feature-2" object on the internet and suddenly all your customers will be able to have both features available to them at no additional cost.

Arshad Noor
StrongAuth, Inc.
Aman Mohd
Greenhorn

Joined: Feb 26, 2009
Posts: 13
I was thinking if i can put the value in encrypted format, so even if the customer is techy he won’t be able to change value. We can use random salt while encrypting, so that if you encrypt same data multiple times each time you will get different value. Thought of using Jasypt (http://jasypt.org/encrypting-configuration.html). This type of information can be encrypted and set in the jndi.properties file or some properties file about which interface has been purchased. when the server starts it decrpts and automatically makes sure to load the right stuff from the database and in the application we would write the code on screens which have data elements which can be hidden.
Do you think this would work? Thanks for your reply.
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
Keep in mind that -if all this is Java code- then it can be decompiled and the authentication/authorization checks be patched out by a sufficiently motivated customer. The most secure solution, IMO, is not to ship code to the customer that they're not entitled to run. if they purchase a 2nd module later on, make it so you can send them a single file (jar, war, zip, whatever) to put on their server, and the apps configure everything from that point on.
Arshad Noor
Ranch Hand

Joined: Oct 06, 2011
Posts: 34
@Aman: Given that you mention "random salt", you're talking about symmetric-key encryption. This is not going to be secure. In order for you to decrypt the value so you can determine what it is, you will need the cryptographic key on that machine. Once you distribute the key (and, as Tim points out, it can be decompiled and determined), your security is shot.

The only kind of technology that could potentially work without giving away secrets is a digital signature. The attestation can be in plaintext (completely visible), but the attestation cannot be duplicated because the user does not have the Private Key to digitally sign the attestation - you do, in your Engineering department. You only need to distribute the Public Key in your software to verify the signed object (there is no risk in distributing the Public Key). However, once again, as Tim points out, a motivated attacker can figure out where your Public Key is being accessed, and replace the file with a Public Key of their own. Then, all they have to do is digitally sign a modified object they created, with their Private Key and the software is off to the races. You can embed all this into your software, but it can be decompiled and modified - unless, you also include obfuscation in your engineering process.

With an internet connected computer, you have a slightly better chance because you can download the Public Key and another digitally signed object to verify its authenticity; but at this point, I'm not sure if your business model is compromised heavily and you've inconvenienced your customers significantly to the point that they choose to go with an alternate solution.

You might want to consider another business model - one that we chose a decade ago from a strategic point of view. Its not for everyone, but its worth considering.

All we produce at our company is cryptographic software, and setup complex cryptographic key-management systems (so, we know something about this). We've chosen to open-source everything. In the first place, what we do is very complex; we don't want to burden ourselves and our customers with additional complexity when we don't need to - it only adds to support headaches. Secondly, we add value in the services we provide and the knowledge/capability we bring to the table with the product. This is extraordinarly useful at a time when data-security regulations are getting more complex. Third, we price our services right so there is little incentive for a customer to try to get around our guaranteed lowest price. Finally, it indicates something about our relationship with the market when we don't presuppose that the market is going to cheat us.

This business model can work wonders for you, because all you now have to do is focus on creating good technology, and deliver it with great service. Price it right and the world will find you - even though we are a small office in Sunnyvale, CA, our customers come to us from Abu Dhabi, Australia, Canada, Columbia, Germany, Hong Kong, India, Italy, Philippines, UK - and of course, the USA. So, we know the model works. You won't always win every customer, but the ones you do - you know why they choose you and why they choose to remain with you.

I hope that helps. Good luck.

Arshad Noor
StrongAuth, Inc.
 
GeeCON Prague 2014
 
subject: Security for 2 Products.