2

Let's say I have a Bash script that generates a password, creates a new user with that password, and then tells me what the password is:

# Generate a password and set it to $PASSWORD
PASSWORD=$(tr -dc '[:graph:]' < /dev/urandom | head -c $(shuf -i 24-32 -n 1))

# Create a new user and set its password to $PASSWORD
useradd --home-dir /home/tom --create-home tom
echo "tom:$PASSWORD" | chpasswd

# Output the $PASSWORD
echo "The password is: $PASSWORD"

I will execute this script, as root, only one time.

After the script shows me the password, I will manually note it into my secure password management system.

I do not want the plain-text password to ever be visible on the system again, even to the root user (to the greatest extent possible).

1. Will it be possible for someone to see the output (plain-text password) of this script in the future, and if so, how can I remove it from the system?

2. What can I do (if anything) to make sure the contents of $PASSWORD are never accessible after the script has finished?

1

The script you wrote does not put the password into any easily accessible long-term storage (like a file). Even if typical linux auditing would be enabled (which would write all unix program invocations to a log file, including arguments), the password is not visible, as it is only passed via streams. The only exception is the "echo" command, which happens to be a shell builtin on bash, so it is not a "unix program invocation".

If the script finished, the memory allocated to $PASSWORD is freed, and if another processs happens to allocate that memory, it will be cleared before. But the memory used for "$PASSWORD" (or the copies made inside chpasswd, the echo builtin, the graphics library to display the password) is not necessarily cleaned after termination of that script. If you happen to use a GUI with a console window, the password obviously is in memory as long as you can scroll back to it. Depending on security settings in the kernel, root processes might be able to search the whole physical memory or swap space for copies of the password, but any program allocating memory via the kernel is guaranteed to not find the password in there, because the memory will be cleared before it will be handed out for another process.

If your computer has plenty of memory, or the password ended up in swap space, it might be around for along time after you script finished. Having no swap (or disabling swap and clearing the whole swap partition/file) prevents the password ending up in the swap file. Allocating and overwriting lots of memory can clear the password from memory, but is a dangerous thing to do on linux because the OOM killer which will kick in just as you can be sure you have overwritten all memory that might contain the password might kill some unrelated process.

If you need security against memory scraping, the password generation would have to make sure that the password is never copied to uncontrolled memory, and the controlled memory is cleared before the program exits. There is no way to do that in shell. I think the is even no way to display a password (short of writing it to video memory yourself) which is 100% guarantueed of not copying the password to some random memory.

  • Thank you for your response and for the detail you provide. It is very helpful :) – user31679 Oct 18 '15 at 23:56
0

Your script is well written for password generation. Most important thing is that you keep the password in RAM and do not store it on disk. Disabling swap during creation will prevent the password from being stored on disk accidentially.

When you think of the root user being able to dump the RAM, you have no chance to avoid password extraction completely. To further protect against eavesdropping, you can create the passwords offline from a Live-CD and just copy the generated password hashes to /etc/shadow (or LDAP, or whatever).

  • Thanks for the response and for the idea of generating hashes away from the system, thereby never even needing a plain-text copy on the system at any time. That will be useful in the future :) – user31679 Oct 18 '15 at 23:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy