Using SHA1 Digested Passwords for SSH connection

[Joe Martin]

Hello all.
For testing, I have been inputting some various user credentials into a
database. The passwords are hashed (digested) with the SHA1 algorithm.
I have a script set up to read these passwords, and use them for
credentials for connecting to other machines to perform actions on each.

As you can imagine, passwords in clear-text connect just fine, but I'm
wondering if its possible to force the host to verify the digested
password, and allow the connection if the password matches the host's
stored password.

I'm using Net/SSH for connections to UNIX hosts, and WIN32OLE for
WMI/Registry connections on Windows.

If this is not possible how would I accomplish this? Basically, I want
to store passwords in a database in a secure fashion, read these
passwords and use them to connect to remote hosts. Is there a way to
accomplish this, or am I going about it the wrong way?

This is my first stab at security, so I'm slowly learning as I go along.
Thanks!

 

[Aaron Turner]

Hello all.
For testing, I have been inputting some various user credentials into a
database. =A0The passwords are hashed (digested) with the SHA1 algorithm.
I have a script set up to read these passwords, and use them for
credentials for connecting to other machines to perform actions on each.

As you can imagine, passwords in clear-text connect just fine, but I'm
wondering if its possible to force the host to verify the digested
password, and allow the connection if the password matches the host's
stored password.

Unfortunately, it isn't possible to send the remote host the SHA1'd
password and have them validate it that way.

I'm using Net/SSH for connections to UNIX hosts, and WIN32OLE for
WMI/Registry connections on Windows.

If this is not possible how would I accomplish this? =A0Basically, I want
to store passwords in a database in a secure fashion, read these
passwords and use them to connect to remote hosts. =A0Is there a way to
accomplish this, or am I going about it the wrong way?

This is a hard/common problem that people have. Generally speaking
the "correct" answer is to design your system so you don't need to
store user passwords in the database and then forward the passwords to
a remote system for authentication. There really isn't a secure way
to solve the problem in this manner.

--=20
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Win=
dows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
-- Benjamin Franklin

 

[Gyepi SAM]

Hi Joe,

I can't speak for the Windows side, but on the Unix side,
you could generate public/private keys and connect with those.
You could manage the keys through ssh agent. All of this is
supported by Net/SSH, with the only issue being that the
private key is generally specified as a path to a file
and I am not sure if Net/SSH allows the possibility to present
the key as data (read from the database). You could always write
a copy of the data to a file, ask ssh-agent to read it, then delete
the file; but that seems inelegant.

Regards

-Gyepi

 

[Brian Candler]

For testing, I have been inputting some various user credentials into a
database. The passwords are hashed (digested) with the SHA1 algorithm.
I have a script set up to read these passwords, and use them for
credentials for connecting to other machines to perform actions on each.

As you can imagine, passwords in clear-text connect just fine, but I'm
wondering if its possible to force the host to verify the digested
password, and allow the connection if the password matches the host's
stored password.

No. If you were able to do this, then the "digested" password would
become equivalent to a clear-text password. That is, anyone who stole
the "digested" password would be able to use it to login, so it's just
another password.

You could store the plaintext passwords two-way encrypted in your
database - i.e. so that you can unencrypt them when you need to use
them. Of course, whoever has access to both the database and the
decryption key can still get them. You could reduce this risk by not
storing the decryption key on disk, but instead prompting for the
decryption passphrase when your application starts. The downside is that
if the machine reboots, the application won't be able to run until the
passphrase has been entered again.

Now, you can also use SSH keys for authentication as has already been
mentioned, and this is a much better solution. Anyone who steals both
the private key and the key passphrase (or just the private key, if you
created it with no passphrase) will be able to use it to login. But you
can minimise the risks by:

1. Prompting for the passphrase when your application starts and keeping
it in RAM

2. Configuring the access at the server side so that this particular key
only has access to the specific commands it needs to be able to run,
and/or is only acceptable from certain source IP addresses. See
"AUTHORIZED_KEYS FILE FORMAT" in 'man sshd'

Another benefit of ssh key authentication is that the same key can be
used to login to hundreds of hosts. You can change the passphrase on the
key locally as often as you like, and don't need to make any changes on
those hosts.

 

[Joe Martin]

Thank you for the suggestions, all. I do have key-based authentication
set up on a number of Solaris hosts, but there are a handful of hosts
I've yet been setup on, and no idea on when I'll be setup for key-based
auth instead of password. Also, I work with a number of Windows boxes,
so I'm pretty much forced to use passwords for those.

I do like the idea of having the two-way encryption, where I can input
the passphrase at the time of service startup. That sounds like the
best solution for this particular application.

Thanks again! Cheers!