Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Many users are familiar with SSL encrypted web pages that ask them for their username and password to log into a web sitelogin to web sites. With SSL, web browsers use a gold lock as a visual cue to indicate to users that their username and password will be transmitted securely over the Internet. For example, this is what Wells Fargo Bank customers see in the lower right hand corner of the Internet Explorer 6.0 and FireFox 1.0 browsers when they log into their account:

...

Although SSL is widely used to allow users to securely log into a web sitelogin to web sites, it is not the only method that modern browsers support. Another method, which is just as seccureat least as secure as SSL (if not more so), is called Interated 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 format, once it arrives at the web server it is in clear-text and could be accidently exposed by an inexperienced web programmer. IWA does not suffer from this vulnerability since the username and password never leave the browser.

Whereas 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. Some users have recently raised the concern that since the Since the visual cues are different for the SSL and IWA methods, that some reassureance of the safety and validity of IWA be given is being provided to the GLAST community , which is in the purpose form of thie this article.

How IWA works

Roughly speakigspeaking, 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 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 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.

...

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. If the web server determines that In the diagram below, the string of characters after the line Authorization: NTLM is what the browser thinks the answer is correct, the web server sends the originally requested page . In this case, the user provided valid SLAC credentials to the browser. If not, and the user is presented with a "Unauthorized Access" page:

If the User Provides the Wrong Password

Image Removed

original page is served:

Panel
borderColor#ccc
bgColor#FFFFCE
titleBGColor#F7D6C1
titleBrowser Correctly Answere Answers the Challenge and Get the Web Server Sends Original Page
borderStyledashed

http://glast-ground.slac.stanford.edu/

GET / HTTP/1.1
Host: glast-ground.slac.stanford.edu
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,/;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: CFTOKEN=84811003; CFID=906
Authorization: NTLM TlRMTVNTUAADAAAAGAAYAF4AAAAYABgAdgAAAAAAAABAAAAAEAAQAEAAAAAO
AA4AUAAAAAAAAAAAAAAABYIIAGwAYQBuAGcAcwB0AG8AbgB0AHIAaQBuAGkAdAB5AGnvMd+cF8Ap
AAAAAAAAAAAAAAAAAAAAAKR+uySl79KWtB9ldk9LLw/n1IUXoy8IeQ==

HTTP/1.x 200 OK
Connection: close
Date: Sun, 19 Dec 2004 01:24:08 GMT
Server: Microsoft-IIS/6.0
Set-Cookie: JSESSIONID=98307ef1b78b$3F$B77B;path=/
Set-Cookie: CFAUTHORIZATION_glast_ground=;expires=Fri, 19-Dec-2003 01:24:08 GMT;path=/
Content-Type: text/html; charset=UTF-8

If the web server determines that the answer is correct, the web server sends the originally requested page to the browser. If not, the user is presented with a "Unauthorized Access" page. For example, if I given the wrong username and/or password, the user will see the following page.

If the User Provides the Wrong Password

Image Added

Conclusion

IWA is a valid and secure way for web sites to authenticate users over insecure networks such as the internet. The username and password are never sent in clear-text over the internet. It is just as secure as SSL, and uses visual cues to indicate to the user who is requesting their credentials. If the user trusts the web site, then they can feel comfortable submitting their credentials to it.

For GLAST users, since SCS has vetted the web site http://glast-ground.slac.stanford.edu/, they can trust that security is implemented properly and should feel secure in using it.