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
Related
Using flyway to manage our snowflake objects, but would like NOT to use user/password based authentication and instead use user+ Auth-key based authentication mechanism supported by Snowflake.
flyway.url=jdbc:snowflake://<myaccount>.snowflakecomputing.com/?private_key_file=<abs_path_to>/.ssh/rsa_key_fdb_user.pem&db=mydb&warehouse=etl_dev_wh&role=etl_dev_role&user=etl_dev_user
However, with the flyway.url set to above pointing to my location of private_key_file, it simply prompts me for a "Database password:" from the command line -
./flywaydb/flyway -configFiles=<absolute_basepath>/conf/flyway-dw.conf info
I was hoping that the user's Auth would get done based on the private key provided.
Please edit your config file and enter a dummy password as flyway.password:
flyway.password=wrongpassword
It should stop asking password and connect to Snowflake with the private key, in case you configured your user with rsa_public_key:
https://docs.snowflake.net/manuals/user-guide/jdbc-configure.html#privatekey-property-in-connection-properties
Can someone please give me an example for corporatePasswordStore that is mentioned here:
https://docs.corda.net/node-administration.html?fbclid=IwAR0gRwe5BtcWO0NymZVyE7_yMfthu2xxnU832vZHdbuv17S-wPXgb7iVZSs#id2
I've been doing a lot of research in the last few days on how to hide the plain passwords from node.conf; it's a new topic for me and this is what I came up with so far:
Create a priv/pub key with gpg2
Create a password store with pass (using the key that I generated earlier).
Store all the plain passwords from node.conf inside that password store.
Replace the plain passwords in node.conf with environment variables (e.g. keyStorePassword = ${KEY_PASS})
Create a script file (e.g. start_node.sh) that will do the following:
a. Set an environment variable to one of the passwords from the password store: export key_store_password=$(pass node.conf/keyStorePassword)
b. Start the node: java -jar corda.jar
c. Restart the gpg agent to clear the cached passwords, otherwise you can get any password from the store without passing the passphrase: gpgconf --reload gpg-agent
Pros:
Using the bash file start_node.sh allows to set many passwords as environment variables at once (e.g. keyStore, trustStore, db passwords, RPC user password)
Since we are running the bash file with bash start_node.sh and not source start_node.sh, the environment variable is not exposed to the parent process (i.e. you cannot read that environment variable value inside the terminal where you ran bash start_node.sh
History commands are not enabled by default inside bash scripts.
Cons:
You no longer can have a service that automatically starts on VM startup, because the start_node.sh script will ask for the passphrase for your gpg key that was used to encrypt the passwords inside the password store (i.e. it's an interactive script).
Am I over-complicating this? Do you have an easier approach? Is it even necessary to hide the plain passwords?
I'm using Corda open source so I can't use the Configuration Obfuscator (which is for Enterprise only): https://docs.corda.r3.com/tools-config-obfuscator.html#configuration-obfuscator (edited)
I wrote a detailed article here: https://blog.b9lab.com/enabling-corda-security-with-nodes-configuration-file-412ce6a4371c, which covers the following topics:
Enable SSL for database connection.
Enable SSL for RPC connection.
Enable SSL for Corda webserver.
Enable SSL for Corda standalone shell.
Hide plain text passwords.
Set permissions for RPC users.
I'm trying to implement a system call which prints hello "current username". I tried using getpwuid(getuid()) but didn't work cause I was unable to include pwd.h or unistd.h or sys/types.h. I currently have no idea how to do the work.
Linux kernel has no notion about username; it knows only user identificator (uid).
Mapping from uid to username is contained in user database, which is stored as a file /etc/passwd. You need to parse this file for extract username.
I want to encrypt db.username and db.password written in alfresco-global.properties .
Can anyone please help me in this, where that username & password is used so that i can write decryption code there, so that alfresco can understand.
I am using Alfresco 4.2 Enterprise.
Can't you just change permissions on alfresco-global.properties so only the user running the Alfresco JVM can read it ?
Anyways, that said the values are used in tomcat/webapps/alfresco/WEB-INF/classes/alfresco/core-services-context.xml. Create a custom bean baseDefaultDataSource deriving from org.apache.commons.dbcp.BasicDataSource and handle the decryption in that class. Make sure to pass the decrypted value to the jdbc driver. Also make sure the definition gets processed after the defaults kick in. You might want to drop your spring context into tomcat/shared/classes/alfresco/extension.
I am connecting to a Teradata database through ODBC with Stata on an Ubuntu server (12.04 LTS). Everything works fine, except that I have my TD userid and password stored in the .odbc.ini file, which seems like a terrible idea. The alternative is to enter them in Stata, which seems even worse and is awkward. Is there a way to do this more securely? The login info that I use to ssh into the server is synced with the TD database. It seems that it should be possible to pass that information along.
In ODBC terms you do not need to store usernames / passwords in any of your ODBC ini files. Both the ODBC SQLConnect and SQLDriverConnect support the passing in of username / password at the time they are called.
SQLDriverConnect would need something in your InConnectionString like "DSN=YourDataSourceName;UID=username;PWD=password".
You could go one step further and pass in the whole DSN as a command line argument thus meaning that you would not need an ODBC data source in an ini file. I'm sure one of the forum readers can post a sample for you from Teradata.
As for passing in the user name and password from your SSH loging. Your application would need to capture that and pass it to ODBC.
If you want to establish a finer grain of security around your odbc.ini file or other files on your Ubuntu server that may contain user credentials I would strongly suggest the use of Access Control Lists (ACLs). Beyond the typical Owner::Group::World permissions you can specify permissions down to the specific user on whether they are allowed or denied an explicit permission for a given file.
Other options regarding security on Teradata include the use of LDAP authentication if your environment supports it. Configuring LDAP on Teradata is beyond the scope of SO and in many cases a billable, professional services engagement with Teradata's Information Security CoE.