Hi,
I’m no expert at all on security, but today I was pondering an
interesting idea about storing passwords for use across a network
connection.
Here’s the scenario:
You have an application you want to deploy via Capistrano and there are
some commands to be run with sudo, but you don’t want to provide the
password each time you do that, so…
What if you store a password encrypted with the sudoer’s public key on
your application (say config/deploy/user.pw), and when you need to
provide a password you do something like:
run “sudo ls” do |channel, stream, data|
if data =~ /^Password:/
# decrypt user.pw using user’s private key
channel.send_data “#{decrypted_password}\n”
end
end
Of course this would work only if the private key doesn’t have a
passphrase…
So, security-wise, what do you think of this approach?
Regards,
Ivan V.
On Jun 6, 7:36 pm, “Ivan V.” [email protected] wrote:
password each time you do that, so…
In my experience, I only have to provide the password upon logging
into the remote machine… the sudo password is the same and I don’t
get prompts after that.
On Sun, Jun 8, 2008 at 11:34 PM, jemminger [email protected] wrote:
Of course this would work only if the private key doesn’t have a
passphrase…
So, security-wise, what do you think of this approach?
Depends on your threat model. The problem here is that anyone who is
able to gain access to the private key file now has the user’s
password. Generally speaking, this is considered bad and is why
passwords on Unix/Windows systems aren’t encrypted- they’re hashed so
the plain text password is unrecoverable. Honestly, this just changes
what file you have to protect (the private key instead of your script
with the password embedded).
You’re probably better off prompting for the password, caching it and
re-using it multiple times. Alternatively, you can edit the
/etc/sudoers file to give your user access to the necessary commands
without prompting for a password (and to prompt for any other
command).
–
Aaron T.
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix &
Windows
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. – Benjamin Franklin
Thanks for your input. I’ve reconsidered this approach now, but it
seemed like a fun idea at the time 
Aaron T. wrote:
On Sun, Jun 8, 2008 at 11:34 PM, jemminger [email protected] wrote:
Of course this would work only if the private key doesn’t have a
passphrase…
So, security-wise, what do you think of this approach?
Depends on your threat model. The problem here is that anyone who is
able to gain access to the private key file now has the user’s
password. Generally speaking, this is considered bad and is why
passwords on Unix/Windows systems aren’t encrypted- they’re hashed so
the plain text password is unrecoverable. Honestly, this just changes
what file you have to protect (the private key instead of your script
with the password embedded).
You’re probably better off prompting for the password, caching it and
re-using it multiple times. Alternatively, you can edit the
/etc/sudoers file to give your user access to the necessary commands
without prompting for a password (and to prompt for any other
command).
–
Aaron T.
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix &
Windows
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. – Benjamin Franklin