[prev in list] [next in list] [prev in thread] [next in thread]
List: samba
Subject: SAMBA digest 560
From: samba () anu ! edu ! au
Date: 1995-06-05 16:07:13
[Download RAW message or body]
SAMBA Digest 560
Topics covered in this issue include:
1) SMB encrypted passwords
by Laine Stump <laine@MorningStar.Com>
2) Re: SMB encrypted passwords
by Doug Hughes <Doug.Hughes@Eng.Auburn.EDU>
3) Re: Samba archives in Europe
by ralf@rbsoft.sdata.de (Ralf Beck)
4) Re: SMB encrypted passwords
by "Andrew.Tridgell" <tridge@arvidsjaur.anu.edu.au>
5) ksmbfs + amd
by "Andrew.Tridgell" <tridge@arvidsjaur.anu.edu.au>
----------------------------------------------------------------------
Date: Sun, 4 Jun 1995 14:17:01 -0400
From: Laine Stump <laine@MorningStar.Com>
To: samba@anu.edu.au
Subject: SMB encrypted passwords
Message-ID: <199506041817.OAA01899@tubeworm.morningstar.com>
"Andrew.Tridgell" <tridge@arvidsjaur.anu.edu.au> writes:
> Servers such as WinNT negotiate encrypted passwords with clients. This
> means the server sends to the client a 8 byte random "cryptkey" when
> negotiating a connection. The client then encrypts the users password
> using a two stage DES process. The result is sent over the net. The
> server then goes through the same process to validate the password.
>
> This encryption protocol is described in the X/Open SMB spec, but
> Microsoft implemented things with two small (but very important)
> changes. Thanks to some help from Microsoft we now know what those
> changes are and we can put a compatible system into Samba.
Unless their "two stage" DES process yields a result which cannot be
decrypted (given the key), this is not much more secure than just
sending plaintext passwords - if you've got the encrypted password and
the encryption key, you've also got the original password.
This is why PPP's CHAP authentication uses MD5 rather than DES - MD5
only goes in one direction.
So, is it deccryptable, or not?
> Note that it is not possible to mix the two, and have some
> users using the unix password system (and plaintext passwords) with
> others using the SMB encrypted passwords. You could make it depend on
> which machine they come from, but not on their username (you don't
> know the username when you negotiate the encryption bit).
When deciding whether to send plaintext or encrypted, the judgement is
much more dependent on the wire that the packet must traverse than on
who is supposedly sending it. So, I don't think the inability to choose
method based on user is that important anyway, although the ability to
choose based on machine (or network) of the client might be nice. On the
other hand, if you don't want plaintext passwords passing over a wire,
you probably shouldn't let plaintext data packets over it either - the
entire session should be encrypted.
> 3) Users can also change the password from the client (using "net
> pass")
I know this is an issue with the protocol rather than with your
implementation of it, but clearly any password traversing the wire
during a "net pass" command would be decryptable. Therefore, anyone with
a amart, automated snooper which sat around grabbing "change password"
packets and interpreting them would eventually know everybody's
passwords. The only way to make this truly secure is with public key
encryption of the passwords. Even storing the DES key on the client so
it would never be transmitted would not be secure, unless the client
itself was physically secure and accessible to only one user (and the
presumption is that it isn't, otherwise you wouldn't be concerned about
authentication anyway).
------------------------------
Date: Sun, 4 Jun 1995 15:14:57 -0500
From: Doug Hughes <Doug.Hughes@Eng.Auburn.EDU>
To: samba@anu.edu.au
Subject: Re: SMB encrypted passwords
Message-ID: <doug-9505042014.AA00243172@netman.eng.auburn.edu>
> Date: Sun, 4 Jun 1995 14:23:11 +1000
> From: "Andrew.Tridgell" <tridge@arvidsjaur.anu.edu.au>
> To: samba@anugpo.anu.edu.au
> Subject: SMB encrypted passwords
> Message-ID: <199506040423.OAA03591@arvidsjaur.anu.edu.au>
>
> Jeremy Allison (jra@vantive.com) and myself have finally worked out
> the protocol for sending encrypted passwords over the net in the SMB
> protocol. Now we need to work out the best way to incorporate this
> into Samba.
>
> First a bit of background. Samba currently negotiates plaintext
> passwords with clients. This means anyone with a sniffer on your local
> net can see your password. It also means Samba can use the standard
> unix password system.
>
> Servers such as WinNT negotiate encrypted passwords with clients. This
> means the server sends to the client a 8 byte random "cryptkey" when
> negotiating a connection. The client then encrypts the users password
> using a two stage DES process. The result is sent over the net. The
> server then goes through the same process to validate the password.
>
> This encryption protocol is described in the X/Open SMB spec, but
> Microsoft implemented things with two small (but very important)
> changes. Thanks to some help from Microsoft we now know what those
> changes are and we can put a compatible system into Samba.
>
> The primary problem with the encryption method is that to implement it
> the server must have acess to the users plaintext password (or some
> equivalent). In the case of NT the MS technet CD says they actually
> store the result of the first stage DES encryption (commonly called
> p16) on disk on the server. This means it's not possible to recover
> the plaintext password from the file, but if you did have access to the
> file you could write your own SMB client which gained access using only
> p16. Thus p16 is a "password equivalent".
>
> So, there are basically two evils, take your pick:
>
> 1) have plaintext passwords on the net (the current Samba way)
> 2) have password equivalents stored on disk on the server (the NT way)
>
> In the spirit of user choice, I think it's best that system
> administrators choose, so there will be an option in smb.conf to
> choose plaintext or encrypted passwords. Plaintext will be the
> default. Note that it is not possible to mix the two, and have some
> users using the unix password system (and plaintext passwords) with
> others using the SMB encrypted passwords. You could make it depend on
> which machine they come from, but not on their username (you don't
> know the username when you negotiate the encryption bit).
>
> Now we just have to work out the best way to administer encrypted
> passwords.
>
> I think storing p16 on disk (rather than the plain password) is a good
> idea, although it doesn't gain much in real security. It just means it
> would be quite a bit of work to break in given access to the file. It
> also means a person breaking in couldn't use telnet etc, they would
> have to use SMB.
>
> Anyway, here is what I envisage, comments welcome!
>
> 1) a smb.passwd file containing username/p16 pairs, along with other
> per user info.
> 2) a smbpasswd program (probably setuid root) that allows users or the
> sysadmin to manipulate the password file (just like passwd).
> 3) Users can also change the password from the client (using "net
> pass")
> 4) optional password expiry times, with users being notified via a
> WinPopUp message (or other mechanism, coonfiigurable in smb.conf).
> 5) can use a samba or NT server as a "password server"
>
> Now I hope the above will prompt a bit of discussion. We want to "get
> it right".
>
> Andrew
>
Too bad you just couldn't rewrite the password thing altogether to
use some kind of assymetric key algorithm that would send the password
across the net encrypted. Then the server could decrypt it and stick
it in the password file in whatever format is desired. Of course, this
would entail rewriting how the client thinks about passwords (which
means MS has to rewrite their code - ick)
--
____________________________________________________________________________
Doug Hughes Engineering Network Services
System/Net Admin Auburn University
doug@eng.auburn.edu
"Real programmers use cat > file.as"
------------------------------
Date: Sat, 3 Jun 1995 22:06:11 +0200 (MDT)
From: ralf@rbsoft.sdata.de (Ralf Beck)
To: samba@anu.edu.au
Subject: Re: Samba archives in Europe
Message-ID: <9506032006.AA28911@rbsoft.sdata.de>
Hi there,
I am using this samba archie in the UK:
src.doc.ic.ac.uk
Samba is there in /packages/samba
Have luck,
+--------------+-----------------+-----------------------+--------------------+
> Ralf Beck |73614 Schorndorf | Phone (+49) 7181 21921|ralf@rbsoft.sdata.de|
> Quellenweg 4-1|Germany | Fax (+49) 7181 62257| |
+--------------+-----------------+-----------------------+--------------------+
**** Leben ist lebensgefaehrlich. - Erich Kaestner ****
------------------------------
Date: Mon, 5 Jun 1995 11:02:12 +1000
From: "Andrew.Tridgell" <tridge@arvidsjaur.anu.edu.au>
To: laine@MorningStar.Com
Subject: Re: SMB encrypted passwords
Message-ID: <199506050102.LAA05870@arvidsjaur.anu.edu.au>
Unless their "two stage" DES process yields a result which cannot be
decrypted (given the key), this is not much more secure than just
sending plaintext passwords - if you've got the encrypted password and
the encryption key, you've also got the original password.
This is why PPP's CHAP authentication uses MD5 rather than DES - MD5
only goes in one direction.
So, is it deccryptable, or not?
No, it is not decryptable. The first stage DES uses the users password
as the key and a well known 8 byte value (called S8) as the data. The
second stage uses the result of the first stage as the key and a
random (server chosen) value as the data. I'm simplifying things a
bit, but that covers the idea. The full spec is available on
nimbus.anu.edu.au in pub/tridge/samba/SMB-info/. It only differs from
reality in the choice of S8 and the padding of the password.
You can't derive the password even if you know all other parts of the
process, and have full source code.
What I proposed is that Samba (like NT) would store the result of the
first stage encryption (called p16) on disk on the server. Knowing
this does not allow you to derive the password, but you should
consider p16 to be a "password equivalent" as you could write a client
that took this value, skipped the first stage encryption and gained
access.
I know this is an issue with the protocol rather than with your
implementation of it, but clearly any password traversing the wire
during a "net pass" command would be decryptable. Therefore, anyone with
a amart, automated snooper which sat around grabbing "change password"
packets and interpreting them would eventually know everybody's
passwords. The only way to make this truly secure is with public key
encryption of the passwords. Even storing the DES key on the client so
it would never be transmitted would not be secure, unless the client
itself was physically secure and accessible to only one user (and the
presumption is that it isn't, otherwise you wouldn't be concerned about
authentication anyway).
This is true. There will be an option in smb.conf to choose if you
want to support the password changing protocol.
Unfortunately we can't do anything useful in Samba about encrypting
the entire session. You'll have to buy a hardware solution (and I
don't think we need to discuss those here).
Andrew
------------------------------
Date: Mon, 5 Jun 1995 11:45:38 +1000
From: "Andrew.Tridgell" <tridge@arvidsjaur.anu.edu.au>
To: samba@anugpo.anu.edu.au
Subject: ksmbfs + amd
Message-ID: <199506050145.LAA05948@arvidsjaur.anu.edu.au>
At home I use Volker's ksmbfs to mount my wifes WfWg drives on my
linux box. I found that together with the amd automount daemon it made
a very convenient package.
Unfortunately amd collapses // to / in it's map files, so I needed
this small change to smbmount.c for it to work:
diff -u ksmbfs-0.1/smbmount.c ksmbfs-0.1.new/smbmount.c
--- ksmbfs-0.1/smbmount.c Thu May 4 04:30:17 1995
+++ ksmbfs-0.1.new/smbmount.c Sun Jun 4 20:03:54 1995
@@ -161,12 +161,11 @@
return -1;
}
- if (!( (complete_service[0] == '/')
- && (complete_service[1] == '/'))) {
+ if (!(complete_service[0] == '/')) {
return -1;
}
- complete_service += 2;
+ while (complete_service[0] == '/') complete_service++;
share_start = strchr(complete_service, '/');
In case anyone is interested this is my amd map file for my two ksmbfs
mounts:
laplandc type:=program;mount:="/sbin/smbmount smbmount //lapland/c ${fs} -P XXXX -u \
148";unmount:="/sbin/umount umount ${fs}"
laplandd type:=program;mount:="/sbin/smbmount smbmount //lapland/d ${fs} -P XXXX -u \
148";unmount:="/sbin/umount umount ${fs}"
It's nice being able to edit my wifes config files using emacs :-)
I tried importing a drive from WfWg then reexporting it back to the
same PC using Samba. Trying to then copy a file using the WfWg file
manager to the net drive caused windows to freeze, which I think
demonstrates that the WfWg networking code is single threaded (it did
not service requests while waiting for a response)
I then tried it with Win95 and it worked, which means Win95 must be
able to respond to SMB requessts while waitng for a response to it's
own requests. It also mean that ksmbfs works pretty well! I was able
to run some large apps though this convoluted setup. ksmbfs did
eventually die, but I was hitting it pretty hard and it is version 0.1 :-)
Andrew
------------------------------
End of SAMBA Digest 560
***********************
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic