An Analysis of the Results of a Web Based Authentication Protocol

An Analysis of the Results of a Web Based Authentication Protocol Eric Galyon Colorado State University Abstract Authentication mechanisms and protocols have been developed for numerous reasons including enhancing security, increasing usability, decreasing the complexity of developing applications, and providing greater control and flexibility over the authentication process. Colorado State University has developed a web based authentication protocol, entitled ‘eIdentity WebAuth’, with these goals in mind. Since the fall of 2001, eIdentity WebAuth has operated as an authentication service for many web sites at the University. Although the service has been well received and been considered a success, no detailed analysis has been performed to verify eIdentity WebAuth has actually resolved the issues it sought to address. Has the University embraced and benefited from the service? Have users used and benefited from the service? Has the desired greater control and flexibility been achieved? Has security been improved? This paper presents a qualitative and quantitative analysis, using inferences for qualitative analysis and log information gathered since eIdentity WebAuth’s inception for quantitative analysis, and demonstrates the effectiveness and benefits derived from the development and deployment of the eIdentity WebAuth authentication protocol. More generally, the results illustrate that the rationale for authentication protocols is well founded and achievable. 1. Introduction Many authentication mechanisms and protocols have been developed to provide applications with an authentication service. These authentication services allow applications to authenticate against some pre-existing and established set of user credentials. Some authentication services, such as Kerberos or LDAP, have been developed to provide authentication service to client-server based applications such as telnet, ftp, or IMAP. Others, such as .htaccess files, PubCookie, Yale CAS, or Colorado State University’s eIdentity WebAuth, have been built to specifically target the needs of authenticating a user for a particular web page or web site. General goals, whether designed for clientserver or web based applications, of these authentication services are to: 1) Enhance security by eliminating the need to distribute and maintain credential stores on a per application basis and by protecting the centralized credential store to the greatest degree possible. 2) Increase usability by allowing end users to use a single, strong credential to access numerous applications instead of remembering and/or maintaining their credentials separately for each and every individual application. 3) Decrease the complexity of developing applications by abstracting authentication to a well defined service instead of redundantly requiring each application developer to plan and create their own authentication service. 4) Provide greater control and flexibility over the strength of the credentials and of the authentication process. eIdentity WebAuth, developed and deployed by Colorado State University in the fall of 2001, was developed with these goals in mind. A previous project in 2000 had lead to the creation and maintenance of user accounts for every student, faculty member, and staff member at the University. These accounts, called eIdentities, were already in use for many centralized services at the University but a desire existed to allow decentralized ser- -1- vices to use these credentials as long as strict security requirements were met. eIdentity WebAuth defines an authentication protocol decentralized web based applications can use to perform authentication against eIdentity accounts. eIdentity WebAuth has been in operation and been steadily logging information for several years. General feedback from the University web developer community indicates the service is successful however there has not been a specific study to find how effectively eIdentity WebAuth has addressed the issues for which it was developed. In this paper, the results of deploying eIdentity WebAuth are explored. Background information about the motivations behind and operation of eIdentity WebAuth are introduced in Section 2. Section 3 discusses how well eIdentity WebAuth has accomplished greater control and flexibility over the strength of the credentials and of the authentication process as well as how well eIdentity WebAuth has reduced web application developer complexity. Section 4 focuses on the adoption and utilization rates of eIdentity WebAuth. Section 5 focuses on the security enhancements. Finally, Section 6 summarizes with a generalization of the findings of the analysis of eIdentity WebAuth and the implications for other authentication services. 2. Background There were many motivations for developing eIdentity WebAuth. In its earliest conception, eIdentity WebAuth only attempted to provide a single, sharable authentication module for the eIdentity management applications. The applications developed to allow end users to create eIdentities, manager their passwords, update their e-mail notification addresses and policies, and allowing system administrators to investigate eIdentity problems and make corrections, all independently required authentication. The original goal attempted to modularize authentication to reduce redundancy. After implementing the solution specific to the eIdentity applications, there was a realization that with a small amount of generalization the solution could provide secure eIdentity authentication for any web based application. The motivation changed from creating a tool to simplify the development of the eIdentity applications to creating a general purpose tool that could securely extend eIdentity authentication to any number of web based applications. Information technology management at Colorado State University is distributed, complex, and diversified. Dozens of web servers, running on different platforms, hosting web applications written in many different dynamic web development languages exist. Many of the web based applications have a common need for authentication. Providing a single centralized web based authentication protocol, such as eIdentity WebAuth, assists University web developers by eliminating the need to create their own authentication mechanisms and manage their own set of user credentials. eIdentity WebAuth assists end users by allowing the use of a single set of credentials for numerous applications at the University. End user client requirements for eIdentity WebAuth have been minimized. The only required software is a modern web browser Figure 1: eIdentity WebAuth Process -2- with support for cookies and JavaScript. eIdentity WebAuth was designed to be architecturally neutral for web application servers using the service. No software or configuration specific to eIdentity WebAuth is required on the web server hosting a web application. This allows the protocol to be used on any platform and any web server. The only requirement is for applications to form HTTP GET web calls and process the results before returning them to the user. This requirement does result in constraints on the types of web applications which can use the protocol since it assumes the possibility of altering a web applications authentication process and assumes a dynamic web based application capable of performing server side processing prior to returning results. The eIdentity WebAuth protocol operates by establish a trust between a centralized authentication service and the decentralized web applications. Figure 1: eIdentity WebAuth Process illustrates the eIdentity WebAuth authentication process. All user credentials are sent to and verified by the central authentication server; no decentralized web server has access to the end users eIdentity credentials. Once validated, the trusted central authentication service returns a token to the decentralized web application. The web application uses the token to ask the centralized service for the authentication results, including who logged in and whether the login was a success or failure, which it must trust and process. 3. Credential Strength Control, Authentication Process Flexibility, and Reduced Complexity Several of the eIdentity WebAuth goals attempted to address qualitative issues. Existing authentication methods relied upon weak or non user friendly authentication practices. Existing authentication methods were decentralized and not flexible; implementing new initiatives into multiple decentralized authentication processes compared to a single centralized authentication process would have been difficult. Existing authentication methods relied on numerous, duplicate, localized code bases and elevated complexity. Though eIdentity WebAuth attempted to address these issues, quantifying the results is difficult. However, a qualitative analysis, relying on web developer and end user feedback as well as inferences concerning the alternatives, of the achievements of eIdentity WebAuth can be performed. Credential Strength Control Compared to the alternatives that existed prior to eIdentity WebAuth, the strength of credentials used by individuals for authentication has been improved. Prior to eIdentity WebAuth, there were three general authentication practices at Colorado State University: 1) Individuals could authenticate using their personal identification number (PID, which in nearly all cases was the person’s social security number) combined with either their date of birth or last name. 2) Individuals could authenticate using their PID/SSN and a 4 digit personal access code (PAC). This method was primarily used for phone and web based registration. Access to the PAC number was rarely granted to others. 3) Individuals could authenticate using a credential created and maintained by one of the eight colleges. A few of the colleges choose to not create and maintain individual credentials and either did not require authentication or, if they did, defaulted to the first mechanism described above. In one case, a college choose to allow each individual department (more than half a dozen of them) to create and maintain credentials specific to the students, faculty and staff within their area. In the first case, authentication was weekend by two closely coupled values performing authentication. If a malicious user learned someone’s PID/SSN, the accompanying information for authentication, whether last name or date of birth, wouldn’t be too hard to determine. In the second case, authentication was weekend by the use of a week password. PAC numbers were restricted to a 4 digit, purely numeric value. Since only 10,000 combina- -3- tions of PAC existed for any given PID, guessing and brute force mechanisms could potentially discover a PID/PAC quickly. The third case may have lead to stronger or weaker credentials depending upon the practices of individual colleges and departments. Although some colleges and departments required stronger password credentials than eIdentity, others did not. The resulting “lowest common denominator” did not enforce credential complexity as strong as eIdentity WebAuth does. eIdentity WebAuth has done more to raise the minimum credential complexity requirements than it has to reduce the complexity requirements of certain colleges and departments. Furthermore, the use of eIdentity WebAuth promotes a true common credential complexity infrastructure. If in the future, as is currently being investigated by Colorado State University, credential complexity is deemed too weak, enforcing a single change of the eIdentity credential complexity immediately elevates the complexity requirements for the entire University and globally addresses the problem. Authentication Process Flexibility Compared to the alternatives that existed prior to eIdentity WebAuth, greater flexibility has been achieved. Two practical examples of this flexibility exist. One has been implemented and in production since the Spring of 2003, the other is under consideration and will likely be implemented within the next year. Policy enforcement has been problematic for Colorado State University. If a policy is made that must affect each and every individual at the University, how can the policy be enforced? The available enforcement means of the past were rarely or never put to use. For students, the clearest way to enforce a policy change resulted in the creation and management of student holds on registration. For employees, the only similar tactic leads to withholding paychecks. The severe consequences of both of these actions resulted in few policies including true enforcement. eIdentity WebAuth has lead to a way to enforce certain policies without the harsh consequences of the past. Policy enforcement on an individual basis has been achieved using eIdentity WebAuth by preventing an authentication request from completing if/when a user has not met a mandated policies. User’s are not allowed to access any services protected by eIdentity WebAuth until they abide by all policies. While still heavy handed, the result is less severe than the previous alternative. The largest problem with the previous alternative involved timing. Students may not have known they were out of compliance with a given policy until the day they needed to register for a class. Employees may not have known they were out of compliance with a given policy until after they missed receiving a paycheck. In both cases, the worst case scenario involved the individual learning of their noncompliance with a policy at a very inconvenient time. By interrupting eIdentity WebAuth authentication, which ideally each individual uses regularly, each person is confronted with and can deal with their non-compliance with a policy in a much more timely and less aggravating timeframe. This process has been executed by eIdentity WebAuth once in the past and there are plans to use it in the future. In Fall 2002, a help desk issue was identified. Too many individuals were calling the University to request help with forgotten passwords. A new mechanism, allowing individuals to store and recall custom questions and answers, resolved the problem in the Spring of 2003. Unfortunately, there were more than 30,000 preexisting users which had not provided the necessary data for the new “Forgotten Password Help” system. The flexible policy enforcement ability of eIdentity WebAuth helped gather this information. The eIdentity WebAuth authentication process was modified to determine if the individual had or had not provided their “Forgotten Password Help” information. If they had not, their authentication attempt diverted them to a site that gathered the information before completing the authentication and sending them to the resulting web site. The interruption generated very few complaints and gathered the “Forgotten Password Help” information quickly and thoroughly for the more than 30,000 pre-existing users. -4- A similar process is under consideration for increasing password complexity at Colorado State University. Due to increasing identity theft, a new security policy has been adopted and increases the recommended complexity of passwords. In the future, a similar policy check to the “Forgotten Password Help” check will likely help enforce the changed password complexity policy. Reduced Complexity Compared to the alternatives that existed prior to eIdentity WebAuth, the complexity of creating and maintaining web sites that require authentication has been reduced. Section 4. Adoption and Utilization articulates the degree of reduced complexity in more detail by quantifying how widely eIdentity WebAuth has been adopted. One detail worth mentioning here relates to the number of web sites that have adopted eIdentity WebAuth. More than 50 web sites at Colorado State University have processed 500 or more authentications through eIdentity WebAuth. Having each of these 50 web sites create and maintain their own authentication mechanisms would be significantly more complicated than having each use the common framework provided by eIdentity WebAuth. 4. Adoption and Utilization eIdentity WebAuth has steadily recorded activity logs since its inception in October 2001. The log information includes who attempted to authenticate, which web site the user authenticated for, the precise date and time of the authentication attempt, and the result (success or failed) of the authentication attempt. In addition to the logs, all eIdentity information resides in a database. The eIdentity information includes links from the eIdentity account to a person’s information in various systems of authority to determine who “owns” the eIdentity and when the eIdentity account was created. By combining the eIdentity WebAuth log information with the general eIdentity information found in the eIdentity account database, descriptive statistics concerning the adoption and utilization of eIdentity WebAuth over time can be generated. 30000 25000 20000 Logins 15000 10000 5000 0 10/15/2001 4/15/2002 10/15/2002 4/15/2003 Date Successful Logins 10/15/2003 4/15/2004 10/15/2004 Failed Logins Figure 2: Total eIdentity Logins per Day One measure of eIdentity WebAuth utilization over time is a simple count of the total number of successful and failed logins per day. Figure 2: Total eIdentity Logins per Day shows the total successful and failed logins attempts for each day over the life-span of eIdentity WebAuth. The clearest change in activity occurred in August 2002. In the year prior to this time, eIdentity WebAuth had been restricted to only the eIdentity management web sites. Beginning in the summer of 2002, eIdentity WebAuth became available for use by other web developers at the University. The web front end to the student information system, entitled RamWeb, began testing eIdentity WebAuth in the summer of 2002 and launched the service in August of 2002. The large spike in utilization in August of 2002 relates to the incorporation of eIdentity WebAuth into the most frequently used web based application at the University. Since August of 2002, RamWeb has accounted for more than 87% of all eIdentity WebAuth logins. Other basic indicators of eIdentity WebAuth adoption and utilization involve simple counts and averages: - 253,910 unique person identifiers have attempted to authenticate with eIdentity WebAuth. - 133,722 unique person identifiers have successfully authenticated with eIdentity WebAuth. - eIdentity WebAuth has processed more than 5,500,000 authentication attempts. -5- eIdentity WebAuth Site RamWeb (student system interface) eIdentity Create eIdentity Modify Psychology 100 Research Misc. Other Sites Advising Network Enrollment Services Intranet Psychology Grades WebAuth CPIP (portal integration) Parking Services Accounts Receivable Web Housing and Dining Services University Relations CTSS Workshop Training Research PASS Advising Orientation RamWeb Administration Housing Convenience Accounts WebAuth CPIP Testing eID Password Help Housing Reservations Assessment Associates Database CTSS Workshop Admin. CTSS Repair Shop ACNS Software Downloads Psychology Undergrad Check sheet ARIES Project College of Veterinary Medicine All Other Sites Distinct Users 189671 62748 46082 8322 9417 5916 536 3677 5622 9063 306 607 2537 3179 1081 6622 347 3763 100 6302 4559 431 463 34 54 1203 1180 101 105 5780 Total Logins 4846166 131491 129932 108508 51756 50384 47027 40701 30443 23158 21489 19014 18294 15621 11734 11285 10974 10386 9057 9023 8841 7081 3917 3741 3182 3110 3057 2317 1797 23999 eID Logins 2266974 834 50989 108508 51094 50384 47027 40701 30443 23158 21489 19014 18294 15621 11734 11285 10974 4696 9057 2194 5136 7081 3917 3741 3182 3110 3057 2317 1797 23045 PID/PAC Logins 2579192 130657 78943 0 662 0 0 0 0 0 0 0 0 0 0 0 0 5690 0 6829 3705 0 0 0 0 0 0 0 0 954 Site Launch Date 3/26/2002 10/16/2001 10/15/2001 1/6/2003 10/12/2001 8/1/2003 1/31/2003 3/10/2003 7/21/2004 11/7/2003 10/24/2003 6/19/2003 9/28/2002 2/19/2002 2/19/2002 12/22/2003 5/16/2003 12/1/2003 4/7/2004 11/13/2002 6/12/2004 12/30/2002 10/19/2001 2/20/2002 7/1/2004 2/8/2005 3/4/2004 10/14/2003 3/6/2003 Figure 3: Top eIdentity WebAuth Site Statistics - eIdentity WebAuth has processed an average of 4,424 logins per day. - Under peak load, eIdentity WebAuth has handled 27,080 logins in a single 24 hour period. That equates to one login every 3.19 seconds. Under peak load, eIdentity WebAuth has handled 18,156 logins in a single 1 hour period. That equates to one login every 0.198 seconds or about 5 logins every second. - There have been 5,051,261 successful login attempts and 514,545 failure attempts. The average successful login to failed login ratio per day is 87.99%. - More than 50 web sites at Colorado State University have processed 500 or more authentication through eIdentity WebAuth. - Figure 3 summarizes the usage statistics for the 30 web sites that have registered the most number of logins. Ignoring the outlier of RamWeb, the remaining sites service a mean average number of 6556.4 users and have been logged into a mean average of 27,976.52 times. - Each distinct user has logged in an average of 25.53 times. These descriptive statistics indicate eIdentity WebAuth has been well adopted and used by the University community. Consider the alternative. If eIdentity WebAuth were not available, the accumulative total number of accounts needed by the 30 top web sites would have been 379,808 as opposed to the 133,722 managed by eIdentity WebAuth; that would be a 284% increase in the number of -6- 400 8 7 300 6 200 Number of Sites Hit 0 365 730 1095 1460 1825 2190 2555 2920 3285 3650 4015 4380 4745 5110 5 Number of Logins 4 3 100 2 1 0 Age of Account in Days 0 0 365 730 1095 1460 1825 2190 2555 2920 3285 3650 4015 4380 4745 5110 Age of Account in Days Figure 4: Number of Logins by Account Age Figure 6: Number of Site Hit by Account Age managed accounts. eIdentity WebAuth has saved the 50+ web sites the necessary cost and expertise of developing and maintaining these accounts separately. Other interesting trends become apparent by accounting for the age of the account. Figure 4 and Figure 6 compare the number of total logins and total number of distinct web sites visited by account age respectively. Figure 4: Number of Logins by Account Age begins with a clear annual trend which correlates to the times when new students create their accounts. Most new students create their accounts between the months of November, when new admits for the next academic year are being accepted, until August, the latest point at which new students create their accounts before registering for classes. The clearly identifiable lull that occurs annually during the first few years of data corresponds Month January February March April May June July August September October November December Student 62% 69% 71% 73% 59% 61% 57% 43% 35% 37% 60% 67% Employee 22% 19% 16% 12% 17% 13% 18% 28% 49% 46% 28% 21% Both 16% 11% 13% 15% 23% 26% 26% 29% 15% 17% 12% 12% to the months of September and October when most new accounts being created belong to faculty and staff members instead of students (Figure 5 shows the percentage of students and employees creating accounts for each month of the year). Additionally, the average number of logins per day for accounts 5 years old or less is much greater than for accounts older than 5 years. These two trends indicate students utilize eIdentity WebAuth many times more often than faculty or staff. The relatively rare spikes in the number of logins occurring in data older than 5-6 years indicate employees which either 1) have developed and maintain an eIdentity WebAuth site and therefore login regularly, or 2) rely on an eIdentity WebAuth protected web site to perform some part of their job and therefore login regularly. The number of sites hits by age of account, shown in Figure 6, also begins with a similar annual trend. Like the total number of logins, the trend shows that students use a greater number of eIdentity WebAuth protected sites. Interestingly, newer students have encountered a greater number of sites than older students. Current Freshmen, who generally created their accounts around 365 days ago, have encountered approximately 4-5 eIdentity WebAuth sites, Sophomores approximately 3-4 sites, Juniors approximately 2-3 and Seniors approximately 2-3. The increased use by Freshmen and Sophomores likely relates to new services oriented towards new incoming students such as Housing and Dining services and CASA advising services. Both of these services implemented eIdentity WebAuth in Figure 5: Account Creations by Person Type -7- 2003. Older students began their academic career before the new systems were in place and never needed to use them. Newer students have used them and therefore have a higher average number of sites hit. This demonstrates an increasing utilization and reliance upon eIdentity WebAuth over time as more and more services require eIdentity authentication. The descriptive statistics, time analysis of logins, and measure of activity by account age indicate similar trends. eIdentity WebAuth has become widely adopted and its importance as an authentication infrastructure at Colorado State University continues to grow. Students derive the greatest benefit although, based upon many spikes in the number of logins per day for accounts older than 5 years, many faculty and staff also rely on eIdentity WebAuth regularly. At present, each new incoming group of students has an increasing reliance on eIdentity WebAuth for both the number of sites they need eIdentity authentication for and the total number of eIdentity WebAuth logins they will generate during their academic career. 5. Security Analysis Many factors determine the overall security of eIdentity WebAuth. Three important among them are the transmission, storage, and processing of eIdentity credentials, indications of brute force cracking attempts, and arguments for or against centralized credentials. eIdentity Process Security The communication for the eIdentity WebAuth protocol is completely built upon HTTP and HTML. Like other secure web sites, the transmission from an end user’s web browser to the authentication web server relies upon the Secure Socket Layer (SSL) to encrypt the transmitted values. Once received, the authentication credentials are processed by accessing a secure, private credential store. In terms of transmission, storage, and processing of credentials, eIdentity WebAuth is at worst no more secure but at least no less secure than the standard practices employed by other secure web sites. eIdentity WebAuth, like any site secured through SSL, is vulnerable to traf- fic sniffing if a man-in-the-middle manages to position itself between the end users web browser and the authentication web server. The transmission of the authentication result from the eIdentity WebAuth server to the web application server using eIdentity WebAuth also employs SSL for transport and site authentication. A web application can only trust the authentication results returned by eIdentity WebAuth to the degree that it can trust the network path to the authentication server and that it can trust the SSL certificate returned by eIdentity WebAuth. As with end user browsers, a man-in-the-middle could potentially intercept and alter communications. This is an additional security risk introduced by eIdentity WebAuth. Sites implementing their own authentication need only concern themselves with the communication from an end user browser to their web server. eIdentity WebAuth enabled web sites must additionally worry about the communication path to the authentication server. Although this adds the potential for an additional threat vector, the use of SSL and difficulty in establishing a man-in-the-middle attack designed to detect and alter eIdentity WebAuth result transmissions make the risk negligible. Finally, as with any web site, eIdentity WebAuth cannot prevent a site spoofing attack. If an alternate web site is created to exactly mimic a web site using eIdentity WebAuth but at a different web address, and if end users do not carefully review the URL they are pointing at and the authenticity of SSL certificates, the spoofed site could gather end user credentials. Like with the other risks, eIdentity WebAuth neither reduces nor increases this risk. In general, eIdentity WebAuth does not attempt to address the limitations of SSL, manin-the-middle sniffing, or site spoofing. However, these exploits exist for any authentication method. At worst, eIdentity WebAuth is as secure as authentication methods web sites would have developed on their own. At best, eIdentity WebAuth is more secure since it enforces all credentials to be sent using an SSL connection; a condition that may not, and likely would not, be true if each service developed their own. -8- Indicators of Brute Force Cracking The logs used to analyze the adoption and utilization of eIdentity WebAuth can also indicate if brute force cracking methods have targeted eIdentity WebAuth. A trace through all of the logs on a per user basis, tracking the maximum number of failed login attempts in a row and the maximum amount of time between a failure and the next successful login attempt, yields interesting results. Figure 7: Maximum Number of Consecutive Failure Attempts shows the results of the trace. Surprisingly, 74% of all individuals have never failed an eIdentity WebAuth authentication attempt even a single time. 96% of all individuals have never entered an incorrect user name and password more than 3 times in a row. Only 10 of 253,910 unique users have ever had 40 or more consecutive failure attempts and the maximum number of failed attempts is 91. These numbers indicate that no systematic, dictionary or brute force Number of Users 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 More than 20 167845 30147 13460 6086 2772 1862 1237 665 414 314 244 157 112 67 61 44 26 26 16 21 10 68 Percent of Total 74% 13% 6% 3% 1% 1% 1% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 10000 1000 Number of Accounts 100 10 1 0 6 12 18 24 30 36 42 48 54 60 Time Minutes Hours Days 66 72 78 84 90 96 102 108 114 120 + Figure 8: Time from Failure to Success cracking attempt has ever been targeted at eIdentity WebAuth. eIdentity WebAuth also includes an ability to discourage brute force attempts if attempted. After 4 consecutive PID/PAC failures or after 8 consecutive eIdentity failures, an account is locked out for a period of 20 minutes. These trace statistics indicate that this value is more than generous and probably rarely invoked. Even if the brute force prevention were engaged after 3 instead of after 8 consecutive failure attempts, 96.4% of all individuals would have never triggered the account locking. The trace also gathered information concerning the length of time it took someone when their maximum consecutive failure attempts began and their next successful login. Figure 8: Time from Failure to Success plots the number of users and length of time in minutes, hours or days it took to resolve their login problem. 90% of all users have never been unable to login through eIdentity WebAuth for a period of longer than 5 minutes indicating people either made typos they quickly corrected or remembered their correct password fairly quickly. There are clear trends on an hourly basis. Specific jumps at 24, 48, 72, and 96 hours occur indicating individuals either remembered (or found the sticky they had written on) their password after day long intervals or they seek help resetting their password after day long intervals. These trace results indicate eIdentity WebAuth has, to date, been secure against brute Failed Attempts Figure 7: Maximum Number of Consecutive Failure Attempts -9- force measures without reducing usability. The vast majority of individuals authenticate with little hassle. Even when authentication problems are encountered, they appear to be dealt with in a timely manor. If anything, the brute force prevention mechanism could be tightened from the present trigger level of 8 consecutive failures to 5 or even 3 consecutive failures without adversely affecting very many people. Arguments for and Against Centralized Credentials As addressed in Section 3. Credential Strength Control, Authentication Process Flexibility, and Reduced Complexity, eIdentity WebAuth has helped elevate the “lowest common denominator” of password complexity. However there is a tradeoff to this approach. eIdentity, as a single-sign-on or common-signon credential to numerous applications, becomes a key to all kingdoms. Although the password complexity is greater, so is the size of the threat if the eIdentity password is compromised. Consider again the reduced complexity example of the 50 web sites implementing their own authentication mechanisms. Without eIdentity WebAuth, a compromised credential may only grant access to 1 of the 50 web sites. With eIdentity WebAuth, a compromised credential would immediately grant access to all of the 50 web sites. Although no measures to reduce this threat are in place for eIdentity WebAuth today, the counter argument relates to the ability to globally deploy strong authentication measures such as two-factor authentication or biometric authentication. As with web based authentication, having 50 separate sites deploy their own two-factor or biometric authentication solutions would quickly escalate complexity. If, however, eIdentity were supplemented with the ability to perform two-factor and/or biometric authentication, any or all of the 50 applications could immediately benefit from the increased security. Arguments against the singular keys-to-the-kingdom approach to security, advocating instead a key-per-kingdom approach, lead to scalability problems, increased management complexity, and decreased end user usability. Centralizing authentication with options for high levels of security for those who require it seems the more rational approach. 6. Summary Analysis of eIdentity WebAuth through qualitative comparisons to the alternatives and quantitative analysis of log files indicates eIdentity WebAuth has been a successful service for Colorado State University. The “lowest common denominator” of credential complexity security has been elevated. The added flexibility of having a centralized authentication protocol has assisted in enforcing policy decisions made by the University. The job of a web developer has become slightly less complicated and more focused by eliminating the need to redundantly design and deploy a proprietary authentication solution. Statistics indicate eIdentity WebAuth has been well adopted and utilized by the University community, although students benefit much more than faculty and staff members. The security of eIdentity WebAuth is at worst no better but at least no worse than the alternatives. More generally, this analysis relates to other authentication protocols. Like eIdentity WebAuth, authentication protocols designed to increase security, increase usability, decrease complexity, and provide greater control and flexibility, are achievable. Based upon the eIdentity WebAuth results, the principles behind developing and supporting authentication protocols are well founded and achievable. References Kohl, J, and C. Neuman. “RFC 1510 - The Kerberos Network Authentication Service (V5)”. September 1993. Wahl, M., T. Howes, and S. Kille. “RFC 2251 – Lightweight Directory Access Protocol (v3)”. December 1997. The NSF Middleware Initiative. http://www.nsfmiddleware.org/, http://www.nmiedit.org/development/index.html Kerberos papers and documentation. http://web.mit.edu/kerberos/www/papers.html - 10 -