In order to provide key store information we have store-password in plain text file. To secure the key store either we need to encrypt the store password or move them in db. Is there any way to access this key store information from Database during run time. I tried below ref for encrypting password in crypto.properties but that is not helping.
Encrypting passwords in Crypto property files
There is no support there by default, you would have to write your own implementation of PasswordEncryptor instead to communicate with the DB:
https://svn.apache.org/repos/asf/webservices/wss4j/trunk/ws-security-common/src/main/java/org/apache/wss4j/common/crypto/PasswordEncryptor.java
Related
I need to store in my Database some datas that should only be read by the owner (specific user) or by my application (some background batchs).
But, those datas are highly sensitive, and I, the developper, don't even want to be able to retrieve it.
So :
I can't just encrypt datas with a secret key kept in the server, because I would personally have access to it, so if I wanted, I could retrieve the entire datas.
I can't encrypt with user password because my app need to have access to it without the user puting his password each time.
What can I do to solve this?
If you want to let the user encrypt something in such a way that only he can decrypt it, then you need a key to do this.
You could use the users password to do this, or you could use something else (a separate encryption key).
Now as for the password, you should not have access to that anyway; if you need the app to have access, then you should provide it with an access token of some sort, which will let the user get the access he needs without keeping the password in clear text. Entering the password should then only be necessary when the token is no longer valid (either due to timeout, manual cancellation / logout, or due to some kind of irregular event that might trigger a cancellation for security reasons).
Under a regime like this, where you don't need the password, your reason for not using the password as the encryption key falls away.
Note that no matter what you use as a key here, there will always be a question of trust here so long as you are doing the encryption on the server side; if you need your user to provide a key to encrypt / decrypt on your server, then what guarantees do they have that you will not simply steal that key and read their data anyway - or easier yet, simply not really encrypt it at all?
I realize that this solution is an improvement compared to using a single server-side secret key, since you will now have separate keys for each user, and keys that are not stored on the server (great in case someone is able to get unauthorized access to your DB), but an even better solution if possible, would be to let your users encrypt data on the client side. That way your server side logic would only ever see the encrypted data, and never even have to deal with either encryption logic or keys or any of that.
I am developing an application (web\mobile). The user have to register the account using a form on the application (it contains some data as username and password).
These data have to be stored in a database table, these data travel on Internet so I think that it is not a good idea that the password is in clear.
I think that the client have to encrypt the password in some ways and that this crypted password have to be stored in the DB.
What could be a decent workflow for this task?
A common way to do this is to send the password as clear text via a HTTPS connection. HTTPS is a must when anything confidential is sent through internet, not only for passwords.
On the server, calculate a hash. There are many algorithms for this, some more secure than others. A hash function works only for one direction: the password cannot be derived from the hash. Store that hash to the database instead of the password. When a User logs in, calculate a hash from that password, and compare it to the hash stored to the database.
I am developing a desktop application. Multiple users shall be using it to insert, delete and select data from database. As users shall be using it so they would not have to login to database.
I know how to use JDBC (for Java Applications), I need suggestions that I don't want to hard code the credentials of database like host address, username, password ... etc. So if change of credential is needed I can change it without changing the code. Also, I cannot just put database credentials in a text file and read every time when the application need to interact with database.
You can create a ApplicationConstants file which will store the host address, username and password.
If you need to change it you'll have to change it only in one location.
But this will require you to compile the code everytime you make changes.
The alternative is to encrypt the values and store the encrypted values in a text file.
You can use the javax.crypto for encryption/decryption. You can find an example on the following link :
Simple java AES encrypt/decrypt example
I'm creating a mobile REST API.
Currently, when user signs in with email and password, I generate secret session key (64 chars long), store it in database and send it to the user so that user doesn't need to log in again for the future request until they logged out.
For the next requests, I just check if the provided session key is equal to the one in database.
But, there is a big security loophole I see in this scheme. If the attacker got access to the database, they can use the secret key and impersonate anyone without knowing the password at all. What's the point of encrypting the password in this case besides obscuring user's real password - it doesn't prevent anything else.
So, my question is how do you store these access key correctly?
Twitter will send session key on sign in on their API. So, how do they store these keys?
Thanks.
It's even better to hash the session key, just as if it was a password, and store the hashed value in the database.
The only difference from password hashing is that, since your session keys are (I hope, at least) generated by a secure random number generator and long enough to be unguessable by brute force (I'd recommend at least 128 bits of randomness), you:
don't need a separate salt, and
can use a simple cryptographic hash function like SHA-256 instead of a deliberately slow password hashing scheme like PBKDF2.
Not using a salt also allows you to use the (hashed) session key to look up session records in the database, so you don't need a separate session ID for that.
So, to sum it up:
When starting a new session, generate the session key using a secure RNG, store the SHA-256 hash of the session key in your database, and send the (unhashed) session key to the client.
When the client makes a request, hash the session key sent by the client using SHA-256, and look up the corresponding record in the database.
You may also wish to limit the lifetime of session keys, and to provide some mechanism for the client to explicitly invalidate all of the user's sessions, to mitigate the effects of a compromise of individual session keys.
I've read that using a database to store session variables is much safer than putting them in cookies.
If you use the CI session library and set it to store in a database instead of cookies, does it automatically encrypt the session ID variables?
Everyone is saying that it is best to use encryption when storing session variables in the database, but I'm not sure if there is another option you have to turn on, in order for the encryption to happen.
Also, where would you set the key, if you do need to activate the encryption step yourself? Is it part of the same encryption helper class?
No, CodeIgniter does not automatically encrypt session data when storing it whether it's in a DB such as MySQL or on the client side using cookies.
Setting $config['sess_encrypt_cookie'] = TRUE in system/application/config/config.php will activate encryption of cookies. If using $config['sess_use_database'] = TRUE, then the cookie itself (stored client-side) will be encrypted, but the actual session variables(stored on the DB) will not.
My guess is that this is because it's not as important to encrypt data stored in a server side DB as when storing using a cookie for the actual session variables, since the user cannot see or modify the session variables in the DB anyway.
The encryption key needs to be set using $config['encryption_key'] for encryption to work.