Re: Password file security

[Keith Keller]

On 2012-09-14, houghi <hou...@houghi.org.invalid> wrote:
> When I make a bash script that needs a password, I do the following:
> #!/bin/bash
> . ~/.passwords
> echo "The password is $PASSWORD"
>
> The file ~/.passwords contains:
> PASSWORD=$SECRET
>
> That way I can still show the script to others and not need to enter
> passwords.
>
> This however leaves the .~/.password file in clear text and that is not
> a good idea, I think. What would be the best way to see that this is
> not readable, while still able to use it in a standard script in the
> normal way.

One typical method is to read the password in, e.g.

stty -echo
read passwd
stty echo

Then the shell variable $passwd contains your password, and you can
still show your script to others. The $passwd variable is not private,
but it won't outlast the running shell, so it's safer than leaving a
file on disk.

If you need to have the password on disk, you can encrypt it, and
decrypt only for the length of time you need it available to the script.

--keith

--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

[Chris F.A. Johnson]

On 2012-09-14, houghi wrote:
> When I make a bash script that needs a password, I do the following:
> #!/bin/bash
> . ~/.passwords
> echo "The password is $PASSWORD"
>
> The file ~/.passwords contains:
> PASSWORD=$SECRET
>
> That way I can still show the script to others and not need to enter
> passwords.
>
> This however leaves the .~/.password file in clear text and that is not
> a good idea, I think. What would be the best way to see that this is
> not readable, while still able to use it in a standard script in the
> normal way.

chmod 700 ~/.password

> Or am I over cautious and will it be all to no avail as people who hack
> my PC will be able to find the password anyway by running the script?

If your home directory is secure (chmod 700 ~), it should be all right.

And/or call it something less obvious.

--
Chris F.A. Johnson, author <http://shell.cfajohnson.com/>
===================================================================
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)

[Kaz Kylheku]

On 2012-09-14, houghi <hou...@houghi.org.invalid> wrote:
> When I make a bash script that needs a password, I do the following:
> #!/bin/bash
> . ~/.passwords
> echo "The password is $PASSWORD"
>
> The file ~/.passwords contains:
> PASSWORD=$SECRET

This file doesn't accomplish anything.

To use this file, the user has to store a value in the variable called
SECRET.

Whatever he stores in that varaible, he could just store it in the PASSWORD
variable in the first placed and avoid sourcing that script.

> This however leaves the .~/.password file in clear text and that is not
> a good idea, I think.

But your password file doesn't contain any secret, just the code

PASSWORD=$SECRET

You can't learn the contents of $SECRET by looking at this file.

> What would be the best way to see that this is
> not readable, while still able to use it in a standard script in the
> normal way.

You could just have these instructions:

"To use my scripts, which require a password, create a variable called PASSWORD
which contains the necessary password. For security reasons, do not store this
in a file."

For convenience, you could have some script that the users have to source in
order to set up the environment. The script will ask the user for a password,
and just keep it in a variable.

> Or am I over cautious and will it be all to no avail as people who hack
> my PC will be able to find the password anyway by running the script?

If the password is only in a volatile environment variable in your login
session, they would have to have physical access to your console, or hack a
privileged account so that they can peek into the address space of your process
to find the environment variable.

Anyway, what is this password for? Maybe that password-protected system already
has a solution for scripting. For instance if you're using the password to run
remote jobs via ssh, then you can use certificates and ssh-agent.

[Ben Bacarisse]

houghi <hou...@houghi.org.invalid> writes:

> When I make a bash script that needs a password, I do the following:
> #!/bin/bash
> . ~/.passwords
> echo "The password is $PASSWORD"
>
> The file ~/.passwords contains:
> PASSWORD=$SECRET
>

> That way I can still show the script to others and not need to enter
> passwords.
>

> This however leaves the .~/.password file in clear text and that is not

> a good idea, I think. What would be the best way to see that this is

> not readable, while still able to use it in a standard script in the
> normal way.
>

> Or am I over cautious and will it be all to no avail as people who hack
> my PC will be able to find the password anyway by running the script?

For what it's worth, I store most of passwords as gpg encrypted files.
Each file may have it's own key but of course I use just one or two
because the whole point is to simplify remembering them all.

I have a small set of scripts to store, edit and "invoke" these
passwords, and another script that is bound to a keystroke so I get a
list (in a GUI) that I can choose from.

I say "invoke" because the script that unlocks the password (by
decrypting it) passes it to a program that injects the characters into X
windows. The effect is as if I'd typed those charters. I can therefor
use the same mechanism for web sites as I can for command-line ftp
programs.

It's grown over the years and now it can interpret escapes like \t and
\n so I can automate entering both a user name and a password into a web
form in one simple action.

<snip>
--
Ben.

[Ben Bacarisse]

houghi <hou...@houghi.org.invalid> writes:

> Ben Bacarisse wrote:
>> For what it's worth, I store most of passwords as gpg encrypted files.
>> Each file may have it's own key but of course I use just one or two
>> because the whole point is to simplify remembering them all.
>

> Then you need to still enter things manualy. I have also API keys that I
> use with scripts.
>
> From what I gatherd, the best I can do is obfustigation. I still want to
> just source the original file and not have too much.

Yes, I realised that, hence my "for what it's worth" lead-in. I've
never been a fan of obfuscation on its own since it usually just points
intruders to the important stuff.

<snip>
--
Ben.