We Keep Coding

Set Variable On First Run in java

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.

How to "hide" sensitive system properties like passwords set by Java applications?

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.

Best way to store a password

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.

Protecting .jar with .htaccess?

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).

Security issues with applet

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).