SYSKEY2. Request For Comments

Simon Lodal simonl at mirrormind.com
Mon Feb 7 22:16:26 GMT 2000


I am not a security expert, but trying to keep up. I do not understand the
real point in SYSKEY2, what is the primary purpose? I only see it making
trouble, no solutions. Excuse me if I'm lame, I know that, but please read
on. Quoting from luke's recent mails:

> recently, netect / bindview posted a review of the syskey system and how
> the RC4 cypher stream was reset each time.  standard RC4 attack analysis
> shows that XORing two obfuscated passwords together results in the XOR
> cypher stream dropping out, and you have the two XORed password.  further
> attack analysis can decrypt the  passwords.

So the problem is that MS' encryption is again too weak?

> i need to make the sam database read-accessible to all unix users.  just
> like /etc/passwd.

So the real problem is that we can't hide these weak password hashes from
anyone?

Jeremy suggested something along the lines of /etc/shadow.

> well, the trouble with that is that i will have to maintain (and lock, and
> maintain), two databases, for users.

So it could be done, only with a slight more trouble? What's worst;
implementing a new encryption system (which may itself open
vulnerabilities), or locking just another file?

The same mail also said:
> i won't be -- over-the-wire.  i blank those out.

But 3 days later:
> but it's not.  think.  ldap.  sql.  nis+.  we can't trust them, and
> they're all publicly accessible network protocols.

So the real problem has now turned out to be that we are using other
protocols that someone might be able to listen on, over the wire?


Sorry if I bother you, my intention is really to figure out what the problem
is, and I am quite confused. I am surely mixing different concepts together.

However I do have some general comments, ignorantly not knowing anything
about the proposed encryption algorithms or protocols:


1) If the problem is only local storage, the obvious solution is a shadow
password system. The argument that you must trust root applies.

2) If the problem is that we cannot avoid revealing password hashes, because
they have to be sent over the wire, the solution is _not_ to add encryption
to Samba. The right solution is to encrypt that wire. People know that when
they choose to store passwords off the server. They must take care
themselves to make it safe. Just like you should know the risk if you run a
web- or mail-server using a DNS server running on another machine. People
know that, and it is not the responsibility of neither Apache nor bind to
solve that problem. It is a problem with IP (AFAIK). Same goes here; it's a
problem with NIS or LDAP. I don't see the point in samba trying to solve
their problems.

I don't know anything about LDAP or NIS, but if they reveal password hashes
to the users, they're no better than old-style UNIX passwd files. Not
samba's problem.

3) The idea of storing the necessary key on a diskette off the machine only
makes things much worse. In theory it will add security, but in real life
there will be a major vulnerability: The human factor. Good old word says
that the only safe server is one that is shut down and locked in a closet.
It's the same if you need that disk to boot the machine. People will not
lock it in a closet, and they will not carry it around all day long, keep it
under their pillow when they sleep. So where will it be, in real life? Ha,
probably in the disk drive. How disciplined would you be? So when a
malicious person comes by the sysadms empty office, of course the sysadms
keyboard/monitor is suitably locked ... but what about that disk in the
drive, or on top of a pile of papers? Key to the entire system, thanks.


... just my 0,02 euros :)

/Simon







More information about the samba-ntdom mailing list