I wrote a helper script in Ruby to handle my file synchronization through some servers. It was used only in my intranet and authentication was made by SSH keys. But now I want to use it where I can't use SSH keys and I want to store the passwords in a config file.
I know, there are some encryption libraries like bcrypt or OpenSSL, but I have a problem with that:
I start my script and enter my passphrase and it is stored in a variable to decrypt my passwords.
My code is open source.
So everybody, who has access with my user to my computer (which would be the first barrier, which I'd like to extend) and looks into the memory (where my passphrase is stored) can decrypt my password file. How is that handled in applications which are relevant to security?
Edith says as a reply to DevDude (but here, because I want to keep my specifications in my question):
But then this configuration file would be plain text and not encrypted. And when I encrypt this file there are two more issues in my opinion:
The super_secret_pwd would be stored in a variable, so when I would search in the memory of the computer, I would find it, wouldnt I?
The master password for encryption would be in the memory as plain text, too.
So the big question is: Is it possible to read plain text variables from the memory? As I know it is possible in C and a big security issue.
What you are looking for is to use a YAML file with the password/API keys. and never check this file into your repo.
Then you can reference this file on your initializers, and maybe make the password a global variable or x, use configatron, etc.
This is basically how production applications work, they read their important settings from a YAML file stored on the server itself.
This is what I use:
#c = configatron
# Per environment settings
app_settings = YAML.load_file('config/secret_stuff.yml')
#c.password = app_settings['super_secret_pwd']
Do not use ENVIRONMENT variables because they have all sort of security issues. They are an antipattern.
Related
Here is the link 12 factor
I am confused weather if I should store values inside my app.properties file vs environment variable.
App.properties
Memory_Folder_Test = Test
Memory_Folder_Prod = Production
Memory_Folder_Dev = Development
Strong_threshold = 10
Low_Threshold = 2
Username = FirstUser
Password = PasswordSecret
So theoretically where should I put these values in? application.properties or as environment variables? If I did not read wrong the purpose of 12 factor is to remove putting values in properties file and externalize it.
You can store the values in application.properties file, however, spring allows you to override those values using environment variables. Hence, it is a 12 factor compliant.
You store the properties externally using something like spring cloud config. You then use the environment properties to define the configurations (like the url) needed to access cloud config from your applications
I prefer to store environment variables in files, encrypt the files and check the encrypted files into git, via blackbox: https://github.com/StackExchange/blackbox
Blackbox will handle encryption/decryption so that it makes it rather difficult to check the unencrypted creds into your repo. Also, the way openpgp works, you can enable teams of devs to encrypt/decrypt the files.
That project is maintained by StackExchange (aka the guys who run this site). It takes some time figuring out openpgp/gpg (which blackbox depends on), but it has been well worth it for me. I've been using in linux and also in windows (via the windows linux subsystem).
I need to change the password on a user for over a hundred system. I want to do this with ansible. Which is easy. However the user module on ansible requires a hashed password. I am concerned because there are a few older hosts which may not support newer types of hashing. I want to be able to programmatically identify what password hashing algorithms are available, and use the appropriate password hash to change. Or is there perhaps a better way to handle this whole sale.
I have considered the following:
echo username:password | chpasswd
and run that using the command module. That should use whatever the default algorithm is. Is there any cause for concern with this method?
In my mind, the ideal way would be to figure the supported hashes for each machine and then generate the proper hash for each machine.
The approach you list should work Just make sure you at "no_log: yes" to your task to ensure the password doesn't end up in the log file.
With either approach you're going to need have a way of getting the password(s) into ansible to use with the user module. Not sure if the passwords will be in a CSV file, yaml file or some other format. You could consider using vault to lock things down a bit more.
I am using the cipher command to encrypt a file so that nobody can read that.
I tried this command : cipher /e /a exp\test.txt
I noticed the content of the file remained same. Only the file properties changed to encrypted. (Also the color of the filename changed to green. :P). I can still read, modify and delete the file.
Later I tried to decrypt: cipher /d /a exp\test.txt
The content as before same and in properties encrypted is unchecked.
I can read write and delete the file after encryption, what is the meaning of encryption then? How to use it properly? Am I missing something? Can anybody help me on this cipher command?
The cipher command on Windows allows you to control the encryption of files/directories provided by the Encrypting File System (EFS).
The important thing to note about EFS is that it is transparent encryption from the point of view of those granted access to the files. In other words, whilst the file data is encrypted on disk, providing you have keys to the file, you don't need to explicitly decrypt it in order to view the contents, it can just be read as any other file and the file system handles decrypting the data automatically. However, if you were to try and access the file as another user on the machine, or by reading data directly off the disk the file would be inaccessible.
You're not doing anything "wrong" here, it's just that cipher and EFS don't do what you expect them to.
The file is indeed encrypted at the file system level. That is, it's encrypted on disk, but NFTS will automatically decrypt on behalf of any application that is attempting to read that file running under your account.
Copy the encrypted file to a shared (NTFS) disk directory and validate it's still green in explorer. Then sign out and sign in with another account on this PC. I don't think you'll be able to read the file.
I'm writing a Ruby script that uses the PG gem to set up a database connection and send files. I'm structuring it to take variables for the hostname, username, database name, and port. In a Shell script I've written to manage some companion tasks, I rely on the password stored in ~/.pgpass instead of having the user enter a password for psql because there are a lot of transactions and sometimes entering the password can fail for no apparent reason (and it sucks entering it in 20 times).
Will PG access the same source when a password isn't explicitly provided? By convention, I've included the password in the file, but since this is being pushed to an internally available repo, I'd prefer not to have that information in my file. I'm trying to test the functionality now, but was wondering if anyone in the SO community knows the answer to this question. If PG doesn't access the .pgpass file, is there a way to reference the variable and write it into the file without prompting the user to enter the password?
Thanks in advance for your help.
Yes, it will use ~/.pgpass just like any interface based on libpq, the C PostgreSQL client library.
However, a good alternative for not having the password in a file is to have it in the PGPASSWORD environment variable. If you set this in a script, it will be inherited by every program it calls.
PGPASSWORD when set will be used as the password for any libpq connection, which means the majority of programs that connect to PostgreSQL.
I am learning to use maven password encryption capabilities and I would like to know how to choose the parameter <password>. There are two things that I don't understand:
1) mvn --encrypt-master-password foobar will always give a different encrypted master password.
Since the encrypted master password is always different, I see only two possibilities:
A local property is stored somewhere so that it can be used to decrypt the encrypted master password to get the master password. That means that our encrypted server passwords can only be used locally.
Nothing is stored and the master password is useless and doesn't matter at all.
So, my questions here are:
What is stored locally? Will my master password remain safe? Is there a third possibility I didn't think of?
2) On the maven website, it is written:
Also note that the encrypted passwords can be decrypted by someone that has the master password and settings security file. Keep this file secure (or stored separately) if you expect the possibility that the settings.xml file may be retrieved.
If the settings security file is the thing to protect, why should I bother choosing a strong master password? Can't I just use foobar and keep my settings security file safe?
Also, it looks like someone with the two files (settings security file and settings file) would not need the master password to connect to the maven servers. He could use our identity without knowing the passwords. The master password is "only" needed to decrypt the servers passwords (to get them plain text). But then again, protecting the settings security file should be the way to go and the master password would remain useless.
My questions:
How important is the master password? Have I got to remember it? Can I use a long random phrase and forget it forever?
PS: I couldn't find my answer here.
First password is used to generated the master password only, then you can forget it. It is generated using encryption mechanisms and pseudo-random component. As a consequence of that, it should not be possible to decipher it. There is nothing else stored locally than your master password in your security-settings file and it won't be ever prompted or asked again.
This master password is used to cipher and decipher passwords in your settings file. It has the same value as an user-introduced password, but it is almost impossible to deduce it.
Then:
There is nothing else stored locally than your master password in your security-settings file and it won't be ever prompted or asked again. All the safety resides in the safety of the security-settings file.
The master password is not really important and you can forget immediately. You can use whatever you want.
I don't like this approach to protect my password and I would like having a real password cyphering mechanism with a real master password not stored. Public-private key with password strategies seems to be better.