It seems that I have misplaced a password for a Keystore for an Android project. I still have the keystore, but not the password. However, the password is saved in Eclipse in the Signing and Keys tab. I also have the secure_storage file within the org.eclipse.equinox.security directory, and it seems that my stored password is there, encoded. It makes sense to me that were I to use the stored password-version of the Keystore, that password would need to be decoded at some point, to be passed to the Keystore. Therefore, I'm wondering what I'd need to do to decode that myself, and retrieve the password.
Any help would be appreciated!
Tim
After much research, I have found how to recover the password from the Secure Storage. As I surmised, Eclipse must have a way to extract the saved password, otherwise it could never be used to unlock the keystore. I found this post: Eclipse password recovery which led me into the method to view the saved passwords. The only bit that took some work was actually executing the code. I didn't go the eclipse-shell path, but instead created a eclipse plugin project using that code. Note that that code will not work in a standard Java project.
Of course, the actual Secure Storage is encrypted with the OS authentication, so this would only work for decrypting the password from the machine where it was originally encrypted. The problem was never about decrypting without the proper ciphers, but about using the built-in decrypting methods to get a clean-text password.
No, you can not. It uses the operatingsystems cryptation or/and the jvms. Standard is usually some AES-256 bits and is very hard to break.
I don't think you will get any help here.
Related
I want to use Aes to encrypt some data and decrypt them later. I created a jks keystore, the problem is where to read the keystore and keys password. Putting the master password in the code seems not really secure. Same thing if I put in the properties file or environment variable. I could use jasypt library to keep encrypted the master password in the properties but again I need another password and the problem again where to store it. What is the best way or guidelines in these cases? I can't use a command line input neither a command line parameter.
Another question: if I keep my keys into the Google memcache, is it secure?
Check Vault project.
I don't recommend you to use Google Memcache for such things. It's pretty similar to situation, when you store your master key in database or file. However, you decide, what level of security for data you need. Sometimes, properties file is enough.
I'm trying to secure a java app that I'm working on. This app has service wrapper that contains a list of parameters, among these a database password. So there are 3 solutions but I'm not sure that any one of them is possible.
1) encrypt the whole file without yet keep it usable.
2) store an encrypted password and add a encryption function to the file
3) create an external program that restores the encrypted password and call it's result in the wrapper.config file
After desperately searching the internet for a response I didn't find any helpful so I'm hoping to find someone who had a similar issue in here.
Another alternative would be to use a key store, as shown in this blog post, however you would still need to find a safe place to store the key to the key store itself. To go around this, you could make your application ask the user the password to the key store, this way the data will be secure but you do not store any (keystore) passwords. That being said, if you are willing to ask your user for a password each time the application switches on, one might as well simply ask the user for the DB password right away.
If you are encrypting the file, you would still need to ship the key with which the application will need to do the decryption. This would mean that potentially users would still be able to look into your application and decrypt the file as they please.
I think that if you really want a safe solution, the answer would be to simply not store the password yourself, but rather ask the users for the password each time.
Our security department wants us to use 256-bit encryption to encrypt SSN, Names of Users etc, so we decided to go with JASYPT with the sample code below:
encryptor = new StandardPBEStringEncryptor();
encryptor.setProvider(new BouncyCastleProvider());
encryptor.setAlgorithm("PBEWITHSHA256AND256BITAES-CBC-BC");
encryptor.setPassword(OUR_KEY)
encryptor.encrypt("TEXT TO ECNCRYPT")
The problem we noticed is when our application creates an encrypted record from our local machine, the application on the app-dev server cannot decrypt it and vice versa even though the key is same. It seems like JASYPT is adding some machine specific information in the salt (Mac address etc).
Even using FixedStringSaltGenerator or ZeroSaltGenerator does not help. This creates a problem for us because if we ever migrated our production server to another machine, or refreshed pre-prod data with the prod data, we may need a couple of million years to recover the information.
The security department wants us to use a well know library and not brew an in-house solution. Can someone please throw some light on this issue on how we can generate encrypted string that can be decrypted across different machines using jasypt 256 bit encryption, or when we refresh pre-prod database with prod data, how we would be able to recover names etc that were encrypted through a different server?
Any useful insights will be greatly appreciated.
your key might be containing some special characters which shell substitute with something else.
do a echo "yourkey" > file
and check the content of this file.
then use this content as a key to decrypt; it should be able to decrypt the encrypted string.
I know this is a pretty old question but I recently experienced this issue and the resolution for me had nothing to do with the differences in machine operating system endianness.
It had to do with a character in the password itself, the dollar sign character ($), that was somehow considered to be a special character in Linux vs not being considered special in Windows. So everything worked fine encrypting the values in Windows, but when I swapped over to Linux and tried to decrypt the values with the same password using the jasypt command line decrypt.sh script, I got the error message "Operation not possible (Bad input or parameters)" and noticed that the password in the jasypt decrypt output arguments list was different than the one I had typed in (the script apparently chopped off the part of the password from the special character until the end of the password string).
Anyway, my solution was to change the password to not use a special character and then it worked. Hope this helps some poor soul who happens to run across this same issue in future, because I wasted 2 days on it.
use single quotes instead of double quotes to wrap your input string. This solution worked when i had a issue with encryption and decryption of string with $.
How exactly SQLCipher for Android Application works?
http://sqlcipher.net/design/
As i understood it all depends on PRAGMA key and this key should be saved on app, maybe in binary.
However this is insecure as alomst everyone could decompile .apk file on rooted phone.
Maybe i missed something ?
Thank you.
As i understood it all depends on PRAGMA key and this key should be saved on app, maybe in binary.
No.
Maybe i missed something ?
The key comes from the user, in the form of a passphrase that the user types in. In SQLCipher for Android, this passphrase is passed to methods like getReadableDatabase() on the revised version of SQLiteOpenHelper.
Yes, securing the key is the tricky part. Ideally it's (partly) supplied by a password the user enters when signing on to the app, but that isn't always ideal, so sometimes you have to resort to the much-maligned "security by obscurity" approach and assemble the key from bits and pieces stashed here and there.
The SQLCipher team universally recommends against embedding a fixed key in an application binary. No matter how creative an application is about obscuring an embedded key, a sufficiently determined attacker will be able to extract it from the application package and open a database.
Unfortunately some applications still choose to use SQLCipher with embedded keys as a rudimentary form of DRM, i.e. by making it difficult for casual users to view data. However, this does not provide any substantial amount of security.
If you need to protect sensitive data the best approach is to use a key derived from a strong passphrase entered by the user. SQLCipher provides strong key derivation automatically, so all you need to do is provide the user passphrase through PRAGMA key or one of the equivalent keying mechanisms provided in SQLCipher wrapper libraries.
I generate key form secureRandom and then save key on KeyStore (BKS).
For KeyStore i generate password using: random, user info, device info and password.
Till now, i have been creating a file (txt/excel) using buffered Writer for creating a text file and JExcel API for creating a Excel file. These files i have been creating using Java only.
Now i want to make the file password protected in both the cases, that to something like, the file can be accessed by number of people, but only selected may access it using there own login ids/password.
Is it possible to do so?..
Thanks
The answer completely depends on what way you want to open your protected files.
If it is opened by your (java) program or an application, then you can simply simply encrypt it with a password upon saving, and decrypt it with something the user provides,
and use some checksum or header to see if the result is valid - or some garbage due to bad password,
some crypto APIs will do it for you right out of the box.
Second option - if you meant encrypting files with a program (like a notepad file, or something), and you expect windows or notepad to ask you for the password, then it depends on the format of the file you use. Some can be password protected, some can not -like text files usually associated with notepad). In this case password protection works as described in the format's own documentation, and you have to research a bit, I guess it will be too much work
we can do password protection of zip files with the core Java API.
Yes, it is possible to do that, you would have to write your own encryption and decryption tool or write a plugin for excel to do the decryption.
Usually the best approach is to use the security of the OS and specify which users can read or read/write the document. This is transparent to the user and doesn't require a encryption/decryption tool.
yes it is possible. You can use either AES or DES encryption. password is nothing but the key using which the file can be be encrypted or decrypted. you can create your own listener which will prompt you for password. If you enter the password then it will take the password and try to decrypt the file