Db2 allows to set a password in the connection using
SET ENCRYPTION PASSWORD 'mysecretpw'
This avoids having to set the password on each ENCRYPT() / DECRYPT() usage.
However, how can I remove the password after I finished my work so that other parts of code that work with the same connection are not able to use my password ?
I didn't find a 'REMOVE/DROP ENCRYPTION PASSWORD'.
Setting the password to an empty string SET ENCRYPTION PASSWORD ''caused problems when my code was invoked multiple times in the same process: the second invocation got 'NO PASSWORD SET' SQL20143N / SQLSTATE 51039 even though it did set the correct password again using "SET ENCRYPTION PASSWORD 'mysecretpw'" again before using ENCRYPT/DECRYPT ... Db2 also says that you have to specify a password between 6 and 127 bytes ...
Setting an arbitrary string as new password (e.g. blanks) is also not ideal, as this does not allow Db2 to detect 'no password set' conditions so that you don't realize that you are encrypting / decrypting with a wrong password ...
So how to clear the password correctly ?
The Db2 LUW documentation (at version 11.1) for SET ENCRYPTION PASSWORD does not state it explicitly but the product allows you to set the password to an empty string with the result that subsequent encrypt/decrypt actions in that connection will return -20143 sqlcode. When I test this behaviour with the CLP it behaves as expected on Db2 LUW.
So while both Db2 for Z/OS and Db2 for i-series for SET ENCRYPTION PASSWORD explicitly mention the empty string behaviour for the password (and the Db2 LUW knowledge center does not), it appears all three code bases have the same behaviour as regards the consequence of setting the password to the empty string.
If you have a testcase that proves you get an -20143 sqlcode even after using SET ENCRYPTION PASSWORD to a valid good password, then perhaps you should publish that testcase or open a PMR with IBM. If your code is multi threaded , you may get unexpected results as the password is in special register and changing it is not under transaction control, so there may be timing issues.
Removing the password seems to be possible either via disconnecting the session or setting it to an empty string in a single-connection scenario, and with the CLP the product appears to behave as expected for me when I set the password to an empty string, and subsequently set it to a valid password for the same connection.
Related
I am using a group context to configure the db connection. The password of the db has a password type. When deploying the job, the password is automatically encrypted in the default.properties under the contexts folder.
What if i want to change the password without using the studio (on a client environment)? what can i use to encrypt the new password?
I was able to do it by creating a separate encryption job with a tjava component and the following code:
System.out.println(routines.system.PasswordEncryptUtil.encryptPassword(context.Password));
where context.Password is an input context variable of type String. When running the job, the user is prompted to enter a password and then the encrypted Talend password will be printed. It will have the following format: enc:routine.encryption.key.v1:[encryptedPassword] The routine encryption key can be modified if needed by following this link: https://help.talend.com/r/en-US/8.0/installation-guide-data-integration-windows/rotating-encryption-keys-in-talend-studio
There's actually a few ways for this:
myJob.sh --context_param myPassword=pass123
this unfortunately can be seen by anyone via ps / task manager.
You can also edit the contexts/contextName.properties file and change the context parameters there. This way the context can only be seen if you have access to the file.
Theoretically both should be able to accept the cleartext/encrypted password.
Implicit context load feature can also be used to load contexts: https://help.talend.com/r/en-US/8.0/data-integration-job-examples/creating-job-and-defining-context-variables
I am learning about hashing and encryption and can’t seem to understand this:
Client: New user logs in => Creates password => Sent to a server in plain text
Server: Server generates a random "salt" => plain text and salt are unified => Hash function (e.g. SHA-3) hashes the password+salt into a hash => Hash is stored in DB.
Client: Same user logs out and logs in => Password sent to a server in plain text.
Server: Password needs to re-add the same salt it generated when creating the account to get the same hash.
How does the server generate that same random and unique salt?
Is the salt stored on a different DB altogether?
If a DB is compromised the hackers would also gain access to the salt and just brute force rainbow tables with the salt and unhash them.
The salt that was randomly generated must be stored in the database and linked to the user that logged in. It could be simply added as another column in the user table.
In a typical setting, the salt and the password (or its version after
key stretching) are concatenated and processed with a cryptographic
hash function, and the output hash value (but not the original
password) is stored with the salt in a database
Source: https://en.wikipedia.org/wiki/Salt_(cryptography) retrieved 19/02/21
The generation of the salt depends on which technology you are using. The following stack overflow answer has an example for PHP:
Can we use uniqid() to generate a unique Salt in PHP
The password should also never be sent in plain text to the server. This can be done via HTTPS for example
When the user logs in again. The password is sent to server side along with email.
The email is used to fetch the user record and then the Hash value saved against that email is compared with the new hash (salt + password entered).
The validate function method matches the 2 different hash values and checks if password entered was same or not.
For example, I am using bcrypt in Node JS and it has a method compareSync which matches the entered password with the saved hash
bcrypt.compareSync(password, databaseHash);
FMDB version (2.6.2)
Problem:
I am testing FMDB and SQLCipher, and find a tricky problem.
I encrypt a db with password 'test001' successfully, and I export it and open the db with DB Brower, with 'test001' I open it without any problem. Then in Xcode I try to open the DB with password 'test002'(I do this to test if FMDB will tell me that I use a wrong password), however the setkey() return YES. I check db.lastErrorMessage, it returns nil, which means FMDB thinks I give the right key.Then I try to read data from the DB using executeQuery(), the function returns NO, and the NSLog shows 'file is encrypted or is not a database'.
Anyone has the same problem? Is it a bug of sqlite or I use it in a wrong way?
setkey() return YES
executeQuery() return NO due to decrypt error
The call to setKey(…)does not verify the password provided is valid for current database, rather it just causes the database to attach a codec context within SQLCipher. The next SQL command that you issue following the keying of the database will cause key derivation to occur (so long as you are not using a raw hex key), and will generally validate whether SQLCipher is able to use the key to access your database. We generally recommend you attempt to execute the following query to validate the password is valid as the sqlite_master table will always be present, regardless of your schema.
SELECT count(*) FROM sqlite_master;
An old version of an application has some passwords stored in the clear in its database. I have written an updated version that encrypts the passwords when new entries are made, but I don't have direct access to the database to manually encrypt the entries that already exist. When the update goes live, it will try to decrypt the plaintext passwords, and crash.
Short of doing something drastic like deleting all the existing data, the only other approach I can think of is this (wrapper pseudocode called when the password data is used.):
# data refers to the password data, either encrypted or plain
if data length < AES.block_size:
# (Shorter than initialization vector, definitely not encrypted.)
open database and replace password entry with encrypt(data)
login(username, data)
else:
try: # try plaintext first
login(username, data)
except AuthenticationError:
login(username, decrypt(data))
else: #plain text worked, encrypt data for future use.
open database and replace password entry with encrypt(data)
It seems a shame to keep this code around to solve a problem that goes away after it runs once. Is there any other approach that might work to ensure the passwords are encrypted and only decrypt the ones that need it?
In this scenario I do one of the following, depending on the client and the system involved:
Set up the encrypted password code, delete all existing passwords, and make everyone enter a new password. I prefer this because the passwords were plain and over time may have been seen or shared.
Run a one-time script to encrypt every password in the system. This way there is never a mix.
Have newer encrypted passwords prefixed with the encryption method, e.g. "SHA1:". You run the risk of someone having that same text as the start of their password, but it is unlikely.
Every password that i enter and when i click the button, it tells me that the password is wrong. it activates this field in its properties: InvalidPasswordErrorMessage.
I suspect that the user tries to use the password to connect to the database.
Another weird thing, is even when a password fails to be created..(invalid), the control stores the record in the database... for example in the PasswordFailed in the members table, i get a date and the users details (The control did it in a few occassions, which is bad for login)..
The main issue however, is with the password always being invalid..
In the membership configuration you will find attributes for setting minimum number of non alpanumeric characters, min length etc. Try lowering all such values and see if it accepts your passwords. A complex password like "abc%12U8" should also be accepted.
But the error message also displays upon db connection errors so you should test the connection to the database.
also the db identity should be a member of all the "aspnet_.*" roles on the database.