Password echoing to terminal? How can I set password securely?

[dbarnett]

Seems like the password is always echoed in plaintext to the terminal when you run transcrypt to initialize. Is that intentional and secure?

For example:

$ yadm transcrypt
Encrypt using which cipher? [aes-256-cbc] 
Generate a random password? [Y/n] 
Password: correct horse battery staple

Repository metadata:

  GIT_WORK_TREE:  /home/dbarnett
  GIT_DIR:        /home/dbarnett/.local/share/yadm/repo.git
  GIT_ATTRIBUTES: /home/dbarnett/.gitattributes

The following configuration will be saved:

  CONTEXT:  default
  CIPHER:   aes-256-cbc
  PASSWORD: correct horse battery staple

I'm used to password-related commands turning off echo and never echoing the plaintext password to the screen.

[jmurty]

Hi @dbarnett that's a good question. I don't see a security risk here serious enough to change the current behaviour, though I could possibly be convinced otherwise.

The way I think about it, the reason to turn off echo – or output * characters instead of the real ones etc – is to prevent anyone snooping on your password over your shoulder as you enter it. Normally entering passwords is a risk because you must type it to authenticate against a password you provided earlier, and you need to enter the password each time you access a resource (or at least somewhat frequently). With transcrypt you only enter the password once at init time, and never again, so the number of risks taken is lower.

I agree that echoing back the typed characters is riskier than not doing so, but I also think the worse usability traded-off by hiding the typed characters would be worse than the risk of showing them.

The failure cases of an incorrectly typed password are:

• first time for a repo, the password set would not match the intended password. This error wouldn't be discovered until someone else tried to decrypt files in a shared version of the repo, or the original user thought to run transcrypt --display to double-check (at which point the password is printed to the terminal). Worst case, if the original encrypted repo is somehow lost before the error is discovered, the encrypted file data is also lost for good because the intended password won't decrypt the files
• second and later times for a repo (after secret files are pushed) the entered password would be wrong but transcrypt won't tell you this, it will just decrypt gibberish into the files. The user would need to notice this, then contact the person who originally encrypted the files to get the correct password from them. After being surprised at their mistake, the original person would need to run transcrypt --display to find out the real mistyped password they set (at which point the password is again printed to the terminal).

These failure cases could happen with the echoed plaintext passwords as well, but are much less likely.

The situation where hiding typed password characters would make complete sense is if you use a password manager of some kind to store the password, and can therefor copy/paste the password into the terminal without any chance of mistyping it. In this case, echoing the password is an unnecessary risk for no real usability gain.

So I can see the case for turning off echo for passwords, in at least some cases, but I don't think it would be a good idea to turn it off by default. Perhaps it could be controlled with an optional argument, or an extra choice during the manual init steps?

What do you think?

[dbarnett]

I'm sure that's fine, I guarantee you understand the security implications better than I do, it just startled me seeing my password echoed to the screen as I started typing it because most similar utilities don't work that way. The biggest thing that would have helped me us actually if the README had a note "Why is my password echoed to the terminal? It's safe, don't worry (citation)".

Options to override that would probably be useful but I just worried it would make it easier to sniff in userspace somehow and thought maybe I'd completely misunderstood how much security I could rely on transcrypt's encryption providing.