4 ms·

If you use stdin, won't most users just pass their password to echo? read -s might be a safer way.

by dharmab 6y ago

kitotik 6y ago
An envvar with a fallback of read -s might be the best compromise?
- R0b0t1 6y ago
  These can be recorded also, the best way is likely a password/key file.
  - forty 6y ago
    Tip: if you prefix your command by a space in bash (and maybe other shells) that command doesn't get recorded in history.
    - visualphoenix 6y ago
      Don’t go doing this and expecting it’s the default behavior. It’s not. Your bash session must have set, at minimum: HISTCONTROL=“ignorespace”
    - R0b0t1 6y ago
      Issue is /proc/$pid/environ if enabled. Envvars are visible just like args. I think there are other ways to recover if on same uid.
bigiain 6y ago
If they're gonna work around your "no password via argv" security design, it might be a reasonable thing to jst let them. Anyone who goes: hide add -n account -u user -p password123 And gets an error message saying "Sorry, you can't put the password into the command,it's a security problem in things like bash_history. Please use STDIN" Then goes "Fuckit!": echo 'password123' > hide add -n account -u user -p Maybe they should be allowed to do that? (I can almost imagine scenarios where someone might want to use a tool like this in some server automation thing where the security tradesoffs really do make using it like that a not awful idea?)
woodruffw 6y ago
This is a good point, and I should have been more precise in my original comment :-) If the program is on a TTY, then reading with echo disabled (i.e., `read -s`) is definitely preferable. I usually have stdin configured as a fallback for when the program isn't on a TTY, for programmatic use. This has the `echo` problem that you mentioned, but it's strictly better than either argv or the environment (both of which persist throughout the program's lifetime and appear in places like procfs).
- dharmab 6y ago
  For programmatic use a file or system keychain is safer than stdin.
  - woodruffw 6y ago
    Agreed re: the file. For the system keychain, I think we're talking about different use cases, no? The system keychain should be used to store the master password, but using it to pre-store any password you intend to later store in another password manager feels a little silly.

If you use stdin, won't most users just pass their password to echo? read -s might be a safer way.

kitotik 6y ago

An envvar with a fallback of read -s might be the best compromise?

R0b0t1 6y ago
These can be recorded also, the best way is likely a password/key file.
- forty 6y ago
  Tip: if you prefix your command by a space in bash (and maybe other shells) that command doesn't get recorded in history.
  - visualphoenix 6y ago
    Don’t go doing this and expecting it’s the default behavior. It’s not. Your bash session must have set, at minimum: HISTCONTROL=“ignorespace”
  - R0b0t1 6y ago
    Issue is /proc/$pid/environ if enabled. Envvars are visible just like args. I think there are other ways to recover if on same uid.

bigiain 6y ago

If they're gonna work around your "no password via argv" security design, it might be a reasonable thing to jst let them. Anyone who goes: hide add -n account -u user -p password123 And gets an error message saying "Sorry, you can't put the password into the command,it's a security problem in things like bash_history. Please use STDIN" Then goes "Fuckit!": echo 'password123' > hide add -n account -u user -p Maybe they should be allowed to do that? (I can almost imagine scenarios where someone might want to use a tool like this in some server automation thing where the security tradesoffs really do make using it like that a not awful idea?)

woodruffw 6y ago

This is a good point, and I should have been more precise in my original comment :-) If the program is on a TTY, then reading with echo disabled (i.e., `read -s`) is definitely preferable. I usually have stdin configured as a fallback for when the program isn't on a TTY, for programmatic use. This has the `echo` problem that you mentioned, but it's strictly better than either argv or the environment (both of which persist throughout the program's lifetime and appear in places like procfs).

dharmab 6y ago
For programmatic use a file or system keychain is safer than stdin.
- woodruffw 6y ago
  Agreed re: the file. For the system keychain, I think we're talking about different use cases, no? The system keychain should be used to store the master password, but using it to pre-store any password you intend to later store in another password manager feels a little silly.