Java Code for Pass Encryption/Decryption

Question

I want to save an encrypted password (the encryption may be produced manually or using java code, and the encryption technique type does not matter), then the java code will read the encrypted pass from the file and decrypt it.

Answer 1

Requesting that somebody write code for you is out of scope for this site. The Java crypto API is reasonably well documented and if you want help with a particular aspect of it, post a new question about that (here, or possibly on StackOverflow). However, we can give advice, depending on what you need. This answer will be a little generic since you haven't given a lot of information.

First of all, a general word of advice: if possible, passwords should not be stored either in plain text or under reversible encryption. There are obvious exceptions, such as password manager utilities, but those are written by, or at least in collaboration with, security experts. Since you're not one of those, the first question to ask yourself is: do you actually need to be able to store and decrypt the password?

Additionally, the general problem with any system like this is "where do you get the decryption key from"? A key that is hard-coded into the application, or that is stored in plain text on the file system, offers no real additional security over just storing the password (or any secret) in plain text; an attacker who can access the password file can also access the key file (or pull the key out of the binary), and use that key to decrypt the password just like your app could.

Here are some example scenarios (some of which overlap):

1. You're building an authentication system, where users or other programs need to prove their identity by sending you a password. For something like this, you should be using a strong password hashing algorithm, such as argon2 (as @Natanael mentioned in the comments), and should not be storing the password under reversible encryption.
2. You're building a client application, and don't want to make the user type in their password every time. The best option here is to store a long-lived session token (or refresh token that can be used to renew the session token), rather than storing the password itself. In other words, don't store the password, store the thing you get back from the server when you supply the password. This token is unique to your client (application) on that machine for that user on that service, so it's safer than storing the password (which is the same for that user on that service, on any client and any machine), but you will probably want to store it securely anyhow (see below).
3. You're building an unattended service that needs to be able to authenticate even if no user is available to type in a password at any point. If you're absolutely sure you need to do this, keep reading.
4. You're storing some secret value (possibly a password but hopefully a session token or similar instead) and need to retrieve it without user interaction. First, see if you can use a platform-specific secret storage system. Many platforms provide some way to do this, such as Keychain on MacOS or Credential Manager on Windows (though accessing these services from Java may be tricky unless somebody has already written a library for the native-code interface). There are also secret storage systems available on many cloud platforms, such as AWS's Key Management Service. If that isn't an option for some reason, you'll need the key to be injected into the program's environment when it starts up, for example as an environment variable or from some other service. Of course, that just bumps the "where do I store it?" question up a level, but maybe the environment you're running in has a provision for secret storage even if you can't access it directly from your code.
5. You're looking to decrypt a secret (possibly a password but probably not) using a key or password that you get from a user. If the user is supplying the key directly (for example, it's in a file on a flashdrive), just read the key into memory long enough to decrypt the secret, and store that in memory. If the user is supplying a password, run the password though a strong password hashing / key derivation function (get parameters, such as the salt, from a file; they aren't secret) to produce a key (store the key and the password itself only in memory, and only as long as needed) and use the key as mentioned above.

It's possible that you just cannot meaningfully secure the secret, because there's nowhere to store the key. In that case, you're out of luck, and need to redesign your system or accept the risk. You can try storing the key in a file combined with another key or XOR mask hardcoded in the binary, and then obfuscating the binary to slow down reverse engineering attempts, but that's not real security, any more than a speed bump is a wall. (Don't just use an obfuscated key in the binary, because they you can't change the key without updating the whole program.)