I use pass too, but technically you just need gpg to do this exact same thing. pass, in this use case, is literally just a very thin wrapper to gpg + a file with your password in it.
I understand, but personally, if I'm already using the convenient wrapper that is pass for everything else, it simplifies my life to use it here too.
I could see going with less glue if there wasn't an expectation that pass be installed and configured on a system already. Those aren't my systems though. Either would work.
Oh yes, I'm not trying to convince you to change. I'm merely pointing out that this technique is not exclusive to pass, but rather that it's easily done without pass too. pass is an amazing tool!
I did something similar where you could send GitHubers encrypted messages only they could decrypt via their SSH public key that GitHub makes available: https://github.com/rockymadden/github-crypt
I've considered adding Github public key support to EnvKey[1]. Currently, when inviting a user, you need to send a token out of band in order to not trust our servers during the invite process. Using the Github public key could potentially eliminate this step.
My only concern is that these might have a tendency to get out of date or not be managed securely, in which case it could be more trouble than it's worth.
That's a cool idea. It would be neat to have some way of sending that to the githubber builtin to the tool. Maybe send an email to the githubber if they have an email published or maybe just post it to a gist that then you can send them the link to?
I love that idea! I think you could use the anonymous gist API. Have the tool output to stdout/pbcopy the gist URL that was created upon encrypt and similarly have it accept a gist URL to decrypt. Nothing to send on either side beyond the URL.
I understand the point you are trying to make, but a RSA key is a RSA key.
The only benefit of gpg here is for things longer than a password. The script is encrypting the password directly with the RSA key. The performance and security will be weaker on things much longer than a password.
Some of the vulnerable systems that have been attacked this way basically were built on the premise than an RSA key is an RSA key. But an RSA implementation that's secure for one purpose might not be secure for another purpose, for example with malleability.
I'm not sure I understand why you would re-use your default ssh public key rather than just generate a dedicated rsa key. Because this uses OpenSSL it won't work with an ssh keyring for passphrase or hardware token management, I'm not sure I understand what using a key in ~/.ssh brings to the table.
Since, by default ssh private and public keys get stored in the .ssh folder under the user's home folder, then it is convenient to leverage the already existing keys rather than having to generate new keys. (Of course you can also use different keys as well if you would like) You just include the script in your existing scripts you have and it works.
This is meant to be a simple solution to needing to store your password in plaintext within a shell script. For example, you might have shell scripts that you create for quick duties like downloading or uploading some asset from a server. Typically sysadmins or developers might just store this in plaintext. The problem is later on they may forget that they stored it in plaintext and the script gets passed around and now you have credentials leaking all over the place. Also, works well for crowded environments where shoulder surfers might be present
Leveraging that existing key is a downright anti-feature though. You should try to minimize the scope controlled by any given key.
You already lean heavily on OpenSSL, so it doesn't make a lot of sense why you wouldn't just generate a dedicated key with a `openssl genrsa -out .spiffytool/private.pem`
I think this is a good idea, b/c as long as the permissions are set on the generated private key to only be readable by the user, then the same level of security would be provided as accessing the user's private ssh key. It would also be nicer in situations like remote servers where the private key is not available due to security reasons. The intention was in these situations to generate your own keys using SSH, but there's no reason to make the user go through that exercise. I will look at making the change. Thanks for the suggestion.
It's not much different from Hashicorp Vault or Cyberark, etc.
Both are like locking your house key in a lock box that has a different key. PCI, Sarbanes Oxley, HIPPA, etc, created a whole new category of funny software.
But you can encrypt with Curve25519: E(public, M) = let (ephemeral_private, ephemeral_public) = gen_random_25519(): let shared_key = Curve25519(public, ephemeral_private): return ephemeral_public || E_AES256GCM(shared_key, M).
Works on both Windows and Linux but the passwords are stored online (GPG encrypted). The main idea was to be able to revoke a password if a machine has been compromised.
That's an interesting idea. Kind of a simpler HashiCorp Vault service offered as a SaaS. I guess you would also be competing somewhat with any cloud provider that offers secrets management, but they are probably going to be more expensive and not as focused on this use case. The closest thing I could find to this is https://secrethub.io/, but looks like they are in private beta still.
The only downside I can really see here is clients are dependent on remotepassword.com being secure. (which is inherent in any SaaS model) For example, if remotepassword.com was compromised then all passwords could be deleted rendering downstream scripts dependent on those secrets temporarily inoperable and of course someone could start logging the password inputs on the website.
This tool looks really easy to use. So easy that it's likely to be used by people who aren't very security-savvy. Of course it would be overkill to try to educate everybody about everything, but I think it would be prudent for the README to mention the risk of passwords showing up in ps output.
I see, so basically if you invoke another process from within the script you are using the decrypted password AND you pass the decrypted password to that process, then it would be visible to ps. That makes sense as you are passing the decrypted password as an argument to the other process. This is similar to doing something like...
echo "password" | whatever.sh
To prevent this from happening the other process should just source encpass.sh directly. I think it is probably worth mentioning this in the README as I could see someone doing that inadvertently. Thanks for the example.
Yes, that's true. It would show up in your command history though. Even though it's probably not readable by anyone else except root, it's still probably not a good idea to have it persisted to disk.
Yeah, I was just giving an example of passing it into a script. Similarly, if encpass.sh is included in whatever.sh script the password won't show up in ps.
Is secret-tool a linux only program? Where is the source for it maintained? (I was having trouble finding it) Do you use this as your main password manager too? Any thoughts on how this compares to pass?
In response to myself, it looks like this is a gnome project and the source can be found here -> https://git.gnome.org/browse/libsecret/tree/tool. So I guess it can be used anywhere that gnome is supported.
pass show whatever-key | password-hungry-command -
[0] - https://www.passwordstore.org/