UX: Missing option for noninteractive use of passwords

[x97x53x81]

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.

[cyb3rz3us]

Can you explain a bit more about how you are trying to use the PW w/ age and your app? I use age as is right now for encrypting a credentials file and while I do use public keys, I don't see much of a hurdle is using a password as well. However, how big that hurdle is will depend on what you are doing and the apps you employ.

As an aside, I know the dev is working to expose an age API library (#63) so perhaps that will provide what you need...

[Fastidious]

@cyb3rz3us OP is trying to pass passwords as an argument (or having age to read it from file, or similar), so it seems. Right now age does passwords only interactively.

[cyb3rz3us]

Thanks @Fastidious --- I'm aware of what age can do but having the PW acquired interactively is not that big a deal depending on what is being done. It's somewhat trivial to have an app peek into an existing file or take a CLI argument and then provide that to age when appropriate. This is why I asked for more details as to what is being done...

[Fastidious]

@cyb3rz3us that will require a third party tool, like expect or similar. I really don't see the need for what the OP asks. If I were it, I would use public key to encrypt instead. 🤷🏻‍♂️

[cyb3rz3us]

"...would use public key to encrypt instead..." --- Indeed. Hence my query...

[x97x53x81]

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.

[FiloSottile]

If #63 provides an API that allows this use case, that is exactly what I am looking for.

The Go API does indeed allow encrypting files under programmatically provided passphrases!

[cyb3rz3us]

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 age which would then hand over decrypted data to another app whatever it may be.

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 age as it is right now.

[FiloSottile]

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.

[jjlin]

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 passphrasePromptForEncryption() to use the value of an environment variable like AGE_PASSPHRASE if it exists. This wouldn't even require adding any new flags, and files can easily be read into env vars in most shells.

Here's what I'm using until some comparable functionality is added:

https://github.com/jjlin/age/blob/2afaf7fda78117f1e0b784a8c41f9dea15028316/cmd/age/age.go#L230-L233

[cipriancraciun]

Another use-case (that I intend to implement for myself, but currently I'm blocked by this issue) is using age to store the key for Linux's "raw" dm-crypt (full disk encryption, "raw" in the sense without using LUKS).

Currently I have a custom systemd unit that uses systemd-ask-password to obtain the password and pass that to gpgv something on the line of:

cryptsetup open [...] --key-file - "${_backing}" "${_target}" \
< <(
    "${_gpg}" [...] --passphrase-file /dev/fd/22 "${_key}" \
        22< <(
                systemd-ask-password --no-tty [...]
            )
    )

Thus replacing gpgv with age would require age having support for taking the password from a file (or pipe in this case, just like #275 suggests).

There is no other workaround here, age must be able to run non-interactively, as systemd runs services are not tied to a TTY, thus the requirement of using systemd-ask-password.

Moreover, given that in such a use-case age would run when the system is barely starting up, there are limited other options.

[hyperupcall]

Hai~,

I just wanna say that age is a fantastic tool, and it's a pleasure to use! I would like to chime in, though, and say that this feature would really be useful. Mainly, the README advertises UNIX-style composability, but I've had to forgo that (in the general sense) in this particular case due to this missing feature...

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 expect...

# 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 age doesn't support scripting as a first-class citizen and there are some things that it just won't support

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?

[leonsmith]

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.
This file needs to be decrypted by the CI runner and sourced before execution.

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 --passphrase directly but with the extra step/complexity of having a file on disk.

I'd love to use age but I feel the extra workarounds are forcing me back to PGP

[tribor]

It is a pity that this feature is obviously considered useful by many users, but there is no further development in this direction yet.

[gabyx]

I can only agree.

[cipriancraciun]

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 age-keygen-deterministic, might be a possible solution for those that really need to use age in a non-interactive manner. Is this a "good" solution? most likely no, but it's a pragmatic solution...)

[FiloSottile]

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.

[HW42]

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 AGE_PASS_FILE=/some/path/to/pw age -j password-via-env ... isn't quite the same as age --pass-file /some/path/to/pw (using file based input as example).

[n-hebert]

Linking in my use case at #257 (reply in thread) and the discussion I had opened today: #445 (comment)

[n-hebert]

And re-linking from there the commit which makes me happy enough for this functionality:
n-hebert@16ff95a

Gratis à @jjlin for the commit beneath this! 🖖 🎩

[anticomputer]

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.

[woddel]

hihi. thanks that this is still being considered. i have the following use case for this issue:
we are working on an intranet solution and users should be able to upload and crypt specific sensitive files (like management stuff). using a key file would require the key itself to be saved somehere. but we really would like to be 'key less', so even WE as the developers or a system administrator does not have possibility to decrypt the files. with key files, we would, as the keys would need to be stored somewhere and we or sys admins would potentially have access to them.
my routine currently uses openssl to encrypt, but i heard that this is kinda outdated. our application (written in coldfusion) can execute a command line to trigger the encrypt or decrypt (on download request into a temp directory, push to user and then delete), but it can NOT do so interactively. and i really would prefer to keep things simple and stupid without plugins and third party software like the mentioned 'expect' above.
i know that our concept has some flaws when going at it hard core (like we COULD save the password the user enters, the file is not encrypted at the time of upload etc), but the requirement is not for NSA grade stuff, but for easy usage by the user with limited computer experience (to do stuff like client side encryption before upload etc).
being able to provide the password directly within the initial command would REALLY really help... :)
i know you say 'disincentivize' the use of passwords (for whatever reasons), but please don't be like vegans who think that THEIR way of life is the ONLY way and everybody needs to adapt to their beliefs... :)
many thanks, lukas

[aaomidi]

GitHub workflows are another use case for this. Decrypting large secrets with age would be awesome.

[gabyx]

I need this too for the following: #572

echo "asd" | age -d secret.age or by any other non-interactive way.

[clach04]

Cross-referencing related/duplicated discussion/PR topics:

• UX: Make age take a passphrase from a non-terminal source #275 "UX: Make age take a passphrase from a non-terminal source"
  • Add --passphrase-fd option. #276 "Add --passphrase-fd option."
• Read passphrase from AGE_PASSPHRASE env var if available #346 "Read passphrase from AGE_PASSPHRASE env var if available"
• cmd/age: passphrase optionnaly supplied from an environment variable #520 "cmd/age: passphrase optionnaly supplied from an environment variable"

[clach04]

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:

• -E to specify the environment variable name
• -k to specify a file, where the first line contains the passphrase

As well as options to prompt once or twice.