Page History

...

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 encrypted format, once it arrives at the web server it is in clear-text and could be accidentally exposed by an inexperienced web programmer. IWA does not suffer from this vulnerability since the username and password never leave the user's 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 reassurance of the safety and validity of IWA is being provided to the GLAST community in the form of this article.

...

IWA is an example of Browser Based Authentication since it is a feature that must be built-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 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.

...

...

A hash of these credentials (not the credentials themselves) is passed to the web server (the line Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=TlRMTVNTUAABAAA... in the diagram listing below), 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 browser (after the WWW-Authenticate: NTLM in the diagram listing below) is the encrypted challenge:

Back at the browser, the browser attempts to decrypt the challenge with the user's password to get the answer to the challenge, which the browser then sends to the web server as proof that the user is who they claim to be. In the diagram listing below, the string of characters after the line Authorization: NTLM is what the browser thinks the answer is. In this case, the user provided valid SLAC credentials to the browser, and the original page is served:

...