Shadow password transmitted in "clear text" across a network

Hi,

I'm currently working on a solution that involves getting the entries of
a user for /etc/password and /etc/shadow from a database on the server
to a client. I know I could use some other kinds of authentication, but
that's really practical for what I do. I just wonder if transmitting
clearly the shadow password is a security flaw. It's intended to be on a
local network, not directly connected to the internet. But there's still
a risk of having someone from the inside with a packet sniffer. In such
a case, what would he need to be gain unauthorized access using the
shadow password of some user ?


JD

Huge wrote:
> Don't. Better people than you have already solved this problem in a
multitude
> of ways.
>
>

What centralized authentication method could be used to allow people
using a computer with this constraint : one user at a time for all
services on one host, the allowed user for each being selected by an
external program, with the ability to changes those settings at any time
? It's because I don't know of another solution that I thought about
adding and deleting lines in /etc/password and shadow when desired.

Huge wrote:
> Well, modifying /etc/passwd doesn't help with the "At any time"
requirement, since
> removing the entry for a logged on user does not log them off...

That's not a requirement. The user decides when he logs, what I want is
to prevent all other people from logging to rssh on the client machine
if he is not the one effectively using it.

> TBH, a custom PAM module sounds much more like what you want.

Ok, so let's say I write a PAM module (I guess that's a lot cleaner than
what I'm currently doing) : I see two issues.
1) there will still be hashed password transmissions across the network.
Can someone gain access to the system after finding such a password ?
The only way is to hash lots of strings and compare with the grabbed
value, right ? How hard is that with a password as strong as a shadow
password ?
2) I will anyway need to use some encryption because someone could also
pretend to be the server and send an arbitrary password to the client's
pam and be granted access. And that brings me back to my original
method, because if it's not too insecure, it will also have the enormous
advantage of saving a lot of my time.

> I'm currently working on a solution that involves getting the entries of
> a user for /etc/password and /etc/shadow from a database on the server
> to a client. I know I could use some other kinds of authentication, but
> that's really practical for what I do. I just wonder if transmitting
> clearly the shadow password is a security flaw.

Look at the permissions of /etc/shadow. Is it world readable? Of course
not, and that's for a reason. (If yours is, you've likely been
compromised.)

If someone has absolutely no knowledge of a password, they can only try to
brute force the login - which you, of course, will know about, as you
certainly watch your logs for that sort of thing. Or, your system may
automatically lock their account after a certain number of failed attempts.
Either way, it's a very long, easily-spotted sort of attack.

However, all of that changes if they have the encrypted password. They
can do the brute-forcing at their leisure, unbeknownst to you - and even
spread the load across multiple machines. Then, once they have the
password, they can log right in, and a single login will be much harder for
you to spot - and by the time you do, the damage may have been done.

> In such
> a case, what would he need to be gain unauthorized access using the
> shadow password of some user ?

Any of the myriad of password crackers, and time. The more machines he
has at his disposal (and the weaker your password), the less time he needs.

steve

Ok, so I will encrypt the connection. I just found a toolkit to use SSL
in my tcl scripts. Thanks.

Julien Demoor wrote:
> Hi,
>
> I'm currently working on a solution that involves getting the entries of
> a user for /etc/password and /etc/shadow from a database on the server
> to a client. I know I could use some other kinds of authentication, but
> that's really practical for what I do. I just wonder if transmitting
> clearly the shadow password is a security flaw.

Isn't this NIS? Don't reinvent the wheel needlessly. And yes... it
is a security risk.

> It's intended to be on a
> local network, not directly connected to the internet. But there's still
> a risk of having someone from the inside with a packet sniffer. In such
> a case, what would he need to be gain unauthorized access using the
> shadow password of some user ?

You'd capture the hash (whatever format) and use something like
John the Ripper to attempt to crack it. Old style DES is
quite crackable (used by traditional/portable NIS).