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.
Related
I am trying to develop an android app in java which needs encryption. Also I want to use AES-256 for encryption. But when I look a tutorial of it, It always generates a random key. My question is: How can I decrypt a string if I encrypt it with a random key? Also I tried almost every code in web, but none of them worked, so can you provide a AES-256 encryption code with no salt and IV. If I know something wrong, please correct me and teach me the truth.
Details: I am trying to make a password manager app. App has two passwords, first one is the master password that we use for encryption string data. Second one is the passwords that we want to manage. Master password is stored in users mind. And other password will be stored in the app with encrypted version. When user wants to see his passwords he will input his master key to decrypt the encrypted passwords. So how can I do it? And user's master password will be 32 or 64 digit and I don't think we need to generate a random key. Can you show me some way? I am not native english speaker, sorry for my bad english. Thanks for help.
My question is: How can I decrypt a string if I encrypt it with a random key?
You can't. You need to save the key (somewhere). Then when you want to decrypt the file you restore the key that you used to encrypt the file and use it to decrypt.
Here is an Answer that explains how to save an AES key to a file and restore it: https://stackoverflow.com/a/7176483/139985. Notice that the example encodes the key in hexadecimal before writing it to disk.
However. Anything that entails storing an encryption key (in the clear) in a file in the file system is vulnerable. If someone or something can compromise the security of the OS / file system where the key is held, they can read the file containing the key ... and ... decrypt what ever the key has been used to protect.
A better idea is to use some kind of secure key store / vault.
My advice: if you are write an app that manages passwords for other people, you really, really need to have a deep understanding of how to do this securely. And if you don't, pay a qualified IT security professional to design and implement that aspect of your system for you.
Just reading some tutorial and asking on StackOverflow does not cut it!
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.
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.
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.
I am working on a Java RCP application. A user needs to authenticate himself with his SmartCard to get access to the application. Inside this, he can open/save files which need to be stored encrypted.
Currently, I'm using a password-based AES encryption with a hard-coded password.
This is obviously not secure, so I need a different approach to encrypt/decrypt files.
What arouses this problem is that there are a few requirements to be met:
no guaranteed network connection (must be usable in offline-mode)
multiple users must have access to the files (so no public/private key encryption)
there should not be one "master"-key used for all files
Edit:
I doesn't need to have a very high level of security. It should just be a little bit harder for an attacker to get the key as to just open the distributed JAR file and get the key in plain text.
Any hints would be appreciated.
For each file, create a new key. Encrypt the file with that key (using AES).
Then, for each user that is allowed to read the file, encrypt the new key with their public key (one that corresponds to a private key on their smart card). Store these encrypted keys with the file.
When a user wants to read a file, the software uses his smart card to recover the content encryption key used for the file.
The file format could use PKCS #7's Cryptographic Message Syntax or OpenPGP.
Caveat: I am not well-versed in security and this is just something that crossed my mind.
As a suggestion, make the password for each file be a hash containing a known salt that is randomly generated for each file, and a single passphrase that is encrypted individually for each user. You can safely store the random salts locally, because these are not the key to the file, and no user knows the passphrase to unlock the file. By encrypting and signing the passphrase with public key encryption, you can authenticate users and control access on a per-user, per-file basis.
This way, you could use public key encryption from each user to deliver the passphrase, which is not stored anywhere in the system, secure the files independently of each other of each other, and not be dependent on outside sources.