proposal: use pipe instead of cmdline arg to pass $otp_secret to oathtool

[flosnvjx]

In current implementation (otp.bash#L360) of pass-otp, when generating pincodes, the implementation use a command line argument to pass the $otp_secret to external binary oathtool.

The problem with this approach is, in strictly managed environment, things like audit log is usually enabled (e.g. enabled for exec* syscall, which is quite common in enterprise server/thin-client environment), arguments to invoke external binary may written to syslogd, which is possibly stored in unencrypted form in terms of on-disk sectors and sudoers (privileged sysadmins). The manual of oathtool(1) also point out this:

oathtool [OPTIONS]... [KEY [OTP]]...

...KEY and OTP is the string '-' to read from standard input

'@file' to read from indicated filename, or a hex encoded value (not recommended on multi-user systems).

This also applies to some consumer-level single user runtime, like Termux on Android (things like logcat may get uploaded to OS vendor. Note that Termux also have pass-otp packaged in their repository). It should have fairly no drawback if switched to pipe appoarch instead.

[guijan]

Command line args are also visible via top, a program running under a different user could call the syscalls top uses to monitor other processes and watch for your key as a command line arg.

[pabs3]

I sent a fix for this issue in pull request #182.