I'm developing in Adonis.js 4 (node.js).
What I want to accomplish is to save inside my database an encrypted value. But I don't want to encrypt that value with an app key (same key for all values). I would like to have something external (this is why of AWS) where I can store an id and a key for each of my values.
Let's say I have a user table, where I have a password field. I want the password to be encrypted with a different key for each user, so that if someone has access to my db and one key they still could have access only to one user account.
Do you know some easy way I could achieve this?
From my researches I think I should use this for keeping secrets: https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/SecretsManager.html
But what about Adonis? How could I change encryption key dynamically?
I have a big amount of data in a mysql database. I want to poll data from database and push them in a activemq in camel. the connection between database and queue will be lost every 15 minutes. some of the messages are lost during connection interruption. I need to know which messages are lost to poll them again from database. the messages should not be send more that one time. and this should be done without any changes in database schema.(i can not add any Boolean status field to my database).
any suggestion is welcomed.
Essentially, you need to have some unique identifier in the data you pull from the source database. Maybe it is whatever has already been defined as the primary key. Or, maybe the table has some timestamp field. Or, maybe some combination of fields will be unique.
Once you identify that, when you are putting the data into the target, reject any key that is already in the target. You could use Camel's "idempotency" features, but if you are able to check for the key in the target database, you probably won't need anything else.
If you have to make the decision about what to send, but do not have access to your remote database from App #1, you'll need to keep a record on the other side of the firewall.
You would need to do this, even if the connection did not break every 15 minutes...because you could have failures for other reasons.
If you can have an Idempotency database for App#1, another approach could be to transfer data from the local database to some other local table, and read from this. Then you poll this other table, and delete whenever the send is successful.
Example:
It looks like you're using MySql. If both databases are on MySql, you could look into MySql data-replication, rather than using your own app, with Camel.
There is a task to encrypt a message with a key stored in HSM (LMK I suppose) to save the encrypted message in database. And decrypt later as well.
The commands I find are M0/M2. As I could see both commands require my own key in addition.
I may generate own keys somehow (with HSM or by another way), but how the message be encrypted finally? With the both my and LMK key? Some other way? And should I store my own key somewhere also?
Is it a more direct way to encrypt message with internal HSM key?
Thank in advance, I am very new with HSM Thales.
Commands M0 and M2 on a Thales 9000 Payshield are Encrypt Data Block and Decrypt Data Block respectively.
To use these commands, you have to provide a key in the M0 command which will be used to encrypt the data.
The key you use must itself be encrypted under an LMK keypair, which is stored in the HSM and should not be accessible to you (except in a test environment where you will normally know the values of all the test LMK keypairs).
To get that data encryption key, generate a ZEK, using command A0. The A1 response to this will give you the key. The key you receive is encrypted under an LMK keypair.
You can then use this key in an M0/M2 command to encrypt a given block of data.
You will need to store the key you receive in the A1 command (it's likely just 16 or 32 hex chars) as it is not stored in the HSM.
Encryption/decryption of any of this data will always have to be performed via the HSM, because only the HSM has access to the LMK keypair required to decrypt your key and make it usable.
I have certain information being stored in a MySQL database that warrants being stored in an encrypted form. However my .Net application can't absorb the perfomance hit of doing the encryption and decryption at the application layer.
Is there any MySQL function that allows an ecryption key to be specified in the connection string and then have the MySQL database do the encrption operations?
do you mean
AES_ENCRYPT
and
AES_DECRYPT
you can pass the key when you run the query
you can see an example
EDIT:
another option to use
DES_ENCRYPT() and DES_DECRYPT()
The key file can be specified with the --des-key-file server option
Say each row in a table has data pertaining to one particular user. The user has a password to access the system.
How do I encrypt a column of data using InnoDB so that no one other than the user who's data it is can read the data ? I was thinking of something like using one of the MySQL encryption functions (say AES) with a key based on a hash calculated from the user's password.
Does any one have any pointers to how I could do this ? Am I on the right track ?
One of the answers below
The issue of modifying user's password involves re-encrypting the user key by means of the new password which is much more straight forward than re-encrypting the whole bunch of user's data that can be arbitrarily large. The user key remains the same accross the life of the user data in the system.
How does this help ? Say the password is pass1. And there are a bunch of records encrypted with a key generated from this. If the user now resets the password to pass2, I have no way of decrypting the data that was encrypted using pass1. In the case of a user forgetting the password entirely, all his encrypted data will be lost.
I don't know if there is much sense in encrypting data with user's password hash, especially if you keep hash itself in the database. In that case anyone who can access the encrypted data can also access the password hash and decrypt the data.
Another approach would be to encrypt the data with the application-specific key salted with some user-specific data. However, then you face another problem: how to securely store the application key. To that question I do not know an easy answer, but keeping it in your source code is probably good enough if you fear that your database data can be compromised, but not the source code itself, e.g. if your database is stored off-site (think Amazon S3).
Salting the app key with the user's password helps if you keep only password's hash in the database, but can introduce another security flaw: you have to keep user's password in clear text in the applications session.
As for technical solution, it is quite simple and sample code is available. You could modify it as follows to encrypt the data with the application password salted with password hash:
INSERT INTO secure_table VALUES (
1,
AES_ENCRYPT(
'plain text data',
CONCAT(#application_password, #user_password))
);
In any case you would have to store your application password somewhere so I don't think that there is an easy approach that provides perfect security.
Another approach I can think of is to ask user for a short PIN which you could use as an encryption key. The PIN would not be stored in the database, but you would need to ask user for it every time you access their data.
And of course your have to think of is the feasibility of the encryption. You won't be able to index or to search it without decryption. It is probably required for a limited set of data (e.g. credit card number), but I wouldn't go to far with it.
To clarify one of the answers mentioned in the question: "user/app key" is a randomly generated private key, which is used to encrypt the data. The private key never changes (unless it's compromised). You encrypt and store the private key with a password. Since the private key is much smaller than the data, it's much cheaper to change the password: you simply decrypt the private key with the old password and re-encrypt it with the new password.
For data that is not user-specific (global), you could maybe use a combination of symmetric and asymmetric cipher. You could have an extra password field that all users are required to enter so that even if one user changes one's password, the global data will still be usable to other users with different passwords.
The extra password can be bitwise xor'ed with another salt-like string inside the source code. Together, it can form the symmetric passkey to decrypt a private key stored in the database (which will never change). After private key is decrypted using the extra password, the private key can decrypt and read all the data in the db. Private key can be stored as session variable.
The public key, as the name suggests, can reside as plain text string in the db. When you need to write to db, use public key to encrypt the data.
You can routinely provide the users with a new extra password and re-encrypt the static private key, followed by an xor'ing with salt-like string.
If the data is user-specific data and not meant for other users, you could use the user's password without the extra-password field to encrypt the private key. The administrator could have another copy of the private keys for specific users, which can be decrypted using his password.
I don't think that's the best approach, unless you're enforcing that users can never change their password, or you have a way to re-encrypt everything each time a user changes his/her password.
You could store another key to encrypt/decrypt user specific data which could be generated when a new user is created. Let's call this new key user key. This user key should also be encrypted in database and the most direct approach would be to encrypt it by means of the user's password or any other data which cointained the password (such as the password and creation/modification time, etc.).
I would keep in user's session the decrypted user key to access user's data at any desired time within session.
The issue of modifying user's password involves re-encrypting the user key by means of the new password which is much more straight forward than re-encrypting the whole bunch of user's data that can be arbitrarily large. The user key remains the same accross the life of the user data in the system.
Of course this method can only be used if authentication is carried out by sending the actual user password to the server at logon, since database only desirably contains the hash of the password.
Say the password is pass1. And there are a bunch of records encrypted with a key generated from this. If the user now resets the password to pass2, I have no way of decrypting the data that was encrypted using pass1
The key would need to be encrypted in a reversable manner, so that it could be decrypted
using pass1 and re-encrypted using pass2.
To summarize:
Stored in the database is: the one-way encrypted password (for password checking),
the encryption key for other data, reversibly encrypted using the clear password (or at any rate, the password encrypted in some different manner than the way it is stored in the database), and the other data, reversibly encrypted using the clear encryption key.
Whenever you need the other data, you must have the clear (or differently encrypted than as stored in the database) password, read the encryption key, decrypt it with the password, and use that to decrypt the other data.
When a password is changed, the encryption key is decrypted using the old password, encrypted using the new password, and stored.
If you need to access the data without user interaction (for database migration for example), you won't have the key to decrypt.