I have been using gpg for encryption for a while. Someone suggested that I should use gpg2 instead. When I went to use gpg2, I could do almost nothing; it would complain that access to private keys was required, but I could not seem to get it to use the private keys without gpg-agent running.
It turns out that I intentionally disabled gpg-agent (by using chmod -x /usr/bin/gpg-agent); this caused gpg2 to have very limited functionality and complain to stderr.
The reasons I disabled gpg-agent was following a chain of events.
First, I would SSH into a remote machine and "an agent" would open a popup asking for me to unlock my SSH keys. I did not like this because:
A pop-up on my screen interrupts my workflow
A pop-up on my screen is unlikely to be noticed, so it would appear instead that the connection is stalling instead of querying to unlock an encryption key
The agent appeared to cache my password when I absolutely do not want my password cached (much like sudo's annoying use of password caching, I can disable that in its config); I will always want to enter the passphrase for my encryption keys every time they are used for whatever program is using them.
The pop-up appeared to be owned by a separate process, while I want the specific process using the key to query for the passphrase (even if it's a library that does the actual querying); since I spend most of my activities using command-line tools, that means a GUI application isn't ideal because not everything I do will have access to X11
Automatically starting a separate process in the background removes the concept of "one command, one process", especially if that backgrounded process then lingers after the original command has exited
It turned out to be GNOME's key agent and that I could not uninstall the agent without uninstalling GNOME. So I simply disabled it by chmod -x /usr/bin/gnome-keyring*. I then found that SSH would fall back to another agent so I disabled that too using the same method chmod -x /usr/bin/ssh-agent*
When I started using gpg, I found it had a similar agent, the same one I am asking about. I disabled it immediately for the same reasons; I want software to always ask me for passphrases in order to use a private key. I do not want the passphrase to be cached for any reason whatsoever.
So with gpg2 appearing to require gpg-agent, I would like to ask:
Am I being overly paranoid about the use of passphrase caching? I would be curious to see or be pointed to a discussion of it.
Is there a best practice that enables a better way to avoid even accidentally enabling the use of a cached passphrase?
Is there a way to use gpg2 without gpg-agent ever running?
Given that agents are daemons which are expected to be able to answer queries, what prevents another user or service running on the local machine from being able to access my cached or stored credentials?
Am I being overly paranoid about the use of passphrase caching? I would be curious to see or be pointed to a discussion of it.
Your concerns are certainly valid IMO. The good news is that there are ways to customize gpg-agent behaviour to suit your needs. For example, use a terminal-based passphrase prompt (PIN entry) instead of a GUI prompt and do not cache passphrases.
Is there a best practice that enables a better way to avoid even accidentally enabling the use of a cached passphrase?
A quick solution, likely not a best practice, is to customize your ~/.gnupg/gpg-agent.conf with the following options:
# Expire cached PINs (passphrases) after zero seconds
default-cache-ttl 0
max-cache-ttl 0
# If you use your GPG keys for SSH auth...
default-cache-ttl-ssh 0
max-cache-ttl-ssh 0
enable-ssh-support
# Use TTY-based PIN entry program (I see pinentry,
# pinentry-curses, pinentry-gnome3, pinentry-tty and
# pinentry-x11 on my system)
pinentry-program /usr/bin/pinentry-tty
I found the following guides on GPG key best practices (more of a general guide around key management, not exactly what you're asking) fairly informative and easy to follow:
https://alexcabal.com/creating-the-perfect-gpg-keypair/
https://riseup.net/en/security/message-security/openpgp/best-practices (somewhat dated, some sections don't work out of the box with latest gpg 2.x versions)
Is there a way to use gpg2 without gpg-agent ever running?
Not with gpg 2.x as far as I am aware of. The man page states the following:
--use-agent
--no-use-agent
This is dummy option. gpg always requires the agent.
I have gpg 2.1.15.
Given that agents are daemons which are expected to be able to answer queries, what prevents another user or service running on the local machine from being able to access my cached or stored credentials?
Good question... By default, gpg-agent uses a socket, so technically any process running as your user could in theory hijack your keys. Don't quote me on this, though. Here's an overview of how the gpg-agent works that will hopefully get you started on finding out the real answer:
https://unix.stackexchange.com/questions/188668/how-does-gpg-agent-work
According to https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase in order to provide password directly to gpg - without gpg-agent running - you need to run with following options:
gpg --passphrase-fd 0 --pinentry-mode loopback ...
You need to provide password in console right after running this command. No password prompt will be visible during typing, but you will see typed password.
To hide password while typing you can wrap command in stty:
stty -echo ; gpg ... ; stty echo
I tested this with GnuPG v. 2.2.4: killed gpg-agent, shredded /usr/bin/gpg-agent, then run as described above. Worked well.
Related
I'm using git with GnuPG signing. Each time I want to sign a commit I have to provide my GnuPG key password.
Is it possible to make git take advantage of some system-wide keyring, like gnome-keyring? I can't seem to find any documentation on that, or even any thread on this in the web. Perhaps there is some solution I'm not aware of, that is not popular enough to be easy to google.
There are probably some GUI tools that can do that for me, but I'm not interested in those, I mostly use git from console, sometimes from IntelliJ-based IDEs, which just invoke the system git binary. Having a system-side solution will allow me to use git config --global commit.gpgsign true with these IDEs (and cli).
Copied from https://superuser.com/questions/624343/keep-gnupg-credentials-cached-for-entire-user-session
Up to GnuPG 2
The user configuration (in ~/.gnupg/gpg-agent.conf) can only define
the default and maximum caching duration; it can't be disabled.
The default-cache-ttl option sets the timeout (in seconds) after the
last GnuPG activity (so it resets if you use it), the
maximum-cache-ttl option set the timespan (in seconds) it caches
after entering your password. The default value is 7200 (2 hours) for
both.
Set it to a year or so – say, 34560000 seconds (400 days) – and you
should be fine:
default-cache-ttl 34560000
maximum-cache-ttl 34560000
But for this change to take effect, you need to end the session by
restarting gpg-agent.
If you want to limit to your session length, you'd need to kill the
daemon at logout. This is very different between operating systems, so
I'm referring to another question/answer containing hints for
different
systems.
You could also restart the gpg-agent during login, but this does not
limit caching time to the session length, but logins of a user. Decide
yourself if this is a problem in your case.
GnuPG 2.1 and above
In GnuPG 2.1 and above, the maximum-cache-ttl option was renamed to
max-cache-ttl without further changes.
I see you use Fedora, in version 29, all I had to do was:
git config --global gpg.program gpg2
And it uses the Gnome Keychain (seahorse).
I've a fingerprint reader on my laptop and I installed fprintd to connect using it.
That works very well but there is this problem : When I remote connect to my laptop then I do a su/sudo command, I'm asking to swipe my finger. It works if I'm near the computer... but I'd prefer to disable it for cases I'm distant. Is there a way to do that ?
There is a bug filed for that in ubuntu which does not seem to have been resolved yet. That suggest there is no native way in fprint to do that. The workaround suggested by one user in there is to wait for the timeout.
From what I see pam can be configured in a certain way to fall back to password in case no print can be read by fprint. Archwiki says
auth sufficient pam_fprintd.so
auth include system-login
in /etc/pam.d/system-local-login not sure if that applies for your system too (for good measure here is someone configuring it in gentoo).So you should be able to allow pam to fall back on password with the right configuration.
I want to reiterate my comment for users that still don't know: Fingerprints (or biometrics in general) are not secure means of authentication (as the simpelest of the many flaws: you leave them all over your computer when you touch it).
There is a workaround:
Start two remote sessions.
On the first one, perform a sudo pwd. This will fire the fingerprint.
On the second, perform your desired command: sudo apt-get upgrade(or whatever). Since the fingerprint is blocked by the first session, it will skip directly to password authentication. No timeout.
Due to some reason, I have to use "setsid" to run all of my commands.
But, when running "setsid scp ~/aaa user1#10.170.3.17:/tmp/", a dialog box requesting for password arose.
Normally, the prompt arises in command line.
Does it caused by some configuration in ssh?
I want to eliminate the box. How to achieve it?
One of the effects of the setsid command is that process that is started via setsid(1) is detached from it's controlling terminal. Without controlling terminal, scp cannot ask for the password on the terminal from which it was started simply because it does not "see" any. However, what it does "see" is the environment variable telling it that there is an X11 window session where it can show a graphical utility to ask you for the password or passphrase needed to unlock the private SSH key which will be used to authenticate to the remote system.
Even if you would unset the environment variable that it "sees" and uses it to route the x11-ssh-askpass dialogue to your screen (DISPLAY), that would probably not produce the desired effect for you, since required key would be missing and scp operation would fail.
One of solutions that I would recommend here would be setting up a "passwordless" login (if applicable in given security circumstances), using ssh-keygen(1) to produce "identity keys" that will not be password-protected.
You might explore other possibilities, for example providing passphrase in a file or on command line option, whatever works better for you. Please have a look in the ENVIRONMENT section of ssh(1) manpage.
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.
How do I ensure that a username/password combination is not read from memory while my application is in use.
My program is a GUI wrapper for some CYGWIN tools, including SSH and SCP. I need to ensure single sign-on capabilities to a variety of hosts.
An attacker will try to obtain passwords from memory using a Debugger while the application is running. The use of any encryption can be bypassed because the password must be in plain text at the time of use. Any time memory is used it can also be observed with a debugger.
The answer lies in anti-debugging:
http://www.codeproject.com/KB/security/Intro_To_Win_Anti_Debug.aspx
More advanced windows Anti-Debugging:
http://www.veracode.com/blog/2008/12/anti-debugging-series-part-i/
http://www.veracode.com/blog/2008/12/anti-debugging-series-part-ii/
http://www.veracode.com/blog/2009/01/anti-debugging-series-part-iii/
http://www.veracode.com/blog/2009/02/anti-debugging-series-part-iv/
With the SSH key pair using ssh-agent, but is there any other way?
The problem is that you need to get the public key out to the remote host, which can be done in a simple string but still requires a login. So the initial setup of the key pairs with passphrase and the adding of the key to the remote host requires many passwords to be entered.
After the initial setup it all works well.
ideas?
Use a public/private key pair with authorized_keys.