CODEWITHSUNDEEP
securitybashshellsh
Daniel Kats
Daniel Kats

Reputation: 5554

Save password between bash script execution

I want my script to prompt for a password, but I only want it to do so once per day session (let's say half an hour). Is it possible to save the login credentials of a user between script executions securely? I need this to be a bash script, because it has to run on several different types of UNIX, on which I am not authorized to install anything.

I was thinking of encrypting a text file to which I would write the login credentials, but where would I keep the password to that file? Seems like I just re-create the problem.

I know about utilities which run an enrypted script, and I am very against using them, because I do not like the idea of keeping a master password inside a script that people might need to debug later on.

EDIT: This is not a server logon script, but authenticates with a web server that I have no control over.

EDIT 2: Edited session duration

Upvotes: 5

Views: 5819

Answers (3)

evil otto
evil otto

Reputation: 10582

Depending on what the "multiple invocations" of the script are doing, you could do this using 2 scripts, a server and a client, using a named pipe to communicate. Warning: this may be unportable.

Script 1 "server":

#!/bin/bash

trigger_file=/tmp/trigger
read -s -p "Enter password: "  password
echo 
echo "Starting service"
mknod $trigger_file p
cmd=
while [ "$cmd" != "exit" ]; do
    read cmd < $trigger_file
    echo "received command: $cmd"
    curl -u username:$password http://www.example.com/ 
done
rm $trigger_file

Script 2 "client":

#!/bin/bash

trigger_file=/tmp/trigger
cmd=$1
echo "sending command: $cmd"
echo $cmd > $trigger_file

Running:

$ ./server
Enter password: .....
Starting service
received command: go

other window:

$ ./client go
sending command: go

EDIT:

Here is a unified self-starting server/client version.

#!/bin/bash

trigger_file=/tmp/trigger
cmd=$1

if [ -z "$cmd" ]; then
   echo "usage: $0 cmd"
   exit 1
fi

if [ "$cmd" = "server" ]; then
    read -s password
    echo "Starting service"
    mknod $trigger_file p
    cmd=
    while [ "$cmd" != "exit" ]; do
        read cmd < $trigger_file
        echo "($$) received command $cmd (pass: $password)"
        curl -u username:$password http://www.example.com/ 
    done
    echo exiting
    rm $trigger_file
    exit
elif [ ! -e $trigger_file ]; then
    read -s -p "Enter password: " password
    echo 
    echo $password | $0 server &
    while [ ! -e $trigger_file ]; do
      sleep 1
    done
fi

echo "sending command: $cmd"
echo $cmd > $trigger_file

Upvotes: 2

Anjan Biswas
Anjan Biswas

Reputation: 7912

Usually, passwords are not stored (for security) reasons, rather the password hash is stored. Everytime the user enters the password the hash is compared for authentication. However, your requirement is something like 'remember password' feature (like on a web browser, or windows apps). In this case there is no other way to store the password in a flat file and then use something like gpg to encrypt the file, but then you end up having a key for the encryption.

The entire design of asking the user of his credentials once per day is as good as not asking for any credentials. A tightly secure system should have appropriate time outs set to log the user off due to in-activity especially on back end server operations.

Upvotes: 0

Pyrce
Pyrce

Reputation: 8571

You are correct that saving the password anywhere that is accessible re-creates the problem. Also asking for credentials once per day instead of each time the program runs is essentially the same as not having an authentication system at all from the point of view of system security. Having the password anywhere that is easily readable (whether as plain text or encrypted by a plain text key) eliminates any security you gained by having a password to anyone with decent system knowledge/scanning tools.

The traditional way of solving this problem (and one of the more secure mechanisms) is to use SSH keys in lieu of passwords. Once a user has the key they don't need to ever re-enter their authentication manually. For even better security you can make the SSH key login as a user who only has execute privileges to the script/executable. Thus they wouldn't be able to change what the script does nor reproduce it by reading the file. Then the actual owner of the file can easily edit/run the script with no authentication required while keeping other users in a restricted use mode.

Upvotes: 1

Related Questions