Save password between bash script execution - security

Question

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

Answer 1

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

Answer 2

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.

Answer 3

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.