I'm completely new to boxen (and puppet) and I want to prompt a user for a password during set up. I need to encrypt the input and add it to a config file.
I'll be using a template to generate the file, but getting the password is a little tricky since puppet wont write to console when executing code inside of a template.
I've considered doing this using a ruby or shell script to prompt the user and then store the password in an environment variable to use later in the template, but I don't know if this is the best or most secure way to do this.
Any suggestions? is there a "best practice" for doing this sort of thing with boxen/puppet?
You can use hiera and encrypt hiera data using the hiera-gpg or hiera-eyaml backend
Other option is to use facter with environment variables FACTER_MYPASSWORD or external facts under /etc/facter/facts.d
Related
A script has been written to access a website programatically(sending a get request) that requires user login credentials, and so the same has been hardcoded in the script.Is there a way in python to hide these credentials from the test script?
You could use something like this:
https://github.com/microsoft/Windows-universal-samples/tree/master/Samples/PasswordVault
Alternatively, if your script is only going to run on one server, you could keep the credentials in the environment variables on that machine and make the script refer to those variables.
Is there a way to programmatically add secrets to config/credentials.yml.enc in Rails 5.2?
Pushing the credentials.yml.enc to the repository for internal use may be fine, but as soon as the app is used by other people, they require different secrets within their environment. Like the Oauth2 credentials will differ for each implementation.
Running the app within docker (for example) will require more manual interaction, and Docker-know-how than usual. In most cases the more secure way is only used if it isn't much more effort.
One will need to run docker exec <app-name> -it /bin/bash first to be able to run rails credentials:edit.
It would be way better to be able to fill the credentials file programmatically.
One could for example provide a temporary credentials file like:
production:
postgresql:
username: 'admin'
password: 'very_insecure'
Then there could be a script adding the file's content to the credentials-file and deleting the temporary file afterwards.
For sure the RAILS_MASTER_KEY environment variable must be set (could be again a script moving the content of the master.key file into the variable) to gain any profit of that.
You can do this via some trickery with the EDITOR environment variable.
Normally, you'd use EDITOR=nano rails credentials:edit in order to have Rails pass (a temporarily decrypted copy of) credentials.yml.enc to nano for modification, with the result being re-encrypted when nano terminates.
If we substitute nano with cat (EDITOR=cat rails credentials:edit), Rails will pass the (decrypted) file to cat instead, causing its contents to be printed on-screen. In other words, Rails is effectively just running $EDITOR tempfile.name.
Therefore, if we do this:
EDITOR='echo "foo: bar" >> ' rails credentials:edit
...then the result will be this:
echo "foo: bar" >> tempfile.name
tl;dr: You can abuse EDITOR to (indirectly) do pretty much anything you'd do for a regular plain-text file.
My .passwd file contains 2 usernames and 2 passwords.
userNameX:$apr1$F3EFwwfP$W4gD4e/W98FerHQWDErfX0
userNameY:$apr1$Nq21ft8f$CRW4OdeRDVLsLnFwFaXyE0
They have been automatically generated by the old server just providing username and clear password.
Now I have just moved to the AWS Elastic Beanstalk, these two usernames/passwords work very well, but I would like to create more users and passwords. How should I do?
If you want to use htpasswd, look at htpasswd - Options.
There, you have the warning about password on the command line
-b
Use batch mode; i.e., get the password from the command line rather than prompting for it. This option should be used with extreme care, since the password is clearly visible on the command line. For script use see the -i option. Available in 2.4.4 and later.
And the recommended option -i:
-i
Read the password from stdin without verification (for script usage).
This way, you can pass the password through standard input through a pipe (e.g. popen).
You can also look at some authentication module, depending on the language and web framework you use.
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
Typically in a large network a computer needs to operate behind an authenticated proxy - any connections to the outside world require a username/password which is often the password a user uses to log into email, workstation etc.
This means having to put the network password in the apt.conf file as well as typically the http_proxy, ftp_proxy and https_proxy environment variables defined in ~/.profile
I realise that with apt.conf that you could set chmod 600 (which it isn't by default on Ubuntu/Debian!) but on our system there are people who need root priveleges .
I also realise that it is technically impossible to secure a password from someone who has root access, however I was wondering if there was a way of obscuring the password to prevent accidental discovery. Windows operates with users as admins yet somehow stores network passwords (probably stored deep in the registry obscured in some way) so that in typical use you won't stumble across it in plain text
I only ask since the other day, I entirely by accident discovered somebody elses password in this way when comparing configuration files across systems.
#monjardin - Public key authentication is not an alternative on this network I'm afraid. Plus I doubt it is supported amongst the majority of commandline tools.
#Neall - I don't mind the other users having web access, they can use my credentials to access the web, I just don't want them to happen across my password in plain text.
With the following approach you never have to save your proxy password in plain text. You just have to type in a password interactively as soon as you need http/https/ftp access:
Use openssl to encrypt your plain text proxy password into a file, with e.g. AES256 encryption:
openssl enc -aes-256-cbc -in pw.txt -out pw.bin
Use a (different) password for protecting the encoded file
Remove plain text pw.txt
Create an alias in e.g. ~/.alias to set your http_proxy/https_proxy/ftp_proxy environment variables (set appropriate values for $USER/proxy/$PORT)
alias myproxy='PW=`openssl aes-256-cbc -d -in pw.bin`; PROXY="http://$USER:$PW#proxy:$PORT"; export http_proxy=$PROXY; export https_proxy=$PROXY; export ftp_proxy=$PROXY'
you should source this file into your normal shell environment (on some systems this is done automatically)
type 'myproxy' and enter your openssl password you used for encrypting the file
done.
Note: the password is available (and readable) inside the users environment for the duration of the shell session. If you want to clean it from the environment after usage you can use another alias:
alias clearproxy='export http_proxy=; export https_proxy=; export
ftp_proxy='
I did a modified solution:
edit /etc/bash.bashrc and add following lines:
alias myproxy='read -p "Username: " USER;read -s -p "Password: " PW
PROXY="$USER:$PW#proxy.com:80";
export http_proxy=http://$PROXY;export Proxy=$http_proxy;export https_proxy=https://$PROXY;export ftp_proxy=ftp://$PROXY'
From next logon enter myproxy and input your user/password combination! Now work with sudo -E
-E, --preserve-env
Indicates to the security policy that the user wishes to reserve their
existing environment variables.
e.g. sudo -E apt-get update
Remark: proxy settings only valid during shell session
There are lots of ways to obscure a password: you could store the credentials in rot13 format, or BASE64, or use the same password-scrambling algorithm that CVS uses. The real trick though is making your applications aware of the scrambling algorithm.
For the environment variables in ~/.profile you could store them encoded and then decode them before setting the variables, e.g.:
encodedcreds="sbbone:cnffjbeq"
creds=`echo "$encodedcreds" | tr n-za-mN-ZA-M a-zA-Z`
That will set creds to foobar:password, which you can then embed in http_proxy etc.
I assume you know this, but it bears repeating: this doesn't add any security. It just protects against inadvertently seeing another user's password.
Prefer applications that integrate with Gnome Keyring. Another possibility is to use an SSH tunnel to an external machine and run apps through that. Take a look at the -D option for creating a local SOCKS proxy interface, rather than single-serving -L forwards.
Unless the specific tools you are using allow an obfuscated format, or you can create some sort of workflow to go from obfuscated to plain on demand, you are probably out of luck.
One thing I've seen in cases like this is creating per-server, per-user, or per-server/per-user dedicated credentials that only have access to the proxy from a specific IP. It doesn't solve your core obfuscation problem but it mitigates the effects of someone seeing the password because it's worth so little.
Regarding the latter option, we came up with a "reverse crypt" password encoding at work that we use for stuff like this. It's only obfuscation because all the data needed to decode the pw is stored in the encoded string, but it prevents people from accidentally seeing passwords in plain text. So you might, for instance, store one of the above passwords in this format, and then write a wrapper for apt that builds apt.conf dynamically, calls the real apt, and at exit deletes apt.conf. You still end up with the pw in plaintext for a little while, but it minimizes the window.
Is public key authentication a valid alternative for you?
As long as all three of these things are true, you're out of luck:
Server needs web access
Users need absolute control over server (root)
You don't want users to have server's web access
If you can't remove #2 or #3, your only choice is to remove #1. Set up an internal server that hosts all the software updates. Keep that one locked down from your other users and don't allow other servers to have web access.
Anything else you try to do is just fooling yourself.
we solved this problem by not asking for proxy passwords on rpm, apt or other similar updates (virus databases, windows stuff etc)
That's a small whitelist of known repositories to add to the proxy.
I suppose you could create a local proxy, point these tools through that, and then have the local proxy interactively ask the user for the external proxy password which it would then apply. It could optionally remember this for a few minutes in obfuscated internal storage.
An obvious attack vector would be for a privileged user to modify this local proxy to do something else with the entered password (as they could with anything else such as an email client that requests it or the windowing system itself), but at least you'd be safe from inadvertent viewing.