I have a script that a member of our L1 team will run on a linux server (ssh'ed in - non root) that will take in their password and pass it to kinit via an embedded expect script (which ultimately talks to our authentication Kerberos KDCs) for the sake of running a ready for business check.

A consideration was to use getpass2 python but that's not available inhouse. A possible solution exists via a shell script using:

read -s -p "Password for $USER: " PASS

I've read through this blog. The author claims

Between the prompt and the shell execution, the password is in cleartext .

Are there steps to take to mitigate this?

I realize the password is in cleartext in RAM as well - but this is a separate issue for now.

  • 1
    What threat are you trying to protect against? Obviously it'll have to be plaintext when they enter it and when it's sent to Kerberos, so what advantage do you gain by encrypting & decrypting it in between? Commented Apr 4, 2018 at 17:40
  • 1
    The password never gets sent to the KDCs. I've clarified the use. My intent is to read in a password as securely as possible. If you think it's a non issue, I'm open to your reasoning why.
    – james6125
    Commented Apr 5, 2018 at 1:07
  • 1
    You should never be processing sensitive data using a shell script.
    – forest
    Commented Apr 5, 2018 at 1:54
  • Thanks forest. Do you have any suggestions for moving the use case forward?
    – james6125
    Commented Apr 5, 2018 at 21:28
  • That depends on exactly what you need to do. You may be able to use PAM for authentication.
    – forest
    Commented Apr 6, 2018 at 5:44

3 Answers 3


You assume (as do a lot of people whom should know better) that when you input a password there is some some magic mojo protecting its cleartext in the program. If you can assure the integrity of the program reading the password and it does not deliberately persist or export the cleartext, then it will not be accessible to other programs.

A script is slightly easier to compromise than a binary program assuming that the attacker has root level access to the filesystem - but at that point its already pretty much game-over. There is an argument that if the program is swapped out of memory, then the cleartext will persist on the swap space - but that is almost the same problem as protecting the RAM (you shouldn't be using remote storage for swap anyway).

Update Sergey's answer appears to address what you do with the password after you have captured the cleartext (although its not very clear). But if you are using a shell builtin to inject the password into the target program it will not appear in the output of 'ps'


kinit has its own facility for password input. For example...

$ kinit user@realm Enter password for user@realm:

I would suggest the tools input method which is already hiding the input from the terminal

  • Thanks. The point of the script is to reduce the number of times the analyst enters the password. Can you share what makes kinit more secure?
    – james6125
    Commented Apr 5, 2018 at 21:12

Each non-builtin command in scripts appears as separate process, so from the cited blog example PASS ( which should be quoted, btw, to avoid word splitting ) will appear on ps output.

See also https://unix.stackexchange.com/q/298178/85039 and https://stackoverflow.com/q/3830823/3701431 for possible ways to solve it

There are also security implications of word splitting: https://unix.stackexchange.com/q/171346/85039

  • 2
    There is nothing in the OP's question about how the password is used after it has been captured by the script. "Each command in scripts appears as separate process" - that's not true, only if the command is a seperate binary. Most shells (and we're probably talking about bash here) have a large set of builtin commands including echo which will not appear in as new processes.
    – symcbean
    Commented Apr 5, 2018 at 9:21
  • @symcbean Good point about built-ins, I'll edit that. As for "how password is used after it has been captured", if they use read to capture password into a variable, and point to blog post that is doing exactly same thing, it's reasonable to assume that's what they're doing, no ? Unless they're placing password into command's environment, which is still accessible via /proc/<PID>/environ Commented Apr 5, 2018 at 17:27
  • Thanks. We will not be passing the password to a command as a parameter but will engage an expect script to spawn kinit repeatedly.
    – james6125
    Commented Apr 5, 2018 at 21:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .