是否可以通过IIS上的HTTP进行身份验证（不使用SSL）？

Question

I'm accustomed to *nix servers and if we wanted a completely secure sign in screen, we (as far as I am aware) are to use SSL via HTTPS. Our overseeing organization at work use Windows Servers for serving web pages. On one such page they are authenticating network credentials. This page is using HTTP, and what appears to be Basic Auth (a popup dialog) for an SQL Server Report Manager.

They say Basic is disabled in IIS.

In my limited experience with IIS at college, I (think I) recall subdomains can override general settings. They believe it's using Integrated Windows Authentication.

So...

1. Is there a way to differentiate between Basic Auth and Integrated Windows Auth when viewing a web-page prompt, and...

2. Is it possible to encrypt the communication between computer and server during authentication so that the text being sent is encrypted (without a JS solution)?

Answer 1

Both Basic and Windows Integrated authentication send the credentials unencrypted over the wire. If the popup login box has the name of the browser in it, and looks like a standard window, it's Basic or Integrated. If the username/password used to gain access is the same as the user's domain account, it's Windows Integrated. You can confirm either by sniffing the HTTP transmission with Fiddler.

There is no good, practical way to encrypt those credentials in either case without SSL. Here is a good article on why custom security methods are a bad idea, and SSL is the way to go.

Answer 2

You could also use HTTP Digest authentication , which will encrypt the authentication in the HTTP header (even without SSL). This will show a dialog box similar to the one you get with HTTP Basic authentication. There are a couple of downsides:

• Most browsers use the same dialog box for Basic and Digest authentication, so as a user, you don't really know which one it's using.
• Only the authentication is encrypted, a Man-In-The-Middle who could intercept and alter the exchange could replace the content of the requests using those credentials.

For these reasons, SSL is better (as suggested before).