Page History

...

Although SSL is widely used to allow users to securely login to web sites, it is not the only method that modern browsers support. Another method, which is at least as secure as SSL (if not more so), is called Interated Integrated Windows Authentication (hereafter called IWA). Most web browsers (all versions of Internet Explorer, and recent versions of Gecko-based browsers such as FireFox 1.0) support IWA. In some ways IWA is more secure than SSL since IWA never sends the username and password to the remote web server. Although SSL sends the username and password in an encypted encrypted format, once it arrives at the web server it is in clear-text and could be accidently accidentally exposed by an inexperienced web programmer. IWA does not suffer from this vulnerability since the username and password never leave the browser.

SSL uses the widely recognized gold lock visual cue to indicate to the user it is safe to type your password, IWA uses a different (but just as valid) visual cue to reassure the user it is safe to type your password. Since the visual cues are different for the SSL and IWA methods, some reassureance reassurance of the safety and validity of IWA is being provided to the GLAST community in the form of this article.

...

Roughly speaking, there are two ways to authenticate a user to a web site called Forms Based Authentication and Browser Based Authentication. The method many users are familiar with is Forms Based Authentication, which is when a form embeded embedded in a web page prompts a user for their username and password over an SSL connection to the web server. The user types their username and password into the web form and clicks the submit button which sends the credentials to the web server over the encypted encrypted SSL channel for authentication. It is important to point out that the user's web browser has no idea that the user is logging into the web site - all that the web browser knows is that it is sending information to the remote web site over an SSL channel.

...

For both the Forms/SSL and Browser based authentication mechanisms, it is important that the user trusts the web site they are logging into. For example, just becasue because you use an SSL encypted encrypted form to send your username and password to a remote web site doesn't mean that your password is safe. If the programmer who created the remote web site is inexperienced in security issues, they could easily do something to compromise your password without intending to do so. Becuase Because security is so important and so easy for a programmer to get wrong, the Department of Energy requires SLAC to not allow programmers to ever ask a user for their username and password unless they obtain special permission from the lab.

IWA is an example of Browser Based Authentication since it is a feature that must be bulitbuilt-in to the browser. As with Forms/SSL, the user must trust the web site they are sending their credentials to. Since http://glast-ground.slac.stanford.edu/ is an official GLAST web site that has been vetted by SLAC Computing Services (SCS), GLAST users can trust that it is safe and secure to provide their SLAC credentials to the web site. In the dialog boxes above, the visual cue that it is safe for the user to enter their username and password into the dialog box is the HTTP address in the dialog box. it is clear to the user that they are connecting to the web site http://glast-ground.slac.stanford.edu/, and since they trust this web site they can safely enter their username and password.

Under the Covers of IWA

For those of you iterested interested in the details of IWA, I'll walk you throuh through the HTTP headers of a web browser connecting to http://glast-ground.slac.stanford.edu/ so that you can see how the cyptographic exhage cryptographic exchange works. In each of the following diagrams, the HTTP header sent by the browser to the remote web server is shown first, followed by the remote web server's response back to the browser.

Note that the web server repponds responds that the browser it is not authorized to access the web server (the HTTP/1.x 401 Unauthorized tells you this), and that the only valid form of authentication that the web server will accept is IWS (which is what the WWW-Authenticate: NTLM line tells you). Since IWA is built-in to the browser (in this case FireFox 1.0), it prompts the user for their username and password. A hash of these credentials (not the credentials themselves) is passed to the web server (in the line Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=), which allows the web server to look up the user in the Windows password database and to construct a unique encrypted challenge that the browser can only decrypt with the user's unique password. The long line of characters sent by the web server to the broswer browser (after the WWW-Authenticate: NTLM in the diabgram diagram below) is the encrypted challenge:

...