Updated to add the Windows NT password mechanism explaination.

Jeremy (jra@cygnus.com)
(This used to be commit fd428da77059ba722d29a07aec4a9b2aacff33a9)

1 files changed, 27 insertions, 24 deletions

diff --git a/docs/textdocs/ENCRYPTION.txt b/docs/textdocs/ENCRYPTION.txt
index 046b473e9a..c50861d3cb 100644
--- a/docs/textdocs/ENCRYPTION.txt
+++ b/docs/textdocs/ENCRYPTION.txt
@@ -1,9 +1,9 @@
 		LanManager / Samba Password Encryption.
 		---------------------------------------
 
-With the development of LanManager compatible password encryption for
-Samba, it is now able to validate user connections in exactly the same
-way as a LanManager or Windows NT server.
+With the development of LanManager and Windows NT compatible password 
+encryption for Samba, it is now able to validate user connections in 
+exactly the same way as a LanManager or Windows NT server.
 
 This document describes how the SMB password encryption algorithm
 works and what issues there are in choosing whether you want to use
@@ -22,6 +22,10 @@ two 56 bit DES keys to encrypt a 'magic' eight byte value, forming a
 16 byte value which is stored by the server and client. Let this value
 be known as the *hashed password*.
 
+	Windows NT encryption is a higher quality mechanism, consisting
+of doing an MD4 hash on a Unicode version of the users password. This
+also produces a 16 byte hash value that is non-reversible.
+
 When a client (LanManager, Windows for WorkGroups, Windows 95 or
 Windows NT) wishes to mount a Samba drive (or use a Samba resource) it
 first requests a connection and negotiates the protocol that the client
@@ -31,7 +35,7 @@ Samba server after the reply is sent and is known as the *challenge*.
 
 The challenge is different for every client connection.
 
-The client then uses the hashed password (16 byte value described
+The client then uses the hashed password (16 byte values described
 above), appended with 5 null bytes, as three 56 bit DES keys, each of
 which is used to encrypt the challenge 8 byte value, forming a 24 byte
 value known as the *response*.
@@ -39,6 +43,9 @@ value known as the *response*.
 In the SMB call SMBsessionsetupX (when user level security is
 selected) or the call SMBtconX (when share level security is selected)
 the 24 byte response is returned by the client to the Samba server.
+For Windows NT protocol levels the above calculation is done on
+both hashes of the users password and both responses are returned
+in the SMB call, giving two 24 byte values.
 
 The Samba server then reproduces the above calculation, using it's own
 stored value of the 16 byte hashed password (read from the smbpasswd
@@ -52,8 +59,8 @@ is this allowed access. If not then the client did not know the
 correct password and is denied access.
 
 Note that the Samba server never knows or stores the cleartext of the
-users password - just the 16 byte hashed function derived from it. Also
-note that the cleartext password or 16 byte hashed value are never
+users password - just the 16 byte hashed values derived from it. Also
+note that the cleartext password or 16 byte hashed values are never
 transmitted over the network - thus increasing security.
 
 IMPORTANT NOTE ABOUT SECURITY
@@ -63,10 +70,10 @@ The unix and SMB password encryption techniques seem similar on the
 surface. This similarity is, however, only skin deep. The unix scheme
 typically sends clear text passwords over the nextwork when logging
 in. This is bad. The SMB encryption scheme never sends the cleartext
-password over the network but it does store the 16 byte hashed value
-on disk. This is also bad. Why? Because the 16 byte hashed value is a
-"password equivalent". You cannot derive the users password from it,
-but it could potentially be used in a modified client to gain access
+password over the network but it does store the 16 byte hashed values
+on disk. This is also bad. Why? Because the 16 byte hashed values are a
+"password equivalent". You cannot derive the users password from them,
+but they could potentially be used in a modified client to gain access
 to a server. This would require considerable technical knowledge on
 behalf of the attacker but is perfectly possible. You should thus
 treat the smbpasswd file as though it contained the cleartext
@@ -108,17 +115,11 @@ ftp
 ftp) which send plain text passwords over the net, so not sending them
 for SMB isn't such a big deal.
 
-- the SMB encryption code in Samba is new and has only had limited
-testing. We have tried hard to make it secure but in any new
-implementation of a password scheme there is the possability of an
-error. 
-
-
 The smbpasswd file.
 -------------------
 
 	In order for Samba to participate in the above protocol it must
-be able to look up the 16 byte hashed value given a user name.
+be able to look up the 16 byte hashed values given a user name.
 Unfortunately, as the UNIX password value is also a one way hash
 function (ie. it is impossible to retrieve the cleartext of the users
 password given the UNIX hash of it) then a separate password file
@@ -162,14 +163,16 @@ chmod 600 smbpasswd.
 
 The format of the smbpasswd file is
 
-username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:Long name:user home dir:user shell
+username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:Long name:user home dir:user shell
 
 Although only the username, uid, and XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 sections are significant and are looked at in the Samba code.
 
 It is *VITALLY* important that there by 32 'X' characters between the
-two ':' characters - the smbpasswd and Samba code will fail to validate
-any entries that do not have 32 characters between ':' characters.
+two ':' characters in the XXX sections - the smbpasswd and Samba code 
+will fail to validate any entries that do not have 32 characters 
+between ':' characters. The first XXX section is for the Lanman password
+hash, the second is for the Windows NT version.
 
 When the password file is created all users have password entries
 consisting of 32 'X' characters. By default this disallows any access
@@ -185,7 +188,7 @@ NO PASSWORD
 Eg. To clear the password for user bob, his smbpasswd file entry would
 look like :
 
-bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:Bob's full name:/bobhome:/bobshell
+bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:Bob's full name:/bobhome:/bobshell
 
 If you are allowing users to use the smbpasswd command to set their own
 passwords, you may want to give users NO PASSWORD initially so they do
@@ -200,7 +203,7 @@ normal unix /etc/passwd file.
 The smbpasswd Command.
 ----------------------
 
-	The smbpasswd command maintains the 32 byte password field in
+	The smbpasswd command maintains the two 32 byte password fields in
 the smbpasswd file. If you wish to make it similar to the unix passwd
 or yppasswd programs, install it in /usr/local/samba/bin (or your main
 Samba binary directory) and make it setuid root.
@@ -246,7 +249,7 @@ secure by reporting all problems to me (the author, Jeremy Allison).
 
 My email address is :-
 
-jra@vantive.com
+jra@cygnus.com
 
 Setting up Samba to support LanManager Encryption.
 --------------------------------------------------
@@ -300,7 +303,7 @@ If this fails then you will find that you will need entries that look
 like this:
 
 # SMB password file.
-tridge:148:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:Andrew Tridgell:/home/tridge:/bin/tcsh
+tridge:148:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:Andrew Tridgell:/home/tridge:/bin/tcsh
 
 note that the uid and username fields must be right. Also, you must get
 the number of X's right (there should be 32).