Context
platforms: archlinux and ubuntu
I have a shell script that backs up my data to a restic server. In order to perform the backup, the script needs access to the restic repository password. There are multiple ways to provide restic with the password (user input, env variable, shell command, file) and I am currently saving the password as plaintext in a file.
Problem
This file is only accessible to root (the script runs as a systemd service as root) but it does not make it particularly secure. Anyone getting access to my laptop could recover my backup password. I know I can change the password of a repository if my laptop gets stolen but I am looking for a solution that does not involve human intervention. I looked for how people more experienced than me do that but could not find any better way.
The user input method does not suit me as I want the script to be fully automated.
The environment variable method only moves the problem as this variable needs to be set at some point and stored in a file.
A shell command could maybe decrypt the password from a file but that also just moves the problem to store the decryption key. However, if the decryption key could be handled by the system in a secure way that could work. I don't have any experience in that so I don't know where to look but this is the most promising way I found.
Question
Is there a secure way to store the password of a restic repository in order to perform automatic backups that would prevent an attacker (that gets access to the machine) from recovering the password?
PS
I want to avoid manually entering the password. I want the script to be fully automatic. I am looking for some kind of lock on the password file that would open when I am logged in. I have no idea if such a thing exists.
Thanks!
you need to customize the restic.exe to get the password from some storage vault in web ( check this and do the modification in code to get the password from storage vault ) https://github.com/restic/restic
Some thing like this.
Restic should not take password from commandline/ environmental variable.
Restic should take password from some storage vault (that has the password ) For this you need to customize it by changing the restic code base.
You can also encrypt the password stored in vault and decryption will happen in the restic.exe ( this require additional changes)
You need learn go language and to this implementation as restic is implemented in golang
It might take a week time to do the implementation
Related
I am running nodejs apps access resources on different servers, and I need to store the keys somewhere. Now, it is considered a bad idea to check-in user credentials or encryption keys in code repository. What is the best way to manage these keys in a secure manner?
One option I found is to save them in environment variables, and then later read their value when needed in script. Two methods I know of to populate env variables are: set them while running the script on command line (e.g USER_KEY=12345 node script.js) or let them be read from a local file on hard drive. But I want to access these keys on a random CI pipeline machine, so cant store file on disk and cant load them from command line.
Second option is to read these keys from a remote machine. Is there a known Crypto/Key Management Service or another popular NodeJS way to save credentials in a key store and then let script read it from there at run-time. Is there another way?
I just uploaded my local svn file repository to an svn host. I notice that when checking out the code to my local (Linux) computer I have to provide my username and password (as expected) but subsequent operations (checkout, commit, log, etc.) does not require any authentication, so I take it that after initial login I stay logged in for some time.
My questions related to this are:
How long do I stay logged in like this?
What would trigger my access to the repository to expire?
Can I manage the expiration time, and if so, is it done server side, or in my local subversion configuration?
I'm running svn 1.7.9 on Ubuntu 13.10 Linux.
Thanks!
1) How long do I stay logged in like this?
You are not logged in. Your authentication tokens are saved somewhere under ~/.subversion/auth.
2) What would trigger my access to the repository to expire?
If you remove the file under ~/.subversion/auth which stores your password for the particular repository, then you will have to reenter the password again.
3) Can I manage the expiration time, and if so, is it done server side, or in my local subversion configuration?
That really depends on how authentication is configured on the server side.
Btw, you can prevent Subversion from saving your authentication tokens if you checkout using --no-auth-cache.
UPDATE
There is a lot more to this, as #BenReser points out:
Realize that the password is not necessarily stored under ~/.subversion/auth. We support a variety of platform specific credential storage (Windows Crypto API, OS X Keychain) and even in 1.8 GPG Agent. The GPG Agent case would behave somewhat like what he's envisioning, where the password is cached only for a certain amount of time, which he could configure. There is also NTLM/Kerberos support that may behave like a single sign on as well. So frankly it's really hard to answer this question without more details about his configuration.
Every time I commit a file in svn I get the following message:
ATTENTION! Your password for authentication realm:
http://domainname.com:80 “domainname.com”
can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.
You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in '/root/.subversion/servers'.
Store password unencrypted (yes/no)? no
I don't want this authentication; how can I get rid of this warning?
You are not storing the password in Subversion because you answered no to the question whether or not you want to store this password.
I take it you want to eliminate this error warning message entirely. There are two ways to handle that:
The easy, but hard way: You can specify svn --no-auth-cache each and every time you a Subversion command. It's easy to do since it requires no real action on your part. It's hard because you have to do this almost every time you use a Subversion command (especially one that touches the repository like checkout and commit).
The hard, but easy way: You can modify your user's Subversion configuration not to ask if you want to store this information. (BTW, why are you running as root? You like living life on the edge? Better off running as a user and configure sudo to allow you to do the root stuff you need. That way, you can track who's doing what, and you don't do something that could accidentally bring the server down. In fact, many Unix/Linux systems by default no longer allow a user to sign in as root. You have to do sudo). This is hard because you have to do something, but easy because once you do it, you don't have to do anything again.
You have the name of the file that you need to edit (/root/.subversion/servers). Look for the [global] section and look for the line # store-passwords = no and remove the # from the beginning of the line. You can also do the same for the # store-plaintext-passwords = no line and the # store-auth-cred = no line. While, you're at it, you can also delete the files under the auth directory which is where Subversion stores its credentials. This will completely eliminate already stored passwords. More information can be found in the on line Red Bean Subversion manual.
Now, when you do a Subversion command that touches the repository, it'll ask you for a user name and password and won't ask if you want to store them.
You copied the full warning message here. Reading it instead of just copy/pasting it would answer your question:
you can avoid future appearances of
this warning by setting the value of
the 'store-plaintext-passwords' option
to either 'yes' or 'no' in
'/root/.subversion/servers'.
The subversion client is only asking for authentication because the server requires it. To get rid of the authentication requirement, you'll have to change the server's configuration (e.g., in Apache, get rid of AuthType, AuthName, and AuthUserFile). You can use other authentication methods which do not require passwords (for example, client certificates).
If you just want to get rid of the save password unencrypted prompt, you can set store-plaintext-passwords=off (by editing ~/.subversion/config) or you can make encrypted passwords work by getting (on Unices) the GNOME keyring or KDE wallet running. On Windows, SVN should automatically use built-in NTFS encryption; on Mac OS X, the Keyring. See the Client Credentials section of the SVN Manual for further details.
You could also encrypt your home directory on Unix. Then the credentials would be encrypted as well (but of course available to any program running as you or root while you're logged in, similar to the NTFS encryption).
If you don't want SVN to store passwords at all, encrypted or not, set store-passwords=no in the SVN config file.
I am building a suite of batch jobs that require regular access to a database, running on a Solaris 10 machine. Because of (unchangable) design constraints, we are required use a certain program to connect to it. Said interface requires us to pass a plain-text password over a command line to connect to the database. This is a terrible security practice, but we are stuck with it.
I am trying to make sure things are properly secured on our end. Since the processing is automated (ie, we can't prompt for a password), and I can't store anything outside the disk, I need a strategy for storing our password securely.
Here are some basic rules
The system has multiple users.
We can assume that our permissions are properly enforced (ie, if a file with a is chmod'd to 600, it won't be publically readable)
I don't mind anyone with superuser access looking at our stored password
Here is what i've got so far
Store password in password.txt
$chmod 600 password.txt
Process reads from password.txt when it's needed
Buffer overwritten with zeros when it's no longer needed
Although I'm sure there is a better way.
This is not a solution for cryptography. No matter the cipher used, the key will be equally accessible to the attacker. Cyrpto doesn't solve all problems.
chmod 400 is best, this makes it read only. chmod 600 is read write, which may or may not be a requirement. Also make sure its chown'ed by the the process that needs it. This is really the best you can do. Even if you are sharing the machine with other users they shouldn't be able to access it. Hopefully this is a dedicated machine, in that case there isn't much of a threat. SELinux or AppArmor will help harden the system from cross process/cross user attacks.
Edit:
shred is the tool you need to securely delete files.
Edit: Based on Moron/Mike's comments the unix command ps aux will display all running processes and the command used to invoke them. For instance the following command will be exposed to all users on the system: wget ftp://user:password#someserver/somefile.ext. A secure alternative is to use the CURL library. You should also disable your shells history. In bash you can do this by setting an environment variable export HISTFILE=
You're not far from the best approach given your constraints. You have two issues to deal with. The first is password storage. The second is using the password securely.
Dealing with the second one first -- you have a huge issue in the use of the command line program. Using options to the 'ps' command, a user can see the arguments used in running the command line program. From what you've written, this would contain the password in plain text. You mention this is an unchangeable interface. Even so, as an ethical programmer, you should raise the issue. If this were a banking application handling financial transactions, you might consider finding another job rather than being part of an unethical solution.
Moving on to securely storing the password, you don't mention what language you are using for your batch files. If you are using a shell script, then you have little recourse than than to hard code the password within the shell script or read it in plain-text from a file. From your description of storing the password in a separate file, I'm hoping that you might be writing a program in a compiled language. If so, you can do a little better.
If using a compiled language, you can encrypt the password in the file and decrypt within your program. The key for decryption would reside in the program itself so it couldn't be read easily. Besides this, I would
chmod 400 the file to prevent other users from reading it
add a dot prefix ('.') to the file to hide it from normal directory listing
rename the file to make it less interesting to read.
be careful not to store the key in a simple string -- the 'strings' command will print all printable strings from a unix executable image.
Having done these things, the next steps would be to improve the key management. But I wouldn't go this far until the 'ps' issue is cleared up. There's little sense putting the third deadbolt on the front door when you plan to leave the window open.
Don't fill the password buffer with zeros, this is pointless. The kernel can decide to swap it to an arbitrary location in the swap file or say after allocation of some memory the kernel will move the page tables around, resulting in other page tables containing the password while you only have access to the new copy.
You can prctl(2) with PR_SET_NAME to change the process name on the fly. Unfortunately I can't currently think of any other way than injecting some code into the running process via ptrace(2), which means enemy processes will race to read the process list before you get a chance to change the new processes name :/
Alternatively, you can grab the grsecurity kernel patches, and turn on CONFIG_GRKERNSEC_PROC_USER:
If you say Y here, non-root users will
only be able to view their own
processes, and restricts them from
viewing network-related information,
and viewing kernel symbol and module
information.
This will stop ps from being able to view the running command, as ps reads from /proc/<pid>/cmdline
Said interface requires us to pass a
plain-text password over a command
line to connect to the database. This
is a terrible security practice, but
we are stuck with it.
It's only a bad security practice because of problems in the O/S architecture. Would you expect other users to be able to intercept your syscalls? I wouldn't blame a developer who fell into this trap.
In our administration team everyone has root passwords for all client servers.
But what should we do if one of the team members is not longer working with us?
He still has our passwords and we have to change them all, every time someone leave us.
Now we are using ssh keys instead of passwords, but this is not helpful if we have to use something other than ssh.
The systems I run have a sudo-only policy. i.e., the root password is * (disabled), and people have to use sudo to get root access. You can then edit your sudoers file to grant/revoke people's access. It's very granular, and has lots of configurability---but has sensible defaults, so it won't take you long to set up.
I would normally suggest the following:
Use a blank root password.
Disable telnet
Set ssh for no-root-login (or root login by public key only)
Disable su to root by adding this to the top of /etc/suauth: 'root:ALL:DENY'
Enable secure tty for root login on console only (tty1-tty8)
Use sudo for normal root access
Now then, with this setting, all users must use sudo for remote admin,
but when the system is seriously messed up, there is no hunting for
the root password to unlock the console.
EDIT: other system administration tools that provide their own logins will also need adjusting.
While it is a good idea to use a sudo only policy like Chris suggested depending on the the size of your system an ldap approach may also be helpful. We complement that by a file that contains all the root passwords but the root passwords are really long and unmemorable. While that may be considered a security flaw it allows us to still log in if the ldap server is down.
Aside from the sudo policy, which is probably better, there is no reason why each admin couldn't have their own account with UID 0, but named differently, with a different password and even different home directory. Just remove their account when they're gone.
We just made it really easy to change the root passwords on every machine we admininster so when people left we just ran the script. I know not very savvy but it worked. Before my time, everyone in the company had access to root on all server. luckily we moved away from that.
Generally speaking, if someone leaves our team, we don't bother changing root passwords. Either they left the company (and have no way to access the machines anymore as their VPN has been revoked, as has their badge access to the building, and their wireless access to the network), or they're in another department inside the company and have the professionalism to not screw with our environment.
Is it a security hole? Maybe. But, really, if they wanted to screw with our environment, they would have done so prior to moving on.
So far, anyone leaving the team who wants to gain access to our machines again has always asked permission, even though they could get on without the permission. I don't see any reason to impede our ability to get work done, i.e., no reason to believe anyone else moving onwards and upwards would do differently.
Reasonably strong root password. Different on each box. No remote root logins, and no passwords for logins, only keys.
If you have ssh access via your certificates, can't you log in via ssh and change the root password via passwd or sudo passwd when you need to do something else that requires the password?
We use the sudo only policy where I work, but root passwords are still kept. The root passwords are only available to a select few employees. We have a program called Password Manager Pro that stores all of our passwords, and can provide password audits as well. This allows us to go back and see what passwords have been accessed by which users. Thus, we're able to only change the passwords that actually need to be changed.
SSH keys have no real alternative.
For management of many authorized_keys files on many servers you have to implement your own solution, if you do not want the same file on every server. Either via an own tool, or with some configuration management solution like puppet, ansible or something like that.
Else a for loop in bash or some clush action will suffice.
Anything besides SSH logins:
For services you run that are login-based, use some sort of authentication with a central backend. Keep in mind that noone will do any work if this backend is unavailable!
Run the service clustered.
Don't do hacks with a super-duper-service backdoor account, to always have access in case something breaks (like admin access is broken due to a misconfiguration). No matter how much you monitor access or configuration changes affecting this account, this is 'just bad'(TM).
Instead of getting this backdoor right, you might as well just cluster the application, or at the very least have a spare system periodically mirroring the setup at hand if the main box dies, which then can be activated easily through routing changes in the network. If this sounds too complicated, your business is either too small and you can live with half a day to two days downtime. Or you really hate clusters due to lacking knowledge and are just saving on the wrong things.
In general: If you do use software unusable with some sort of Active Directory or LDAP integration you have to jump the shark and change passwords for these manually.
Also a dedicated password management database that can only be accessed by a very selected few directly, and is read-only to all the others, is very nice. Don't bother with excel files, these lack proper rights management. Working with version control on .csv files doesn't really cut it either after a certain treshold.