I got a little system here that encrypt a connection string used in SQL Server.
When I put a connection like:
Server=WK-001;Database=4RSYSTEM;User Id=user1;Password=user123;
I receive that encrypted string:
rJUDUypxZUSmrFHgkTW0GY3Xpf97WOaWIa4dbwJK85an9QsCWMJbjaKT8LxAUEjl9hPo0gW3CVA7IiTpOvqAcw==
Btw, now I got a encrypted string (generate by the same "system") and I need to decrypt. There's a way to discover the encryption method / how decrypt it?
Related
I am trying to get my head over this and hope someone can explain what is happening. I have a PGP key pair from which I encrypted a message after specifying the cipher algorithm like AES_128, AES_192 or TWOFISH. Later, I tried to decrypt that encrypted message using a different cipher algorithm and I could still see the message.
How is this possible if I am encrypting a message using cipher AES_128 then how is it getting decrypted using the CAST5 cipher algorithm? I was expecting it to fail or at least get some garbage data however I could see the exact plain text that I encrypted in the first place.
I am trying to pass encrypted email address in my robot framework but i keep getting the below error. How do i fix this?
ValueError: Send Message failed: {"'crypt:\Cryptedvalue'": (553, b"5.1.3 The recipient address <'address'\n5.1.3 'some value'='> is not a valid\n5.1.3 RFC-5321 address. Learn more at\n5.1.3 https://support.google.com/mail/answer/6596 g9-20020a05620a108900b0067b13036bd5sm5495282qkk.52 - gsmtp")}
Programming is like Excel. Start backwards.
Were you able to insert the email address without the encryption first?
Then use an easier encryption or try to create the insertion using code conversion without encrypting the code conversion like using a binary file.
Then use the base encryption, a popular encryption (md5), and then move on to your desired encryption SHA -.
I am using entity framework database first approach .I have connection string in my config file how can I encrypt my connection string and then how can I decrypt for entity framework
i used aspnet_regiis.exe but I get this error (The RSA key container could not be opened.) when I run software
I'm not using command line, merely two separate GUI programs that should functionally work together, but I'm unable to both verify a signed file and decrypt a file sent to me by someone else using Symantec's PGP program and I'm using "GPG Keychain." They have my public key and I have theirs. Any idea why they're not working when they should be?
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.