I need to set the following variables before invoking remote queue.
System.setProperty("javax.net.ssl.trustStore","C:\\certs\\trustStore.jks");
System.setProperty("javax.net.ssl.keyStore","C:\\keystore\\keyStore.jks");
System.setProperty("javax.net.ssl.keyStorePassword","Demo1234");
System.setProperty("javax.net.ssl.trustStorePassword","Demo1234");
The passwords are exposed here. What is the best way to encrypt the passwords?
At some point, your private key/key store password must be visible to enable secure communications to take place. It needs to be stored securely within your web/app server. And your code base needs to be securely stored and only accessible to the people who need to see it. You could store it encrypted somewhere and decrypt it for use, but your encryption and decryption algorithm would still be visible and potentially emulated, so at some point, the means to access the clear text will be available and it's merely a matter of ensuring that it's only available to as few people as possible and kept from prying eyes as far as possible via your network security.
Encryption technique here, if you need it: How to encrypt String in Java
Related
What will be the most secure way in java to Pass username and password encrypted between 2 backend systems written in Java behind the vpn?
The goal will be that if the username and password encrypted being captured by someone, it could never be decrypted.
Theoritically speaking, asymmetric encryption tools are used for transporting confidential data. Every node/client will has a pair of keys that one of them is private and only known by itself, and the other one is public and should be known by everbody that wants to send confidential data to that particular node. The thing is, if a payload data is encrypted with the public key of the client X, it can only be decrypted with the private key of the client X.
Protocols like SSL, TLS, etc. are some widely used implementations of that concept.
assuming you can control both servers in an un-monitored manner(or at least not monitored by the intruder) and could implement any code on both servers then:
you can write your own made up protocol and its encryption algorithms on both systems and use it to share your data between your two systems.
this way the intruder would have no clue what the captured data even is or how to interpret them.
since you said 'Never be decrypted' your protocol could use an encryption key which is already defined on both servers and is not exchanged between them(over a handshake for example) and could use an encryption algorithm which doesn't store any encryption key validation in the transmitted data(like padding or hash etc) and of course shouldn't exchange the encryption algorithm.
it is worth noting that ssl/tls or any other protocol which expose their encryption algorithm and exchange encryption keys used are bad ideas to reach your goal since these protocols are prone to be deciphered if certain portions of their traffic are captured.
The SHA (Secure Hash Algorithm) is one of the popular cryptographic hash functions. A cryptographic hash can be used to make a signature for a text or a data file.
The SHA-256 algorithm generates an almost-unique, fixed-size 256-bit (32-byte) hash. This is a one-way function, so the result cannot be decrypted back to the original value.
Currently, SHA-2 hashing is widely used as it is being considered as the most secure hashing algorithm in the cryptographic arena.
A few library like Guava or Apache commons codec provide the functions.
In your case, I suggest you send the Username in clear text, but send the password use the SHA encrypted, since it cannot be decrypted, in another backend system, you have save the enrypted String somewhere safe like Database, when the password send over, you just need to see the encrypted string match.
This is nice tutorial article talk about SHA in java:
https://www.baeldung.com/sha-256-hashing-java
I am developing an android application through which i am sending a mail via GMAIL API.
To send mail via GMAIL API i have to give them my ID and password.
GMailSender m = new GMailSender("myemailhere#gmail.com",
"mypasswordhere");
and i know writing password like this is not at all safe as my password could easily be stolen by extracting my apk and alsostoring the password in strings.xml is also not secure as xml can also retrieved.
my question is-
Is there any other way to write password in my file so that it remain secure??
The short answer is not. You shouldn't store your password anywhere in the code or in any file.
Even if you encrypt it like someone said you will have to store it's decryption algorithm/key somewhere in the code, which will be easily reverse engineered.
No,It's not safe to store passwords on the device.
small advice is always store passwords in char[] in encrypted form rather than storing in a String whenever it is mandatory to store.
Since Strings are immutable in Java if you store password as plain text it will be available in memory until Garbage collector clears it and since Strings are used in String pool for re-usability there is pretty high chance that it will be remain in memory for long duration, which pose a security threat. Since any one who has access to memory dump can find the password in clear text and that's another reason you should always use an encrypted password than plain text. Since Strings are immutable there is no way contents of Strings can be changed because any change will produce new String. So Storing password in character array clearly mitigates security risk of stealing password.
Storing passwords is not considered safe, and shouldn't be done if at all avoidable. There are a few considerations, if you have to for some reason.
The best place to store such things is in private SharedPreferences. These are not readable by anything but the app, or rooted devices. Do not store on external storage!!!
Encryption can always be undone, but if you have to, then it would be better than nothing, requiring more work to undo. Use a key which is unique to each device.
Some sort of a token, such as is used by Oauth, could be a solution. This isn't perfectly secure either, but it could be.
Google provides more secure APIs for it's functions. You really should look in to that.
I've read about the Adobe CryptoSupport that is now in CQ5.5+, which is meant to provide a utility for encrypting and decrypting data, for example, to store API keys in the JCR more securely.
The JavaDocs or the general Adobe documentation give no details on its implementation, just stating that:
Note that this method and the decrypt(byte[]) method provide full
round trip support:
decrypt(encrypt(plainText)).equals(plainText) == true
Please note,
that calling this method twice on the same plainText does not return
the same cipher text:
encrypt(plainText).equals(encrypt(plainText)) == false
This is reasonably useful, but what it doesn't tell me is how these ciphers are enncrypted to begin with. I've tried encrypting on one CQ instance & decrypting on another, but this doesn't seem to work.
To use this feature with confidence, I'd like to know on what CQ bases its encrypted.
There are two main concerns I have:
How do I know that the service is salted (think that's the correct term) based on something secure? Or if it needs to be configured, how do I do that? (i.e. does it use the equivalent level of security OOTB as a log-in of 'admin/admin'!)
If the encryption is environment specific, does this mean that I cannot encrypt data & then transfer across between servers?
Bundle description in the Felix console states that
The Crypto Support bundle provides a CryptoSupport services which
allows applications to encrypt and decrypt binary and String data.
Encryption is based on the symmetric AES/CBC/PKCS5Padding (AES
algorithm, CBC mode with PKCS5 padding) from the RSA JSafe libary.
Key is randomly generated during the first start of the Adobe Granite Crypto Support bundle and then saved as /etc/key/master property. It is per-instance by design and I don't think it's a good idea to move this key between CQ installations. Actually, Adobe says it's a good idea to move key between author and publish instances.
Answering your questions:
you don't need to worry about configuring the service as it's done automatically during the first bundle activation,
you can move encrypted data from one instance to another as long as you also move the key.
I am currently making an app that will need to save sensitive data in J2ME, either in RMS or using LWUIT's storage class. (For example username and password)
How secure is such an implementation, and what are the steps to take in order to make sure the data is secure and not vulnerable to theft?
RMS is not encrypted - an attacker can easily read off any data. You'll need to encrypt the data - I recommend the Bouncycastle AES provider, but the Java AES provider also works (although it isn't as efficient, and you'll need to enable 256-bit keys on it). See the accepted answer to this question for some example code, I don't recommend changing anything in the code without asking StackOverflow or another good Q&A site first (it's very easy to incorrectly use encryption libraries); the code uses the Java crypto provider, to use the Bouncycastle provider use Cipher.getInstance("AES/CBC/PKCS7Padding", new BouncyCastleProvider()) after you import the Bouncycastle library. Important to note is that the code generates a Keyspec spec from a char[] password - the user will need to enter this password at least once per session in order for you to decrypt the data (you can't store the password on the device, that would defeat the purpose of encrypting the data). Also important is that you'll need to use the same IV (initialization vector) in the encryption and decryption phases; this IV should be unique to each record that you're encrypting (e.g. when you encrypt foo.txt then use a different IV than when you encrypt bar.txt), but it does not need to be secret (you can store it in plaintext alongside the encrypted file). As an added precaution, wipe the char[] password when you're done with it.
This question already has answers here:
Encrypt password in configuration files [closed]
(10 answers)
Closed 5 years ago.
I need to save a db password as an encrypted string and then decrypt before connecting.
Can anyone refer me a good two-way encryption library in Java?
Dan, take a look at this thread as there is some useful info on how to do that in a property file just via Java's APIs.
Encrypt Password in Configuration Files?
In real terms of security Base64 encoding will be almost as good as any "hard" encryption.
(Dispute in comments. :) )
Edit: OK, the recent downvote brought me back here to add some words.
The above statement is meant to remind people that it is impossible to have any automated activity authenticate in a secure way to some other party. If you'd use a password to encrypt and decrypt a stored password, where would you store this new password? Easy! Just make a third password to securely store the second password and so on.
Point is: Any password which is decryptable by some automatic procedure is in fact not encrypted but merely obfuscated. Thus, the encryption is futile in the first place.
Usually passwords are kept as hash, so the process of getting the real password is not possible, other than converting it back what we do is we convert the password user entered to a hash and then match them. If you can explain more about your usecase it'll be clear