UX: Missing option for noninteractive use of passwords #256
Replies: 22 comments 4 replies
-
|
Can you explain a bit more about how you are trying to use the PW w/ As an aside, I know the dev is working to expose an |
Beta Was this translation helpful? Give feedback.
-
|
@cyb3rz3us OP is trying to pass passwords as an argument (or having |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @Fastidious --- I'm aware of what |
Beta Was this translation helpful? Give feedback.
-
|
@cyb3rz3us that will require a third party tool, like |
Beta Was this translation helpful? Give feedback.
-
|
"...would use public key to encrypt instead..." --- Indeed. Hence my query... |
Beta Was this translation helpful? Give feedback.
-
|
The scenario in which I am opting to use age does not allow to store something like keyfiles for each user. Additionally there is one requirement where new users need to get access to previously encrypted files, which is easy when using a shared password. In an additional use case, data is encrypted for long term storage (decades) and one of the requirements that were set for this is symmetric crypto, as it is deemed more reliable in the long run. At the moment the implementation for all of this is planned with a custom encryption file format, but I would like to prefer age if possible to make it easier to access the data in the future and to help age become a standard. Also I do not see much reason to design and implement yet another format if age is already available for this. If #63 provides an API that allows this use case, that is exactly what I am looking for. |
Beta Was this translation helpful? Give feedback.
-
The Go API does indeed allow encrypting files under programmatically provided passphrases! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @x97x53x81 --- So just considering this at a high-level, I can say it is definitely possible to use something simple like a Tcl\Expect script to collect the requisite password information and then pass it to If the API ends up working for you, then of course all the better. But if you need something in the interim, then technically speaking, I don't really see an issue making this work with |
Beta Was this translation helpful? Give feedback.
-
|
Passphrases are somewhat disincentivized in the CLI (but you can use them noninteractively though the API) because they are generally hard to pick securely for humans. In fact, maybe letting users specify passphrases at all rather than generating random ones was a mistake. Not supporting noninteractive use is part of that, and an early design decision: passphrases are for interactive use, key files should be used for the rest. I am not certain that's a position we can hold forever, but custom applications that generate files for people to decrypt with a passphrase for example can use the API. |
Beta Was this translation helpful? Give feedback.
-
|
There are currently 3 threads asking for similar things (#256, #257, #275), so there clearly seems to be demand for this capability. If there's going to be support for passphrases anyway, they might as well address the use cases people want them for. For the CLI, it would be trivial to modify Here's what I'm using until some comparable functionality is added: |
Beta Was this translation helpful? Give feedback.
-
|
Another use-case (that I intend to implement for myself, but currently I'm blocked by this issue) is using Currently I have a custom Thus replacing There is no other workaround here, Moreover, given that in such a use-case |
Beta Was this translation helpful? Give feedback.
-
|
Hai~, I just wanna say that Instead of the simple following (an example of how a password can be supplied non-interactively) # ssh keys
cd ~/.ssh
tar -c ${sshKeys[*]} | age --encrypt --passphrase --armor --passphrase-fd "$fd" | sudo tee "/mnt/ssh-keys.tar.age"
# gpg keys
# ...I've had to use # ssh keys
exec 4> >(sudo tee "/mnt/ssh-keys.tar.age" >/dev/null)
if expect -f <(cat <<-EOF
set bashFd [lindex \$argv 0]
spawn bash \$bashFd
expect -- "Enter passphrase*"
send -- "$password\n"
expect -- "Confirm passphrase*"
send -- "$password\n"
expect eof
set result [wait]
if {[lindex \$result 2] == 0} {
exit [lindex \$result 3]
} else {
error "An operating system error occurred, errno=[lindex \$result 3]"
}
EOF
) <(cat <<-EOF
set -eo pipefail
cd ~/.ssh
tar -c ${sshKeys[*]} | age --encrypt --passphrase --armor >&4
EOF
); then :; else
util.die "Command 'expect' failed (code $?)"
fi
exec 4<&-
# gpg keys
# ...Not pretty code :( In my case, I am copying sensitive data (ssh keys, gpg keys) to a USB drive to be copied to a different computer. I can't use LUKS since not all operating systems support that, so I'm just encrypting the data with a password. I am doing this for my gpg and ssh keys separately, so I'm scripting so I don't need to enter my password four times - just once It was mentioned here that a "passphrase-encrypted identity file" would be an alternative for scripting passphrases. It was only after creating the workaround solution did I find this, and I think I see how I could have used it. For me personally, I sort of skimmed over this part, since it wasn't obvious to me how I could have originally used passphrase-encrypted identity files; not only that, but I'm less comfortable using identity files since it's a bit less clear to me / requires actual thought on how they guarantee or help guarantee data properties like encryption, etc. in various contexts like this one If passphrase-encrypted identity files really do solve this use case (without the need for Expect, etc.), then maybe its just my fault that I didn't understand cryptography well enough. I chose age over gpg and friends because I didn't want to worry about accidentally "doing it wrong". Either way, I think it would be good to document that passphrase-encrypted identity files solves some issues with scripting passphrases. And/or, make it clear that I originally posed this in #256, but it seems this feature is already being discussed in here, so I moved it. Maybe the other discussions should be considered duplicates and should be merged/archived? |
Beta Was this translation helpful? Give feedback.
-
|
Shame this is missing & one of the reasons I switched back to PGP in a CI workflow I'm building. I have an environment file with secrets that I wanted to encrypt and to commit it into the git repo. I could work around the above by downloading a non-pass-phrased private key and placing it on the CI machine but that involves a more complex build step and also being sensitive to exposing the private key etc. The other approach with a pass-phrased private key which could then be committed into the repo feels like jumping through hoops as the private key would be along side the encrypted content, with only the passphrase for the private key being injected into the CI. So it's the same approach as using I'd love to use age but I feel the extra workarounds are forcing me back to PGP |
Beta Was this translation helpful? Give feedback.
-
|
It is a pity that this feature is obviously considered useful by many users, but there is no further development in this direction yet. |
Beta Was this translation helpful? Give feedback.
-
|
I can only agree. |
Beta Was this translation helpful? Give feedback.
-
|
As I've commended on #257, in the end, I think a dangerous trend will appear, namely more projects that allow one to generate ECDSA private keys from "passwords", and feed those into age, like for example https://github.com/keisentraut/age-keygen-deterministic. (I have partially duplicated my comment here, because I think that |
Beta Was this translation helpful? Give feedback.
-
|
Hey all, just wanted to mention that I am hearing the feedback, and I do have a plan. Currently @str4d and I are focusing on shipping plugin support in age and rage. Once that's ready, I am going to provide an age-plugin-pass in the same spirit as sshpass. That has two advantages: first, it will keep non-interactive password use disincentivized, nudging users towards key files, and giving us a place to document the security rationale and the alternative workflows; second, it can absorb the myriad of different ways people will want to provide a passphrase (environment variable #346, file or file descriptor #257, stdin #257 (comment), command #256 (comment), pinentry #386) without polluting the age CLI. Let me know if this wouldn't work for you or if I'm missing useful input methods. |
Beta Was this translation helpful? Give feedback.
-
|
Just having read the plugin spec, the plugin doesn't seem to have much options to accept input from the user or did I miss something? The interactive interface provided by the plugin protocol is obviously not what's wanted there. Live encoding options into the Bech32 identity/recipient is also not what you want to do. So the only convenient option seems to be env vars, right? For me this would work but |
Beta Was this translation helpful? Give feedback.
-
|
Linking in my use case at #257 (reply in thread) and the discussion I had opened today: #445 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
And re-linking from there the commit which makes me happy enough for this functionality: Gratis à @jjlin for the commit beneath this! 🖖 🎩 |
Beta Was this translation helpful? Give feedback.
-
|
Just a note that for solutions like https://github.com/anticomputer/age.el (emacs support for age) having a default pinentry mechanism makes life a lot more straightforward versus trying to juggle /dev/tty interactions for passphrases from Emacs. By default, I'd like folks to just depend on the age cmd that is available with their package manager and nothing else. Specifically I'd like to be able to support ssh key passphrases for ssh private keys via pinentry. I'll hack around it for now, but just FYI. For my personal setup I'll likely use https://github.com/str4d/age-plugin-yubikey as it provides all the primitives I need and it would compose nicely with age.el, but it'd be nice for folks to be able to plug and play the age cli for age.el with passphrase pinentry support as well. |
Beta Was this translation helpful? Give feedback.
-
|
hihi. thanks that this is still being considered. i have the following use case for this issue: |
Beta Was this translation helpful? Give feedback.
-
|
GitHub workflows are another use case for this. Decrypting large secrets with age would be awesome. |
Beta Was this translation helpful? Give feedback.
-
|
I need this too for the following: #572
|
Beta Was this translation helpful? Give feedback.
-
|
Cross-referencing related/duplicated discussion/PR topics:
|
Beta Was this translation helpful? Give feedback.
-
|
I'm primarily on Windows so I would be happy with either stdin support for password or, preferably, an environment variable. My preference would be a way to specify the environment variable name. https://ccrypt.sourceforge.net/ has a number of options:
As well as options to prompt once or twice. |
Beta Was this translation helpful? Give feedback.
-
What were you trying to do
Writing an application that uses age as a backend for encryption using passwords
The application uses passwords for various things and I would like the use age to encrypt data by using the preexisting passwords. Using public keys is not an option in this scenario.
What happened
Age only allows the use of passwords interactively, making it hard to use if (preexisting) passwords need to be used.
For age to become a global standard for encryption, it should consider use cases like this and allow to use of passwords without being used interactively.
Beta Was this translation helpful? Give feedback.
All reactions