I'm gonna go over Pass, and GPG. I like this better than, say, Google's password manager because I don't want my passwords on the web (I'm not fan of closed-source software, but probably Google's password manager is otherwise fine). And also, rather than using something like KeePass (a GUI-based application) (which is both offline, and FOSS (I think), so I have deference for it), something lightweight like `pass` is pretty easy to transfer around to other devices, if I want - and I do.
Anyways, some things are worth learning. It's worth learning how to cut with a chef's knife, kind of annoying at first, but anything that isn't 'a little annoying at first' to learn is probably not really a skill. It's worth learning to do algebra. It's worth learning to use Vim. It's worth learning how to encrypt and decrypt a file - because in the Unix-like philosophy, everything is a file - passwords, documents, pictures, anything. In fact, with `pass` you don't even need to know how to encrypt or decrypt a file! It's stupid easy. But I still like to understand things, and then explain them poorly. And I think `pass` is a great demonstration of (A) 'everything is a file', (B) how encryption works, (C) integrating command line utilities with normal computing life (without looking like a dinosaur), and (D) the utility of git/syncthing/etc. It's a great example of my Mario Linux analogy - any dummy can use pass, but there is A LOT of room for extensibility and customization with it too. First, an explanation you don't need (but it helps if you migrate your `pass` to multiple devices).
There's this Computerphile video, 'Public Key Cryptography', and you should watch it. I'm going to briefly summarize.
Maybe it's anecdotal, but either way, the spy story is pretty helpful here to understanding the issue. Say that there are two spies, and they have a connection over the internet. How can they make sure that (A) when one receives a message from the other, that it is really the other and (B) that no one else can snoop on their messages? To tackle this, we have 'public key cryptography'.
A naive first attempt might be that both of you agree on a key which encrypts a message, and which can then de-crypt that message. But how do you both agree on the key over the clearnet (ie an unencrypted connection), without the rest of the world knowing? You have a circular problem here - to get an encrypted connection, you need to agree on a key, but without an encrypted connection to begin with, you can't safely share a key without exposing the key to the world.
To address this, we use public/private key pairs. Your public key is shared and known by everyone, and is capable of encrypting messages, and also decrypting messages that were encrypted by its complementary private key. Your private key is secret and unshared, and it can encrypt mssages also, and can decrypt messages that were encrypted by its complementary public key. So basically, some encrypted by X can be decrypted by Y, and vice versa - and X is public knowledge, and Y is a secret (protected by a passphrase).
This allows for two kinds of functionality - First, person A can encrypt a message with person B's public key. In this case, the only person who can decrypt that message is person B, since they are the only one with their private key (the key that can decrypt their public key). Second, person A can also encrypt the message with their own (person A's) private key. Obviously this isn't to 'hide' the contents of the message, because anyone can decrypt the private key's encryption with Person A's public key. However, it does validate that person A actually sent the message. If anyone tampers with Person A's message along the way, then the message is no longer encrypted by person A's private key. So then you know Person A isn't the last person to the touch the message - it's been tampered with.
So this combination allows you to both make sure only the inteneded recipient can decrypt the message (since you encrypted with their public key, so only their private key can decrypt), and makes sure the receiver knows that you are the actual person who sent it, as it was encrypted with your private key (they can verify this by decrypting it with your public key - if it doesn't work, then your private key didn't encrypt it, and there was tampering).
So coming back to GPG, GPG is basically this, for all intents and purposes. According to the man page, it's 'the openPGP part of the GNU Privacy Guard (GnuPG). It is a tool to provide digital encryption and signing services using the OpenPGP standard. gpg features complete key management and all the bells and whistles you would expect form a full OpenPGP implementation. So a GPG key pair is basically all of the above.
Now this is basically a rundown of how to encrypt things over the web, one of the most robust ways to do so. Buuuut it can also be used in other settings. For example, you can easily encrypt files which only you can decrypt... maybe sensitive documents, such as a file with a password in it!
Now that we understand that, we can get to pass. According to the man page, it 'is a very simple password store that keeps passwords inside gpg2 encrypted files inside a simple directory tree residing at ~/.password-store. The pass utility provides a series of commands for manipulating the password store, allowing the user to add, remove, edit, synchronize, generate, and manipulate passwords.' That's right, pass can just generate nice passwords for you. Half my passwords, I don't know if they've ever seen the light of day. This isn't actually the most wild thing - any password manager will generate passwords for you if you want, but it's always cool lol.
So after you initialize the password store, you add a password by typing `pass add ebay` (for eBay, for example), then enter the password - it will then create a file with that information that is encrypted with your public key; only your private key can unlock it then. To access the passwords, you type in the command line `pass X`, where X is the account you want a password for (eBay, for example). To access this password, it has to be unlocked by your private key, so you have to enter the passphrase for your private key to show you are truly you. Once you enter that, boom, it gives you the password (it actually just copies it to your clipboard for 45 seconds).
It comes with a nice tool called `passmenu`, that allows you to type `passmenu` and it brings a dmenu instance with all of your accounts to choose from. So then you can just fuzzy search for the account you want, and get it copied to your clip board. Now I use i3, and so I went into the i3 config file, and entered a hotkey (super+Y) which runs the command `passmenu` when I press the key combo. So if I'm at the eBay website, and it asks for my password, I can just press `Super+Y`, type 'eBay', enter my private key passphrase (one of maybe three passwords I actually need to remember - the other being my email account, the other being my login/admin password for my computer), and boom, the password for eBay is copied to my clipboard. So then I just paste into the password query, and boom, I'm in.
Now if you want to use your password store on another device (say an Android phone - for iPhone users idk), you just need to (A) get the `~/.password-store` directory onto that device, (2) export the GPG key-pair, and (3) get software that can utilize these. Off the F-Droid store, I got the 'Password Store' app, and then I did the caveman thing, and just copied the `~/.password-store` directory to my phone over a USB cable. The 'Password Store' app will recognize these, but it can't handle the GPG stuff by itself. For this, go to the F-Droid store, and download the 'OpenKey chain' app. Then I exported my GPG keys into key files, and copied those over. Open them with 'OpenKey chain' (there are more precise guides in the 'Password Store' and 'OpenKey chain' github wikis), do a bit of setting up (follow the wikis), and boom. You should be able to select an account in 'Password Store', and it will, through 'OpenKey chain', ask for the passphrase for your private key! It will then briefly decrypt the password and put it on your clipboard for 45 seconds. Very handy!
I was too lazy, and did it the cave man way, but I'm gonna set it up soon with the Git way. The git way is nice because if I add a password on one account, I want to keep the repositories in sync. `Pass` can handle git very easy (because it just references a directory with files in it), and so this is the real move to keep everything in sync.
It's also possible you could use syncthing. Actually, I might try that out. I don't see why it wouldn't work... Although that could be a bit more volatile than git.