I am developing a java swing project that require login and password that need to be entered when run first time i.e. setLoginFrame.java.
for all the subsequent run it should run the Login.java
can't find a way other than file handling to store login and password..
I have no idea like how to do this..
If it's not very risky data, then you can just use files for storage, then encrypt them separately if you wish.
Else, you can generate hashes of your strings with MessageDigest in the java.security package. Just call getInstance() as per the example. SH1 is generally seen as stronger encryption.
You really should learn about security of data and how to store passwords.
If you want to store data, there is always a database option.
But if you are staying with storing in files, there is a lot of info in the web about how to do so. For example here.
Related
Context: I have two apps, both signed with the same signature. The first app has data stored in internal storage that I would like to migrate to the second app.
Question: How can I access the data in the first app from the second app? The Android documentation makes reference to "signature permissions" (https://developer.android.com/guide/topics/permissions/overview#signature and https://developer.android.com/training/articles/security-tips#StoringData) and hints that it is possible to share data between apps with the same signature, but I cannot find clear guidelines about how to do this.
It seems like it might be possible by creating a content provider? Or is it possible to directly access the files, since I understand from the docs that they will be running with the same user / same process?
Ideally this process can happen with minimal intervention from the user, and can all happen from the second app (e.g. the second app can recognize that the first app is installed, prompt the user to migrate, and then read the data from the first app and move it to the second). It would be even better if it was possible to move the files (rather than copy) because we potentially have a lot of data and the user may not have enough disk space to copy the data.
It seems like it might be possible by creating a content provider?
Yes. You can create a signature-level permission and use that to protect access to any of the standard IPC options in Android, including ContentProvider and Service.
Or is it possible to directly access the files, since I understand from the docs that they will be running with the same user / same process?
No, two apps signed by the same signing key to not run as the same user, let alone in the same process. android:sharedUserId has the apps run as the same user. This was never a great idea, is deprecated, and is likely to go away soon.
It would be even better if it was possible to move the files (rather than copy) because we potentially have a lot of data and the user may not have enough disk space to copy the data.
That suggests that having two apps is a bug, not a feature, from the standpoint of the user. The closest you will be able to do to a "move" operation is "delete-after-copy", so plan your copies to be as granular as possible so you can delete as you go.
I am maintaining an existing Java product (which has a HUGE code-base). I discovered that it is setting (and getting) two of its internal passwords as Java system properties, at no less than 4-5 different places (methods). Now, the problem is, the passwords are being stored as plain text in the Java system properties, and so, the same is visible to external entities, as the application is not using any Java Security Manager. For example, if the application (process) is running on port number 1234, we can run the Java command:
jinfo -sysprops 1234
to view both the passwords as values of the corresponding Java system properties. I wish to ask if there is any remedy to this without changing the existing code-base too much? The desired effect would be to "hide" the two Java system properties (denoting the two passwords) from all external entities.
It may be noted that introducing a Java Security Manager into the application may not be a solution, as if we revoke read permissions from the said two Java system properties using the Java Security Manager, the application codes which read those properties would crash. Same is applicable for storing the passwords in encrypted form, as that would crash all codes within the application which are expecting to read the passwords in clear text form.
Since you said:
...at no less than 4-5 different places...
and you really don't want to do major code changes, I would:
Supply the password in an encrypted form.
Go through those 4-5 places (it's not so much!), and call a wrapper method that you have to write separately: MyPassUtil.getXYZPassword() which internally calls the System.getProperty() to get the encrypted password, decrypt it, and return the plain text version to whoever is calling it.
Keep in mind though, that this way, the decryption key and algorithm is stored within the application, and a good Java decompiler (JD-GUI or CFR) will still return this information. In other words, anyone with the access to the JAR file, can still get the information with some minor effort, something which I presume, since one can call jinfo, they can also get the JAR file.
The best is to use some form of keystore, which again, you can easily implement once you do the wrapper method mentioned in step 2, without affecting whoever is using it.
Also, some security tips:
If it's an SSH / SFTP connection, set up SSH keys between the two machines, and eliminate use of passwords.
If it's a database connection, at least configure the DBMS to allow connections only from this particular machine's IP address. If the connection is over the internet and you are behind an NAT, set-up a VPN first, and channel the traffic between the hosts through it.
For other setups, try and see whether there are some other tips you can do similar to these two points, to improve the security around these passwords.
I have a java program that scraps web pages and store data on a db.
This program has no user interface, it's run vy the linux boot sequence.
what is the best way to store the db and sites password for a program like this?
I alreasy tried pass them via configuration file or command line, but i'm not very satisfied.
Thanks
You can use some secure keystore or wallet, but the bottom line is, as long as an attacker gains access to it, they can simply alter the script to print out the credentials.
Since your system consists of at least 2 components (script, db), you have to think of security on the level of the whole system. E.g. it doesn't matter if you put the cleartext passwords in the script if your system is not accessible externally by any means. On the other hand, you can have the best encryption and anti-tracing techniques, and yet, by simply setting up a proxy between your software and the DB software, one can scoop the password.
There is no simple answer for this. Sysadmins generally put the password in the script and make it 700.
Here is an excellent article that might help: Codinghorror
Generally I would say: Put restrictive chmod rules & salt, salt, salt !
Unless you deal with very sensitive data such as Banking. I would say don't worry about it.
Do your best to secure the server itself.If you don't want to expose the password in config file. Then create a class for your java program that will hold them.Then compile the code.
No matter what you do, you will still have to type in the password somewhere.
I want to prevent decompiling for my game client.
Is there a option I can some how protect the .jar file with .htaccess or any other method so the client (Browsing user, that loads the client via a applet) won't be able to get the file & decompile it.
I always wondered if there is a solution for this, is there? Maybe creating a crypt code, and whenever the server tries to get the client jar, it will send a crypt code via GET, if the crypt code matches, it will load the client from that page, I don't know, there should be a solution ?
Thanks!
For a browser to execute an applet, it needs to download the jar file containing the applet code. An if it downloads it, it's available for decompilation. To protect you against that, you can obfuscate the byte-code, or not use an applet at all, and simply use a traditional web application, where the code is at server-side, and the client only see HTML and JavaScript code.
No. You could stop the browser getting the file, but then it would be unable to run it.
Maybe creating a crypt code, and whenever the server tries to get the client jar, it will send a crypt code via GET, if the crypt code matches, it will load the client from that page,
The user could see the code and still get the file.
There is nothing you can do to prevent the user getting hold of the unencrypted bytecodes.
NOTHING.
The user's machine needs the applet's bytecodes in unencrypted form in order to execute them. Since a user (with sufficient knowledge) has totally control over what his machine does, you can assume that control will extend to allowing him / her to intercept the bytecodes at some point where they have been decrypted.
And if the user can intercept the applet's bytecodes, then he / she can change them to defeat any clever stuff you put into the code. And that includes changing the bytecodes to defeat any measure that you use to detect changes to the bytecodes.
"just make it so they have to use it in the browser then check if they are accessing it from our url" Could that work?
Nope. The user can modify the applet to remove that check.
"you could also make php create a session variable with a hash in and check if that hah is present and matches our hashing algorithm"
Nope. The user can modify the applet to remove that check too.
I don't know, there should be a solution ?
Unfortunately, there is no practical solution ... apart from running everything that needs protecting on the server side.
By the way, this problem is not unique to Java. Someone with the technical knowledge and the motivation can defeat any tamper protection measures in Javascript too, or even in native code plugins that you get the user to install (if he is foolish enough).
Currently i include
jvmArg=-Djavax.net.ssl.keyStore=/cfg/secret
jvmArg=-Djavax.net.ssl.keyStorePassword=123456 a.b.c.Proxy
What would be the alternative notation where password is not stored in clear text?
You would have to build an X509KeyManager manually and initialise it by loading a KeyStore programmatically. When loading the keystore, you call its load(...) method which will take a password (you could use a callback if necessary).
If you want your application to run unattended, you password will be obfuscated at best, not strongly encrypted (since your application will need to be able to decrypt it when required without a further password). It can be worth the effort, but not always (since an attacker may just be able to get that obfuscated version and de-obfuscate it easily).
(One of the problems with JVM args is that they may be visible in the process argument list, depending on your environment. Setting the system properties within your application when it starts might help in some cases.)