title: Secure password solution for a web service authenticating against Active Directory?
body: <p>An application I'm modifying has a Web Service, and one of the web methods on that web methods is used to authenticate a user against active directory.  So the current code called by the AuthenticateUser web method looks something like this:</p>
  
  <pre><code>string domainAndUsername = aDomain + @"\\" + username;
  string ldsPath = buildLdsPath(searchBase);
  DirectoryEntry entry = new DirectoryEntry(ldsPath, domainAndUsername, 
      password);
  
  try
  {
      //Bind to the native AdsObject to force authentication.
      object obj = entry.NativeObject;
  
      DirectorySearcher search = new DirectorySearcher(entry);
  
      search.Filter = "(sAMAccountName=" + username + ")";
      search.PropertiesToLoad.Add("cn");
      SearchResult result = search.FindOne();
  
      // more code to validate the result, etc...
  }
  </code></pre>
  
  <p>When I started looking at this code, the first thing that worried me is the arguments to the web method look like this:</p>
  
  <pre><code>[WebMethod]
  public ResultObj AddRole(string roleToAdd, string username, string password)
  {
      // code that calls above Authentication fragment...
  }
  </code></pre>
  
  <p>So the current web service is expecting a password string, presumably <strong>sent in the clear</strong> over the network as XML, when the request is made to the service.asmx page.</p>
  
  <p>Has anyone dealt with this type of issue before?  Are there alternative Active Directory authentication mechanisms I could use that would avoid having to pass in a plain-text password?  The best option I could come up with on my own is to invoke the WebMethod using an encrypted password, and have the code on the other side decrypt it.  However, I'd prefer a better solution--e.g.: is there some way to do search for a DirectoryEntry using a one-way hash instead of a password?</p>
  
  <p><strong>Edit:</strong></p>
  
  <p><em>Additional Details:</em>  To this point I haven't considered SSL as this is a tool that is internal to our company, so it seems like overkill, and possibly problematic (it'll be running on a company intranet, and not externally visible).  The only reason I'm even worried about the security of sending plain-text passwords is the escalating amount of (possibly password-sniffing) malware present even on company intranets these days.</p>