Three years ago I made my first Android application and signed it with my keystore and uploaded on playstore.
Well that time I shared my keystore with my college friends
Now I made a update for my application and I want to make it secure so no one other than me can place a update or cannot do anything wrong with my work. Well that app is published using my college account so anyone can access that account. They can't delete (college rules) but still they can experiment on my application.
Is changing the keystore password will help? Anything I can do in this situation? I have my original key with me. If there is no way to make it secure then definitely I don't want to waste my time on updating.
You cannot change your keystore. Each app is linked to one.
Related
I would really like to know if it is even possible to run a self-signed java applet in Java 8. I have tried everything possible except buying a certificate and I my self-signed applet gets blocked every time. I can only just make it accessible if I add an exception in Java Security Settings but Ive never had to do that for anything else and what user is actually going to go to that much trouble. Im using applets because I want to embed a DosBox on my site... But Im beginning to think that Java 8 just can't do self-signed applets, period.
Can anyone else manage to get their self signed applet through security? I'm about to lose my mind with this to be honest.
Self-signed certificates are not trusted, by definition. You have two choices:
Buy a code signing certificate.
Have the user adjust his Java Security Settings, or trust the publisher via the popup dialog.
This is how the system is designed and intended to work. It's been that way for 20 years.
With the Java 8 security update, uploading a java application onto a webpage has been a nightmare. Self-signing is no longer a valid option (as it appears to me). I have recently bought a GeoTrust RapidSSL certificate in hopes that the website will be secured enough for Java not to block the application, but hasn't been like that (its been so confusing all-round).
My webhost setup the ssl so its there, website uses https. But the second area needs to be configured (I'm thinking by me), it wants me to choose the 'Web Server Type' which I believe its CPanel & WHM and underneath 'CSR' (image: http://postimg.org/image/jdnjjt6gr/).
Now I use Eclipse, and I installed this Keytool plugin (link: http://marketplace.eclipse.org/content/keytool) which allows me to create a keystore & csr (I really have no idea what a keystore, keytool, csr and jks are; I tried to study them on docs and available websites but its just all confusing). When i tried to create a simple one it gave me a bunch of numbers which Im presuming is encrypted with a Begin and a End on its borders (top and bottom).
I'm really confused on what I need to do, I just want to get my application running - I'm just really annoyed by this security block. What can I do? or What am I supposed to do? & Could anyone briefly explain what keystore, keytool, csr and jks are briefly?
Thanks in advance. If you could simplify things and/or give examples, that would be extremely helpful.
In the previous months I developed a sandbox Java applet for an academic project. I wasn't able to sign it with a trusted Certificate Authority because of the restricted budget.
With the release of Java 1.7.51 I found that the new security restrictions forbid the execution of the applet, because of the lack of signature.
Until now, I have found two rough solutions to this problem:
ask the user to include the applet page on his/her exception lists;
ask the user to set the Java security level to "Medium" (which, of course, is a risky manoeuvre).
Is there a way to overcome the restrictions imposed by Java with a self-signed applet without asking the user to change the security settings?
I would deeply thank you for your answers, since the option to buy a trusted certificate remains an expensive one.
Is there a way to overcome the restrictions imposed by Java with a self-signed applet without asking the user to change the security settings?
Short answer, no. Long answer, nope.
Its not a real solution but maybe a bit more convenient for the enduser:
Write a small programm (as jar file, or batch) which adds your site to the exception list. This tiny programm you offer to the user which can't execute your applet. It only has to be executed once. How this can be done is described here.
The file controlling the Exception Site List is stored in the user’s
deployment location as described in the deployment configuration. On
Windows 7 the location is
C:\Users\username\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites.
The format is one site per line.
If you think that is not really trustworthy to the user you are probably right ;-) who executes a file downloaded from the internet? You can also just add a small description to your page and a user could execute it from commandline. For windows it would like that:
mkdir %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\security
echo http://www.carlos.com >> %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites
The more I read my post I think the best solution is the certificate but still wanted to share this option.
I have a little problem. I program in two different computers and when I change from one to the other and I try to run an aplication the adb return an error because the instaled apk and the new one have different signatures and I have to manually uninstall it.
Is there some way of avoiding that?
Thanks
I believe you can just copy the debug.keystore file from one machine to another (I'm sure I've done this, but I'm currently developing on 1 machine).
Another variation on Phil's answer is that there is an option within the Android settings in Eclipse to use an alternative debug key, so you needn't actually overwrite with the copy.
I share such things between my desktop and my laptop with Dropbox and point the alternate debug key setting to one in there.
Edit: See Phil's comment about copying over debug.keystore. That seems like a preferable solution.
When you build an Android app it's signed with a debug key specific to that machine. In order to build from two machines without having to delete the app each time you switch you'd need to sign the apk every time you build with the same key.
Personally, I just delete the app whenever I switch environments but I could see that being a pain if you switch back and forth a lot.
You can use the same debug certificate across multiple machines, you just need to copy it from one to the others. I do this on my 4 development machines and it saves a lot of frustration, especially when you don't want to delete your app's datastores.
In windows, the keystore is located in C:\Users\[username]\.android by default. I'm sure there are analogs for other operating systems.
Dropbox is really helpful for syncing keystores.
You can alternatively use a custom keystore, as long as it has the same keystore and alias names and passwords. More documentation here.
I have developed an applet. But when my browser fetches it from the webserver it pops a security warring. I don't want this message to come. Meaning applet should run without the end users permession. How can I do that? Do I need to get my applet signed? If yes, from where can i get it signed? What's the cost of geting it signed?
Your description might relate to a number of problems, such as the code trying to do things which require trust. That does not sound like the case in this instance. If your unsigned code tried to do things that required trust, it would not prompt the user at start-up, but either prompt them when the trusted action is attempted (e.g. for cross site access in later JREs) or just fail with an AccessControlException or similar.
It could be that your applet uses multiple Jars and has run into the mixed code restrictions introduced in Java 1.6.0_20. But the symptoms do not sound quite right for that either.
Is your applet publicly available? What is the URL where I/we can visit it?
As an aside, if your applet tries to break out of the security sand-box, it must be trusted. That means the code must be digitally signed, and OK'd by the end user at the prompt. There is no way around it.
But it does not require a code signing certificate issued from a CA. You can roll your own code signing certificate using the tools of the SDK. I have a few small demos. of code projects that compile and build code before signing it.
You need to get yourself a code-signing certificate. Probably by some "well-known" CA if you want to avoid all warnings. The certificate itself costs money, but once you have it, you can use it to sign as many applets as you want (you do the signing yourself).