X-no-Archive:yes
It's been a while since I had to dig up the behavior of enabling plain text.
I remember it not being so easy to find on the web, although that may have
changed. As I recall, when Windows tries to connect to a smb server of any
kind (be it NT 4, 3x, Lan Manager, Windows, Samba, etc.), Windows tries to
request challenge - response authentication. If the server does not support
this at all (and the server is the deciding factor), the server "fails" the
request in a known and well-defined way. Windows sees this failure. If the
registry is set to enable plain text password, which is not the default (and
I don't believe has been since WFW 3.11), it will then pass the password in
plain text. The server can then authenticate the user for that share (I am
not sure that this is limited to share-level access, the Lan Manager and
Windows way of managing its own shares, but would bet that way), with that
user name and password.

So, shares do normally require them as the default, and will only use plain
text under a very limited set of conditions, involving several steps. I am
no expert on this, but I am not aware of this being a known and actually
exploited security risk, although the opportunities to exploit it seem
obvious, and have been exploited on other systems (the truly paranoid can
always type their password in wrong the first time to detect host-based
password grabbers). But since the first attempt is challenge - response
authentication, enabling plain text passwords breaks nothing. Any host that
wants a challenge - response will still get it.

What is challenge - response authentication, you ask? The server already
knows your password. So it uses that as a key to encrypt a string. It
challenges your client with that string. If you type your password
correctly, your client will respond to this encrypted-string challenge with
a correctly unencrypted string, without ever sending your password over the
wire (or thru the aether, I suppose)

Greg Stigers
http://www.cgiusa.com