This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
In our application, we propose to include some HTML templates in Jar(s). We would like to make it reasonably difficult for users to add, remove or modify templates. Presumably, Java security can do this, but what would be the simplest solution? I am experienced in Java, but new to security APIs, so please bear this in mind when replying. TIA.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
There is NO way. The problem for you is that jar files are based on the zip format. However, no security was built into it (Zip, such as winzip, does have very simple/useless security of a password, but that's NOT available for jars in Java.). So all they have to do is use winzip on windows or unzip on linux and they've got your HTML files.
It's not all that difficult, once you know how -- but if you're unfamiliar with PKI it can be a bit daunting at first. Jar the templates up in their own jar, then sign the jar using the jarsigner tool. This will provide each file with an unforgeable digital signature. You'll need to generate your signature first, but the keytool documentation does a reasonable job explaining that. I think (but am not 100% sure) that a simple self-signed certificate will do. The most straightforward way to verify the signature is not to store the jar in your CLASSPATH, but to open it explicitly using the JarFile class. You can then use JarEntry.getCertificates() to retrieve the certificate for each HTML file, and verify that they are yours by calling Certificate.verify() with your public key that your hardwire in your application. Since your users do not have your private key, they cannot add or modify templates and provide them with the right certificate. That leaves the problem of removing templates, which is easy enough to address by including a signed list of templates in the jar. - Peter [ June 25, 2003: Message edited by: Peter den Haan ]
That was a nice catch Peter! The only thing is, I'm not sure it totally fits his definition. What will happen is the users will change them and then see they don't work anymore. They'll then bug him and get him to send over a new version, wasting his time. But still, your idea is the only one that'd work. Nice!
Joined: Oct 30, 2001
Originally posted by Robert Paris: ... I'm not sure it totally fits his definition. What will happen is the users will change them and then see they don't work anymore. They'll then bug him and get him to send over a new version, wasting his time.
I think that it would fit my requirement. If users, who are not allowed to modify things, go ahead and try to do so, then they deserve whatever they get. Or perhaps that's just a naive developer's view of the world! I am not sure whether I will use the jarsigner approach, or put the security at a different level in the product. But thanks anyway.
Peter den Haan
Joined: Apr 20, 2000
A more lightweight approach would be to calculate a simple MD5 hash for each template (possibly as you read the template in), and compare the hash with the known good value stored in a properties file somewhere. If you "encrypt" the hashes by XORing them with a "secret key", no ordinary mortal will be able to mess with the templates. Of course this is not serious security because anyone determined enough to use a decompiler can simply figure out how the thing works, retrieve the value of the "secret key" and manipulate the templates with abandon. But it sounds like you might be more concerned about discouraging ordinary users than about thwarting determined hackers. - Peter [ June 27, 2003: Message edited by: Peter den Haan ]