[CLUE-Tech] Bash and password entry

[Dave Anselmi]

Matt Gushee wrote:

> > I guess that if a machine is safe enough to keep your password for you, you
> > can just put it on disk (protected by filesystem permissions).  If it isn't
> > safe enough for that, it isn't safe to do anything but prompt when it's
> > needed.
>
> Could you expand on that statement a bit? I'm not a security expert
> (obviously), but I would've guessed that a password stored on disk would

> be a good deal easier for a cracker to access than one in memory.

Ok.  Assume that you're the only one with root on the box, otherwise there are
plenty of ways root can get your password (e.g., record all your keystrokes).

You have a password, a sequence of characters.  It can be stored in a file or in
memory.  Now someone cracks your box and gets root.  If they can find the
password they can get into your other box.

So, you've stored this password in a file.  It is not named "password" or
"secret" or anything else obvious.  Maybe it's part of a larger file with config
info for your script.  It is tucked away where it is hard to find (it only takes
a little paranoia and creativity to hide a file or a string pretty well in all
those megabytes in use on your disk).

So what is the cracker looking for?  He knows about standard Unix programs and
conventions so he looks at all the usual places (like /etc/shadow - you didn't
use the same password on both boxes, did you?).  He looks for typical things that
work on any box.  Maybe he'll find a way to record your keystrokes (which doesn't
give away the password if it's in a file).

In order to know there is a password in a file, the cracker has to find out that
you're sending files back and forth.  He has to find the script to understand how
you're doing it and that you're getting the password off disk.  Then he has to
read the password file (that's the easy part).  True, if you give the cracker
full reign for long enough, he has an easy time doing this if he's that
interested.  Hopefully you can notice that he's there before he takes an interest
in your custom scripts.

Now, suppose the password is in memory.  Your script starts when the machine
boots, asks for the password once, and runs merrily until the machine goes down.
Ok, the work for the cracker to find out that you're sending files back and forth
and have a password he wants is the same.  Having found that, he looks at the
script.  Now he coredumps the script process and your password is on disk (though
it takes a debugger to find it - not much of an obstacle to someone creative
enough to explore this far).

Even easier, whether the script runs full time or only when you log in, you have
to type in the password at some point.  Recording that is easier than reading out
of memory, and since you're probably typing at a "password" prompt may point out
what you're doing even before the cracker realizes what your script does.

I suppose there are many dimensions of risk we could talk about.  Is it worse to
keep the password around for a long time, or to type it in when it's needed?  If
someone breaks into your house, steals your box, and dissects it at leisure,
sure, memory (that goes away when they pull the plug) is safer than disk.  If
they break into your machine from the Internet, and you type the password
whenever you log in, maybe disk is better.

I guess my point is that the effort required to keep a password around in memory,
applied to hiding the password on disk results in similar protection.  In the
end, the effort you take to secure your system has to be greater than the effort
the crackers take to get you.

Dave