Without making any changes to settings.js file, I can see two JSON documents in .node_red folder - one for the flows and other for credentials. For example, flows_ip-xxx-xxx-xx-xx_cred.json and flows_ip-xxx-xx-xx-xx.json. Then, there is a field as credentialSecret in the settings.js file.
On a fresh Node-RED installation, suppose, I manually copied flows_ip-xxx-xx-xx-xx.json only, from an earlier installation, followed by a restart. I will copy into a different_name.json that is also mentioned for the flowFile property. Then, are the credentials still copied over but encrypted with a (different) auto-generated password? In which case, if I defined a common value for credentialSecret option in settings.js for both installations, the nodes would get correct credentials in the new installation?
I should probably be using the projects option; but, until then, I want to figure out the credentials behavior.
If you do not set a credentialSecret in settings.js then Node-RED will create a key the first time it starts and store it in the hidden file called .config.runtime.json in the user directory.
This key will be used to encrypt the flows_creds.json to protect the credentials file.
If you need to move a flow to a new machine then you can copy the _credentialSecret value from .config.runtime.json to the credentialSecret in the new settings.js to allow it to decrypt the existing credentials file.
If you are starting from scratch then you can choose to define your own credentialSecret in the settings.js on both machines to allow them to decrypt a common flow_creds.json file.
And yes the new project feature makes this a lot easier.
Related
I've just been through the steps to upgrade our Rails app from 5.1.6.2 to 6.0.0 via 5.2, (I chose to not to worry about the credentials concern until 6.0.0 in case it ended up meaning I had to figure out new credentials twice).
I've been looking at a number of guides as to how to use the new credentials when upgrading, but they all feel like they're missing a final step, or I'm misunderstanding something. Doing no credentials upgrade at all seemed to cause no problems in my local development environment, but when attempting to deploy to our production env (Convox/AWS), I got the following error:
Missing encryption key to decrypt file with. Ask your team for your master key and write it to /app/config/master.key or put it in the ENV['RAILS_MASTER_KEY'].
Confusingly (to me), the was already an ENV var of that name with a secret key set, and any changes to it locally before or after stepping through the guides raise a ActiveSupport::MessageEncryptor::InvalidMessage (ActiveSupport::MessageEncryptor::InvalidMessage) error.
Stepping through the guides, I'm using Sublime, so initially I ran EDITOR="subl --wait" rails credentials:edit, and then pasted the secret key base value over the current value of config/master.key - causing the error above. Which has left me unsure of what I'm actually supposed to do with the secret_key_base key. I've tried putting it in the prod env var RAILS_MASTER_KEY, but then on deployment that still gets the error Missing encryption key to decrypt file with. Ask your team for your master key and write it to /app/config/master.key or put it in the ENV['RAILS_MASTER_KEY']. I've tried deleting the secrets.yml file in case that was overwriting something, but that doesn't change the deployments message.
So what else should I have done?
I would create a master.key file in your config folder and add your key to it. (The value you used to set RAILS_MASTER_KEY env var. However, make sure you exclude it from VCS (just add it to your .gitignore). That should fix your problem, given the key is the right one. If not, you will have to regenerate the encrypted credentials file altogether.... but that's another story.
For example, I have a npm package which is a cli-tool. Users should set their yahoo email and password first before using the functionalities.
My question is where should I store the personal data? Is there a convention?
Most cli's use a hidden configuration file commonly stored in the home directory of the user. For example .cli-config, it is also good to store the configuration data as JSON or YAML.
Finally be carful to save sensitive data in the config file as it still is just a file and can be accessed by anyone with correct permissions.
With mongoose.connect('mongodb://username:password#host:port/database?options...');, which I use in a script, I don't suppose there is any real way to hide the password?
Should I even be concerned if the Mongodb is only listening on 127.0.0.1? If my server can get exploited then the can just cat that script to get the password.
You can put the password in a environment variable when launching node, or read it from a file not checked into source control. If mongodb is only listening on localhost, an attacker would not be able to connect directly to the database from a remote machine. It would still be advisable to configure your firewall to block remote access, just in case some configuration change opens mongodb up publicly.
Here may be one related topic Store db password as plain text in node.js
Solution 1:
Use an environment variable.
Run your app with MONGO_PASSWORD=yourpasswd node app
Then you can access it inside the app with process.env.MONGO_PASSWORD
Solution 2:
Make a module (I call it "secrets") that exports all of your secret credentials. Don't check it into source control. Then, your app can just require('secrets').
Solution 3:
Trousseau is an encrypted key-value store designed to be a simple, safe and trustworthy place for your data.
All the answers above are good suggestions, but they still leave the password visible on the host in a easy to figure out location...rather in shell env variable or a file.
What I decided to do is upon every server boot up, make a job that creates a file for the mongoose script to be read that has the password. Then, have a cron job that deletes the file after 5 minutes after boot up. That password still exists on the system, but it would be much harder to trace where.
You will create a .env file on your node file.Then you put your User name and Password just like this DB_USER=Your Username and DB_PASS=Your password.
Then you will insert it to your index.js file by enter image description here
I'm looking for a means to programmatically tell Notes to generate a secret key (like File, Security, User Security, Notes Data, Documents). Is there such? It does not appear so.
The goal is to be able to have a template that auto-provisions all of the secret keys necessary for that application to operate.
As Richard mentions there is no direct way to fully automate this, but you can automate some of it.
In Domino 9 it is possible to create secret keys via the Domino console. So you would do something like the following.
keymgmt create nek SECRETKEY
keymgmt export nek SECRETKEY FILENAME PASSWORD
keymgmt delete nek SECRETKEY
This will create a .key file of FILENAME. You can then mail this file to the end user. However the end user would need to detach the key file and manually import it into notes. They will also need to know the password to import.
[edit]
To expand on this. You could do the following.
Create your initial secret keys on the server as per the command above.
Create an agent which executes the export with a randomly generated password.
Same agent mails the key file, with instructions to install.
Same agent sends a second email with the randomly generated password.
It won't stop the end user from forwarding on the key/password to someone not authorised to use the database (which is what an IDK prevents), but you could have some level of auditing this way.
As far as I know, the Notes client's secret key generation and management features are not exposed in any of the Notes APIs, including the Notes C API.
I have a small Sinatra app I'm running on Heroku that uses a single admin password, plus a couple API authentication keys.
Where's the best place to store these things? Do I put them in environment variables, and use
heroku config:add ADMIN_PASSWORD=foobar
? Or do I use a config file that contains them, and I simply don't commit the config file?
I stick API keys and that sort of thing in a config yaml, like so
development:
twitter_api_key: stringstringstring
chunky: bacon
production:
twitter_api_key: gnirtsgnirtsgnirts
foo: bar
then use Sinatra's builtin set to handle the data.
configure do
yaml = YAML.load_file(settings.config + "/config.yaml")[settings.environment.to_s]
yaml.each_pair do |key, value|
set(key.to_sym, value)
end
end
And I can then access them from the settings object. I'm not sure why you wouldn't commit the config file, though . . . there's no major security risk here, since only those paths that you've explicitly defined can be accessed via the web. I guess the admin password could be stored in the same manner if you don't want to put it in a database, but I would at least encrypt it with a salt.
Just be careful not to step on Sinatra's Configuration settings when defining your own.
EDIT:
I think I just realized why you would prefer not to commit the config file. If you're working on an open source project, you certainly wouldn't want to commit the config file to your open source repo, but you would need to commit the file to Heroku in order for it to work. If this is the case, I'd either:
Use two separate local repos: one for the open source project, and one for the heroku project. Just set the open source project as an upstream repository in the Heroku project, then you can fetch changes.
Put both the API keys and encrypted/salted password in a database; MongoHQ offers a free tier to Heroku users as an addon for simple nosql storage using MongoDB.