FULL TITLE HERE IN ALL CAPS IN A FORMAT



The Investigation of Single Sign-On (SSO) System SecurityA thesis submitted by Xiang Tan to the Department of Computer Science at the University of Colorado Colorado Springs, in partial fulfillment of the requirements for the degree of Master of Engineering focus on Information Assurance.2015This thesis for the degree of Master of Engineering focus on Information Assurance byXiang TanHas been approved for the Department of Computer Scienceby______________________________Dr. Chuan Yue, Chair______________________________Dr. C. Edward Chow______________________________Dr. Jia Rao_____________________DateABSTRACTToday’s networking access security has faced a new challenge from web SSO phishing attacks. Now providing social login service becomes a norm among popular Internet software companies, more and more Internet users choose to accept their social media profile as their identities to connect web applications. Whether to share stories and videos to friends or access web games, all-in-one online credential seems to be a necessary convenient tool for daily Internet lives. The lack of understanding of web SSO user authentication system and its risk among Internet users can lead to potentially catastrophic damage to their privacy data. As web SSO has increasingly gained popularity, scientists and engineers in computer security fields have started to pay attention the security risks from this fast grown phenomenon. In this thesis, the implementation of an alternative web SSO user authentication concept to connect with common social login service providers are presented. Phishing attacks against web SSO user authentication system is an area of intense research. This thesis presents the base for the alternative practice, which I called redirection method. Using JavaScript and web browser extension, the redirection method, governed by OAuth 2.0 protocol specification, provides an easy to understand model that also create a system that Internet users can quickly identify phishing attempts with. The results are analyzed from the data gathered from a focus group study. The results show that Internet users do not have sufficient knowledge to counter phishing attacks against web SSO user authentication systems; more social media security oriented training can be beneficial to all Internet users. The current web SSO authorization process has security issues that need to address, and the redirection method can be beneficial to improve the security of web SSO system.ACKNOWLEDGEMENTSI would like to use this opportunity to express my special appreciation and thanks to my advisor, Dr. Chuan Yue, you have been a tremendous mentor for me. I would like to thank you for encouraging my research and for allowing me to grow as a researcher. His advice on both research as well as on my career have been priceless. I would also like to thank my committee members, Dr. Jia Rao and Dr. Edward Chow for serving as my committee members. You made my Thesis defense process to be an enjoyable moment, and your critics and suggestions during proposal and defense are valuable to my research.I thank all the volunteer participants, who attended my focus group study sections for their valuable comments and feedback. I thank the inventors and maintainers of all the open source software projects used to implement in this thesis study: Nginx, JavaScript, jQuery, Firefox extension, MySQL, PHP, and statistical analysis tool R.TABLE OF CONTENTSChapterPage TOC \o "1-3" \h \z \u ABSTRACT PAGEREF _Toc416377873 \h iiiACKNOWLEDGEMENTS PAGEREF _Toc416377874 \h vTABLE OF CONTENTS PAGEREF _Toc416377875 \h viLIST OF TABLES PAGEREF _Toc416377876 \h viiLIST OF FIGURES PAGEREF _Toc416377877 \h viiiCHAPTER I: INTRODUCTION PAGEREF _Toc416377878 \h 1CHAPTER II: BACKGROUND PAGEREF _Toc416377879 \h 4I.SSO AUTHENTICATION PAGEREF _Toc416377880 \h 4II.WEB SSO AUTHENTICATION PAGEREF _Toc416377881 \h 5III.PHISHING PAGEREF _Toc416377882 \h 11CHAPTER III: RELATED WORK PAGEREF _Toc416377883 \h 14CHAPTER IV: HYPOTHESES PAGEREF _Toc416377884 \h 17I.RESEARCH GOALS PAGEREF _Toc416377885 \h 17II.PROTOCOL PAGEREF _Toc416377886 \h 18CHAPTER V: METHODOLOGY PAGEREF _Toc416377887 \h 23I.TAB METHOD PAGEREF _Toc416377888 \h 24II.REDIRECTION METHOD PAGEREF _Toc416377889 \h 27III.FOCUS GROUP STUDY PAGEREF _Toc416377890 \h 35CHAPTER VI: RESULTS AND ANALYSIS PAGEREF _Toc416377891 \h 43I.DATA COLLECTION PAGEREF _Toc416377892 \h 43II.DATA ANALYSIS PAGEREF _Toc416377893 \h 51CHAPTER VII: RECOMMENDATIONS PAGEREF _Toc416377894 \h 74CHAPTER VIII: CONCLUSION PAGEREF _Toc416377895 \h 75Appendix A: JAVASCRIPT LIBRARY PAGEREF _Toc416377896 \h 78fb.js PAGEREF _Toc416377897 \h 78Appendix B: FIREFOX EXTENSION PAGEREF _Toc416377898 \h 82/install.rdf PAGEREF _Toc416377899 \h 82/chrome.manifest PAGEREF _Toc416377900 \h 82/locale/en-US/overlay.dtd PAGEREF _Toc416377901 \h 83/skin/overlay.css PAGEREF _Toc416377902 \h 83/chrome/content/browser.xul PAGEREF _Toc416377903 \h 83/chrome/content/ssologin.js PAGEREF _Toc416377904 \h 83GLOSSARY PAGEREF _Toc416377905 \h 88REFERENCES PAGEREF _Toc416377906 \h 89LIST OF TABLESTablePage TOC \h \z \c "Table" Table 1 Data value before Facebook Web SSO authorization PAGEREF _Toc416377907 \h 33Table 2 Data value after Facebook Web SSO authorization PAGEREF _Toc416377908 \h 35Table 3 Focus group study – the entrance questionnaire PAGEREF _Toc416377909 \h 39Table 4 Focus group study – the discussion questions PAGEREF _Toc416377910 \h 42Table 5 IRB Informed Consent PAGEREF _Toc416377911 \h 48Table 6 Focus group study - invitation email template PAGEREF _Toc416377912 \h 49Table 7 Participants’ feedbacks from phishing attacks against the popup window method PAGEREF _Toc416377913 \h 71LIST OF FIGURESFigurePage TOC \h \z \c "Figure" Figure 1 OAuth 2.0 Authentication Process Flow [5] PAGEREF _Toc416377914 \h 7Figure 2 OpenID Protocol [5] PAGEREF _Toc416377915 \h 9Figure 3 and Yahoo! Mail web SSO logins PAGEREF _Toc416377916 \h 11Figure 4 Facebook Login with the popup method PAGEREF _Toc416377917 \h 25Figure 5 Facebook Login with the tab/redirection method PAGEREF _Toc416377918 \h 29Figure 6 Session log after Facebook Connection authorization PAGEREF _Toc416377919 \h 34Figure 7 Survey question 1: Do you know what web Single Sign-On user authentication is, i.e. Facebook? PAGEREF _Toc416377920 \h 52Figure 8 T-test result of survey question 1 PAGEREF _Toc416377921 \h 53Figure 9 Survey question 2: Do you know what Phishing Attack is? PAGEREF _Toc416377922 \h 54Figure 10 T-test result of survey question 2 PAGEREF _Toc416377923 \h 55Figure 11 Survey question 3: Do you know the Phishing Attacks against SSO user authentication? PAGEREF _Toc416377924 \h 56Figure 12 T-test result of survey question 3 PAGEREF _Toc416377925 \h 57Figure 13 Survey question 4: How often do you use Facebook or Google+? PAGEREF _Toc416377926 \h 58Figure 14 T-test result of survey question 4 PAGEREF _Toc416377927 \h 59Figure 15 Survey question 5: How often do you use Sing Sign-On to log into other websites? PAGEREF _Toc416377928 \h 59Figure 16 T-test result of survey question 5 PAGEREF _Toc416377929 \h 61Figure 17 The average scores of the survey questions PAGEREF _Toc416377930 \h 62Figure 18 Focus group study Q1a PAGEREF _Toc416377931 \h 64Figure 19 Focus group study Q1b PAGEREF _Toc416377932 \h 65Figure 20 T-test result of Q1a and Q1b PAGEREF _Toc416377933 \h 67Figure 21 Focus group study Q2 PAGEREF _Toc416377934 \h 68Figure 22 Focus group study Q3a PAGEREF _Toc416377935 \h 70Figure 23 Focus group study Q3b PAGEREF _Toc416377936 \h 72CHAPTER I: INTRODUCTIONThe software industry is in the midst of changing how users identifying and accessing web applications. There are unaccountable number of different applications and security databases within the industry today. Many organizations have their own internal applications and databases and social media websites. For examples, Facebook and Google have multiple web applications. Many of these applications are third party software or developed by different teams, it is rare that all these different components that make up a company’s internal information system or websites are managed and maintained by following the same standards. Each of the system requires username and password, and their restrictions vary from the software design.It is really frustrating to memorize all usernames and passwords. To the purpose of reducing users’ frustration, a system called Single Sign-On (SSO) was developed to remove the heavy burden from registering and memorizing many accounts and their difficult passwords, and to ease the needs of each user repeatedly typing their credential to each application.What is SSO? A simple definition is the software, which has an ability to authenticate once and never have to repeat the process for duration of a defined session period. A web SSO is software that an authentication service provider installed on web servers; it is a central infrastructure that includes a directory service and logic of managing authentication and access control.Like any other systems in the world, there are risks with web SSO. Embedded login forms can be used in an attack to steal users’ login credentials. Users enter their usernames and passwords into popup windows when requesting SSO from a website. In theory, the login forms are controlled by the Identity Providers (IdPs), which means the websites that bridge between users and the authentication servers do not have a way of manipulating embedded login forms. Nonetheless, this mechanism brings two major issues to us. Users supply their credentials in plaintext to the login forms, and believe these forms are directly connected to the authentication servers without verifying the true owners of the popup windows. It is correct that websites cannot alter the source code of the embedded login form popup windows; however a malicious attacker can create a fake form that looks similar to what IdPs provide. Users who are not aware of phishing attacks or do not look carefully enough will give their credentials away but think accessing their authorized IdPs. My contributions to this field of research are:A redirection method to present a safer web SSO user authentication process that requires less technical knowledge from the Internet users.An implementation to replace the current popup window method with minimum modification of websites.A focus group study evaluates the processes between the redirection method and the popup window method.In the following sections, I will discuss the background (Chapter II), related works (Chapter III) and hypotheses (Chapter IV) of my thesis study; I will then summarize the methods (Chapter V) I used to gather data, describe the results (Chapter VI); discuss related and possible future work (Chapter VII) and the conclusion of this thesis paper (Chapter VIII).CHAPTER II: BACKGROUNDSSO AUTHENTICATIONSSO system has been with us long before Facebook’s or Google’s web SSO systems were introduced. Whether to access a workstation or virtual machine in company or school, an employee or a student can just type in his/her email account and password to access any computer inside the network. This system is called Enterprise SSO. Companies like Microsoft, Oracle and Dell, etc., all have enterprise SSO services provided from their enterprise level products.Kerberos authentication is an enterprise SSO, a directory service database that performs authorization. It was developed as a part of Project Athena by MIT in May 1983. The goal of the Project Athena was to create a SSO system that unified network file system and a naming convention service. It uses secret-key cryptography to supply authentication for web applications or executable between servers and clients. Microsoft developed Active Directory (AD) as a directory management tool to control Windows directory. AD adapts the Kerberos process to authorize users and machines to communicate within a Windows domain network. When a user logs into a single Windows domain network, the login process contacts a part of Kerberos called the Authentication Service (AS). The user requests a Ticket Granting Ticket (TGT) from the AS and the AS responds by looking up the user’s password hash, which it then uses as a key for encrypting the session key. The user’s login process attempts to decrypt the session key using the user’s password hash as the encryption key. If it is successful, the user may then use the TGT received to logon. It handles all user authorization within Active Directory. Apart from the single domain network, when building a trusts relationship between multiple domains, an account from domain A wants to be authorized in domain B; both domain A and B must accept each other. CITATION MIT \l 1033 [1] CITATION Dia12 \l 1033 [2].Lightweight Directory Access Protocol (LDAP) is a directory standard, developed by University of Michigan to adapt X.500, it runs over TCP/IP. As an authentication protocol, LDAP serves a broader purpose than Kerberos; it not only administers directory services like Kerberos, but also provides records of user information and equipment. Each record is called an entry in the world of LDAP, an entry can be an address book, a user profile, a document, or printer information; it stores all attributes of a LDAP object; LDAP references a LDAP object by its Distinguished Name (DN). DN contains a series of related distinguished names, which makes the entire DN a unique identifier. For example, my exchange account in UCCS is xtan@uccs.edu, the DN of such account is “CN=Xiang Tan,OU=People,DC=uccs,DC=edu”, where CN is the common name, OU is the organizational unit name, and DC is the domain component. A sequence of domain component attributes formulates the domain name. As the example above, “DC=uccs,DC=edu” gives us “uccs.edu”. Within the authorized network, a user or an application can retrieve information about an entry by its DN CITATION Tut04 \l 1033 [3]CITATION JSe06 \l 1033 [4].WEB SSO AUTHENTICATIONThe concept of web SSO is to capture the user credential once it is entered and uses it to access each application on behalf of the user without prompting the login form again in the same login session. The web SSO is a little different from the enterprise counterpart; it focuses on web based applications; some popular examples are the Facebook SSO or the Google API. It generally has a centralized IdP, which is an online account management tool that simplifies personal profile sharing throughout the Internet.OAuth is an authorization standard, which provides the client applications a way to access server resources on behalf of the resource owners without sharing the resource owners’ credentials. Communications between clients and servers are specifically designed to work with Hypertext Transfer Protocol (HTTP). The current version of the OAuth authorization framework is 2.0 which is not backward compatible with the previous version. It provides simple authorization flows for third-party client developers to create their applications. Unlike the standard client/server authentication process, which the server is required to store client credential and deal with the resource owner directly, the third-party client with OAuth authentication model acts like a manager between the resource owner (i.e. the user) and the resource. REF _Ref415690192 \h Figure 1 illustrates that the resource server receives a resource request from the resource owner; it initiates an authorization request to the resource owner. The resource owner supplies his/her username and password to the third-party client. The client does not store the resource owner’s credential, instead sends them immediately to the authorization server. The authorization server generates an access token for the third-party client to access the resource server if the credential is correct. The access token is a string of encrypted characters follows by the formats created authorization server, which will be stored by the third-party client until it expires; it becomes the key for the third-party client to request any secured resources from the resource server. With the unique connection that has been set up between the third-party client and the resource server, the resource owner can request the resource from the resource server without the resources owner’s password being entered again until the access token expires CITATION DHa121 \l 1033 [5].Figure SEQ Figure \* ARABIC 1 OAuth 2.0 Authentication Process Flow CITATION DHa121 \l 1033 [5]The idea of OpenID is to reduce the burden of memory multiple passwords for Internet activity. All web applications, including emails, online banking and social media websites, require Internet users to set up passwords. A Microsoft research paper states that an average user has around 25 accounts and creates 6 sets of passwordsCITATION Flo07 \l 1033 [6]. Creating a password for an individual web account is rather difficult considering all the different rules needed to be followed, some of rules regulate that the password cannot have special characters such as * or @; some must contain at least several digits of capital letters, numbers, special characters, and the password will expire every six months. On top of that, the users have to memorize all those passwords and know exactly which corresponding web accounts they use for. This inconvenience, caused by the web today, is based on a site-centric approach.OpenID suggests a user-centric approach. It separates the authentication process from the third-party clients that communicate between the Internet users and authorization servers. Internet users do not need to create different login credentials for each individual third-party clients to access the resource, but use one identity from an IdP. There is a list of IdPs on the Internet; examples are Facebook, Google+, Yahoo!, etc. The identifications provided by those IdPs are called OpenID. In REF _Ref415690317 \h Figure 2, Relying Providers (RPs), a.k.a. the third party clients, initiate OpenID providers’ functionalities by adding their Software Development kits (SDKs) into their websites. SDKs belong to IdPs, thus the third-party clients do not control contents of the login forms. An Internet user submits a user authentication request from the SDK, which embedded on the third-party client website; SDK calls its original domain and generates the OpenID login form inside DOM of the third-party client web page. The user agrees to authorize the RP, to access his/her information by submitting his/her username and password into the login form, which are sent to the OpenID Provider for authentication. Given that the user inputs his/her identity within the IdP’s domain, the third-party client cannot record any information from the user from the user authentication process. Information related to identifier of the third-party client is embedded in the Uniform Resource Locator (URL) of the login form, which also is sent to the OpenID Provider along with the user’s credential via HTTPS. OpenID Provider receives the user’s approval and responds back an access token to the RP if the credential from the user is correct and the third-party client is valid with its client identifier; this access token will validate the RP to request more information on behalf of the user from the source server CITATION NSa13 \l 1033 [7] CITATION Sun11 \l 1033 [8]. Figure SEQ Figure \* ARABIC 2 OpenID Protocol CITATION DHa121 \l 1033 [5]The whole process stated above does not require existing trusted relationship between OpenID Provider and the RP. Different from the Enterprise SSO, which has a preset relationship via Kerberos, all necessary communications of OpenID protocol are through the URL.OpenID connect is a protocol from OpenID with a more API support. It can communication with multiple media, such as web-based application, mobile apps or JavaScript fat clients. It also supports extensibility so that web application developers can add necessary functions such as encryption on top of the OpenID protocol. The OpenID connect sits on top of OAuth 2.0 protocol as an identity layer. Internet users submit their credentials from their favorite OpenID providers; OpenID connect uses users’ credentials as authenticate identities to log into other applications. OpenID providers make decision on whether the account is certified. An authorization server, which contains the OpenID Connect Core specification, verifies users’ identities based on the OAuth 2.0 protocol. The Facebook Login and Google API use OAuth 2.0 open protocol for authentication and authorization. It identifies users’ identities and controls of information related to specific accounts and returns to RP CITATION NSa13 \l 1033 [7] CITATION Sun11 \l 1033 [8].OpenID provides who the users are; OAuth grants access to functionality and data from the IdP. OAuth issues an access token during authentication process. An Internet user is a resource owner. The user enters his/her username and password to the RP website; the RP delivers the resource owner’s identity information to authorization server for authentication along with its own client ID. Once the handshake between the third-party client and the authorization server was successful, the authorization server authenticates the RP and generates a string of variables as a key to access the resource server. This key is called access token. The RP can use this access token to retrieve resources from the resource server on behalf of the resource ownerCITATION DHa121 \l 1033 [5].Web developers do not need to concentrate on building security into their applications. An enforcement agent is put in place to intercept web traffic and authenticate the user against the central authentication server.Web SSO phishing attacks come under the spot light of web application security since web SSO became more and more popular on the Internet today. The web SSO phishing attacks give hackers more value than the traditional phishing, because users’ web SSO credentials can access multiple web applications that integrated with web SSO system. Figure SEQ Figure \* ARABIC 3 and Yahoo! Mail web SSO loginsThere are many services providers that provide identities today. REF _Ref415730611 \h Figure 3 shows and YAHOO! Login forms. Both of the login forms have integrated with IdPs for identifications. Facebook Connect and Google+ are Facebook’s and Google’s version of OpenID systems.When Internet users try to leave comments on CNN news articles or log into Yahoo! email accounts, they can pick the options to sign into each respective web application with local user accounts or web SSO providers such as Facebook Connect, Google+ and many others. The Internet users can use their identities created from Facebook or Google as their default profile to access any other web applications. This approach reduces the time Internet users consumed to register every individual websites, and the effort to memorize all username and password combinations they registered at the websites.PHISHINGPhishing is a way of attempting to acquire Internet users’ information, such as their usernames and passwords. The traditional phishing attacks mainly reside within emails to lure users into clicking on malicious web links. These web links may appear to be legitimate, but in reality, they send the users to phishing websites created by hackers. Once victims follow the spoof links to the phishing websites and give away their private information, phishing websites record this information and may redirect the victims to the real websites. Phishing attacks can also be done by using online chat programs; attackers trick users to click on web addresses attackers provide in chat sessions, or convince users to give away their private information during conversations. In the modern day, phishing attacks even spread to VOIP, SMS and online multiplayer games. All phishing scams persuade victims to disclose their credentials by accessing malicious web links or by calling unknown phone numbers. It is not difficult for average users to detect traditional phishing attacks. For suspicious web links, the users can either hover over the web links before clicking on it, or copy the link and paste into text editors. If the information shows differently than what the links are supposed to be, they are mostly likely phishing scams. Once the users detect phishing scams, they can simply ignore the suspicious web links. Users can also disable JavaScript to avoid accessing JavaScript generated web links. It is hard to understand a web address with a long non-human-readable string of characters. Many users just use “look suspicious, skip it” approach. During conversation in live chat programs, chat users need to be aware of these attacks and never reveal their sensitive information. As for phone phishing attacks, users need to make sure to call the destinations only with official provided phone numbers CITATION Dow06 \l 1033 [9] CITATION DrB13 \l 1033 [10] CITATION Kum08 \l 1033 [11].Web SSO phishing attacks use a similar concept but a different approach. Since the login forms inside a SSO popup window are SDKs from authentication servers, it is difficult to modify the SDKs’ contents when the they are created on different domains; it is also impossible for hackers to customize the output of any SSO system without cooperation with the IdP.Hackers’ new trick is to create an entire login window on their own domains. When attackers create a fake RP website that seems to integrate with popular web SSO IdPs, They can use JavaScript to create a division element similar to a legitimate popup window from the read IdP. Once the Internet user visits the fake RP website and clicks on the login link to initiate the web SSO user authentication process, the malicious JavaScript code dynamically creates a spoof login form inside the division element. The Internet users are led to believe that they are using the genuine SDK from the actual IdP without second-guessing the rightfulness, but instead the malicious code records the users’ credentials into the databases before sending the user to the real authentication server CITATION Ell02 \l 1033 [12] CITATION Chu \l 1033 [13].CHAPTER III: RELATED WORK In the modern day of Internet, many API supports are provided from social media companies. Web developers are encouraged to apply web SSO user authentication based on the OAuth 2.0 authorization protocol. Chetan Bansal et al. CITATION Ban12 \l 1033 [14] presented an analysis about attacks on web SSO user authentication systems. The authors described a web based attack called Cross-Site Request Forgery (CSRF) against OAuth web authorization vulnerabilities. In their model, they constructed tools to successfully breach social logins with token redirection, etc. In the version of OAuth 2.0, the protocol attempted to remediate token redirection attacks via its redirect URL being validated with the authorization key exchange.In a research paper about investigating OpenID, Dr. San-Tsai Sun CITATION Sun11 \l 1033 [8] and his colleagues studied how human subjects reacted to the common web SSO practice and how to improve the common OpenID process. Their study learned that most Internet users did not fully understand the concept of OpenID SSO authentication. Their participants had security misconceptions, because they thought that the RP and the IdP were integrated together and sharing users’ private information. Because of concerns of phishing attacks, their participants did not want to use web SSO user authentication system at the present time.The IdPs provide third-party clients with SDKs for integration and security measures. Rui Wang et al. CITATION Wan13 \l 1033 [15] analyzed the models of major SDKs to understand their design assumptions and security issues related to these assumptions. IdPs such as Facebook and Google+ develop SDKs for web SSO user authentications; third-party developers follow the SDK documentations to integrate user authentication systems provided by IdPs onto their websites. However, some implicit assumptions that SDK providers have concerned may not be considered by the third-party developers. An example the authors stated was about the session security of the Facebook SDK. Facebook PHP SDK uses PHP session variables to store data assigned to the specific user ID. Facebook offers a free cloud base service on , where I used to perform various testing too. PHP shares its sessions throughout the entire domain, therefore, each session variable from subdomains of can communicate to other subdomains, which can lead to session hijacking. It is technically neither SDK providers nor application developers’ fault, but an assumption violation.Internet users use their web SSO accounts to access multiple websites. This behavior made these accounts higher value target than traditional local accounts from individual websites, because it required less effort to attack multiple web applications. The existing way of verifying a phishing scam is to validate the URL; however this method does not work with web SSO since a real RP website can still carry out phishing attacks with a spoofed popup window to trick users to log in. When Internet users hover over a web link of social login, it commonly presents a JavaScript function. It is difficult for average Internet users to determine whether this link is malicious. So are Internet users ready for this new form of phishing attacks against web SSO? Dr. Chuan Yue CITATION Chu \l 1033 [13] conducted a survey research study about phishing attacks against SSO Systems. He found out that majority of his participants failed to recognize the spoofed login web pages from his demonstration. The participants could not tell the differences. One of the simple methods to determine the legitimacy of a popup window URL was to check the SSL certificate to the left most of the address bar; nonetheless none of his participants had checked SSL certificate. Given that the popup windows was the essential part of the web SSO popup window process, and the popup windows failed to provide enough information for users to determine the rightfulness. An alternative approach is clearly desired to replace the popup window process. CHAPTER IV: HYPOTHESESRESEARCH GOALSWeb SSO user authentication system is relatively new technology to the Internet. It suffers from the lack of well-defined security protocols and procedures. Security is a big concern in programming world today; developers may spend extra resources to make systems more secure. However the users may want simplicity; a complex system that requires users to perform a series of tasks can cause the users to stay away from it. This study is to find a web SSO user authentication system on balance between protection and easiness. The research goals are:To investigate if the redirection method is easier to understand than the popup window method in web SSO user authentication.To investigate if the redirection method can help Internet users identify phishing attacks more easily than the popup window method.In this thesis paper, I want to test the following hypotheses:There is no difference between the redirection method and the popup window method in term of easiness for users to understand web SSO user authentication.There is no difference between the redirection method and the popup window method in term of helping users identify phishing attacks.PROTOCOLUnlike most enterprise or academic network environments, the existing web SSO systems integrated on social media websites are open to the whole world. Every web developer can integrate the web SSO systems from most popular IdPs. Facebook Connect provides Facebook Login APIs for developers to incorporate the Facebook authentication to the developers’ websites. There is a great list of documentation about Facebook Login on the Facebook Developers website and many developer communities’ forums. The bottom line is that a web SSO user authentication system is very easy to implement; unfortunately, hackers can easily build one as well. It is not onerous to generate a spoofed web SSO Login popup window by using a HTML division element and a little trick with CSS z-index property. Internet users believe that they click on legitimate web SSO login pup windows without knowing how to differentiate the real web SSO applications from the malicious software, which can cause their accounts to be compromised. According to Dr. Yue’s the Devil is Phishing paper CITATION Chu \l 1033 [13], 86% of users have heard about phishing attacks, however 61% of all participants could not differentiate a spoofed SSO login page from the real one. Identifying the genuine web SSO application login form from phishing attacks is not an easy task even for experienced users who had some basic knowledge about traditional phishing attacks. The old practice of detecting traditional phishing does not work with web SSO phishing attacks CITATION Chu \l 1033 [13]. Hackers can modify any parts of the web contents under their own domains, but they cannot force any changes to the address bar in web browsers (DNSSEC and Browser security is beyond the scope of this thesis). Internet users can identify the integrity of the web address inside the address bar. I have drafted two alternative methods with the use of the browser address bar to replace the current popup window method. One method is to utilize browser Tabbed Document Interface (TDI) - I name this design the tab method; the second method is to send the Internet users from the third-party client website to the authentication server website directly and redirect back to the original website within the same browser tab - I describe this method as the redirection method. Both alternative methods follow the idea of letting the Internet users view the URLs of the login forms from the main web browser’s address bar. The difference is the technique to return back to the original third-party websites. The tab method is similar to the current popup window method, but instead of using a popup window, the script initiates the process on forcing the SDK into another browser tab. The redirection method keeps all the processes in the same tab; the concept is to save the data related to the login process in the session storage of the web browser while allowing users to go back and forth between different web pages.The alternative user authentication system, either the tab method or the redirection method, aims to satisfy two conditions: it can perform all functionalities of the current popup window method and keep security measures in check; it is feasible, easy to understand, and allows users to identify phishing attack attempts effortlessly. Once the method is defined, the implementation needs to apply not only to websites that have not yet integrated with web SSO authentication systems, but also to websites that already incorporate with web SSO authentication systems.For a website that wants to add social login functions, it can be accomplished by inserting a JavaScript library to the existing website. The JavaScript library should:Authenticate web SSO users’ accounts by following the OAuth 2.0 redirect specification.Store the form data from the RP websites.Transfer users between the RP websites to the IdPs’ authentication servers via the HTTP Secure channel.Retrieve and store authorization tokens.Add an interactive media such as a link or a button on the website with minimum modification of the original source code if social login features haven’t been introduced.JavaScript can provide a search function to replace any existing elements from DOM without causing too much trouble. However it is rather insufficient to add the JavaScript library into every website that has already integrated with social logins. Modifying existing source code becomes tiresome if the web developers have to manage multiple third-party client websites. Browser extensions allow web application developers to add extra functionalities to web browsers without needing to dive into web contents; since browser extensions are integrated to the browsers, they work with multiple websites. With these nice features, the third-party clients do not need to replace their previous web SSO authentication application system individually with the JavaScript library, but simply supply a browser extension to their resource owners. The browser extension needs to follow the same design scope as the JavaScript library. My next task is to determine whether the alternative user authentication system is easy to understand and use, I have outlined a focus group study in order to collect opinions from random users. It also serves the purpose of determining whether different education backgrounds can cause diversified understanding about the concepts of web SSO user authentication system and detection of phishing attacks. There were 20 participants separated into multiple sections of the focus group study. Each section was half an hour long, and had 3 to 5 participants to discuss web SSO user authentication and security.I did not believe age was going to alter the results, because the participants were faculty, staff and students of the university; the age range was predictable. Pew Research Center’s Internet and American Life Project stated that Internet users between the ages of 18 to 50 were likely to visit some type of social media networks, such as Facebook, Twitters or Instagram CITATION Dug13 \l 1033 [16]. The possibility of finding a participant, who had never heard about social media networks, was going to be slim. I did not believe that gender differences were going to vary the results significantly. Though there are fundamental differences of the purpose of using social media platform between males and females, study showed that male users were more likely to meet new people online and female users tried to get in touch with their old friends; nonetheless, both genders used social media to do their preferred activities CITATION Maz11 \l 1033 [17] CITATION Vol14 \l 1033 [18]. This focus group study only concentrated on how people understand the concept of the web SSO authentication process, and the ability to identify phishing attacks. It was not my concern about what activities my participants did online.I personally did not think that users who have studied computer science and computer engineering had a clear advantage of understanding the background knowledge of web SSO user authentication systems, or being able to identify web SSO phishing attacks faster than the users in other education fields. A “computer person” could be a programmer who wrote C code or designed an enterprise level of database; these experiences might not give this “computer person” necessary skills and knowledge on network security. One the other hand, a non-computer related participant might use social media websites daily and concern about his/her privacy greatly so that he/she investigated SSO security issues him- or herself. The focus group study would help me determine whether education background might affect the understanding of the topic in this research and the likelihood to detect web SSO phishing attacks easily.CHAPTER V: METHODOLOGYAs previously indicated, I have planned to implement two alternative methods to replace the current web SSO user authentication system. They are the tab method and the redirection method. For the purpose of demonstration in the focus group study, I have designed a scenario that contains a simple comment form. This form supported both local users and Facebook SSO users to submit comments. It had a TEXT INPUT field with an element ID name, in which local users had to fill and submit their comments; it had a radio button for users to select their genders, with gender as its element ID; it had a TEXTAREA with an element ID text. Two submit buttons allowed the local users and Facebook users to submit their comments at the bottom of the form. I chose Facebook Login as the social login system in my implementations; all demonstrations in the focus group study were built to execute Facebook Connect user authentication process.The Facebook Connect provides a set of client-side functionality to the third-party clients. Third-party websites add the Facebook plugin in its DOM when the web page is loaded. Internet users initiate the Facebook authentication process by activating the interactive media provided by the Facebook Login. The Facebook JavaScript and PHP SDKs respond with a Facebook Login form inside a popup window. It enables the interaction with the Facebook Graph API on behalf of the Facebook users after the users’ authorization. The whole process is done via a web development technique called Asynchronous JavaScript and XML (Ajax). Ajax enables the communication between the server and the client in the background without changing the static content of the current web page. The third-party clients receive requested data and store them in the current page session.Knowing is half of the battle. Once the concept is understood, I can continue to proceed to duplicate the web SSO user authentication process with my alternative methods.TAB METHODThe tab method is to open Facebook Login in a new web browser tab. It shares a similar concept with the popup window method used by Facebook Login. Both techniques open a new browser window to display the Facebook Login web page, the difference is where the login form is presented. The popup window method pops up a small browser window in the middle of the screen and the tab method can employ the TDI technology to open the login form in a new browser tab. The small browser window from the popup window method ( REF _Ref415690192 \h REF _Ref415850444 \h Figure 4) does not have a browser menu bar, a bookmark bar or any browser icons such as back, home and refresh buttons. The popup window is positioned at the center of the screen. Therefore unless Internet users drag the popup window outside the boundary of the main web browser, it is difficult to spot whether it is part of the current web page content or another small size browser window. One the other hand, detecting the fake Facebook Login window is simple with tab method because tab will always be in the browser tab bar.Figure SEQ Figure \* ARABIC 4 Facebook Login with the popup methodWhen Internet users log into Facebook with their favorite web browsers, they will notice that they are able to open any numbers of the new Facebook web pages and apps. They do not need to log in again as long as they use the same web browser and manually log off from Facebook. This feature is brought to us by the Facebook authentication cookie. In the computer world, a cookie is a tiny bit of information generated by computer program that is stored inside the web browsers. Web applications frequently use authentication cookies to determine the login status of users, and the accounts the users has logged in with. What the Facebook authentication cookie determines, as the name suggests, is called Facebook Login status. Facebook and all third-party clients’ websites that integrated with Facebook Connect acknowledge that users have been logged in once Facebook Login status has changed to “connected”; Facebook Connect requires users to log in when the status is “not_authorized”. Since the authentication cookie works browser wide, each tab can check Facebook Login status on its own, which is why users can directly open their Facebook home pages or sign in without actually seeing the Facebook login form in popup windows. The credentials that have been submitted in separate browser windows grant the access to all browser tabs.With the tab method, the URL of the Facebook Login website was presented inside the browser address bar. This URL contained information of the App ID of the third-party client (client_id), and Facebook Connect response type (response_type) followed Facebook Connect OAuth specification. The popup window method also showed the exactly URL within its own web address bar because it followed the same protocol. In consideration of the entire popup window could be manufactured inside the page content, the URL could also be forged. However, hackers and their server side scripts could not alter URL inside the browser address bar; therefore checking URL could become a simple way to recognize authenticity of the Facebook Login website.Third-party clients retrieve access tokens from the Facebook authentication server after Facebook Login status becomes “connected”. This behavior supported the core design mechanism of the tab method. When users clicked the Facebook Login button after filling out the comment form, all data within the comment form were not altered or saved as in the tradition popup window method, because they did not need to. The data were still alive within the Document Object Module (DOM).Nonetheless, one issue had forced me to abandon the tab method. Hackers could not infiltrate the Facebook server easily; it was also difficult for me to add a “close” action to the tab created by the script since the login page was solely operated on the Facebook Connect authentication server. The entire method relied too much on Facebook Connect APIs; changing a “close” action from closing the popup window to a browser tab requires modifying the Facebook SDK. I could have put the Facebook Login form into an iframe, but it defeated the purpose of sending the end users to the Facebook website, and let the Facebook deal with the login process. Internet users would still see the domains of the third-party clients in the browser web address bar. Hackers could spoof the iframe in order to steal users’ private information. Since feasibility was one of research goals, I wasn’t considering building a browser extension at first; consequently, I moved on to the second alternative I had in mind.REDIRECTION METHODThe redirection method (the course code of the redirection method main function is in REF _Ref415916999 \h Appendix A: JAVASCRIPT LIBRARY) introduces the concept of sending Internet users to Facebook Login server while saving all form data from the third-party client web application and returning back to the web application once the authorization process is completed. It utilizes URL as the media to transfer authentication requests and access tokens via the Facebook Connect OAuth 2.0 protocol. URL passed same variables client_id and response_type as in the popup window method and the tab method; it also contained a unique value, redirect_uri, for the next web page that the web browser should go to. The OAuth 2.0 protocol recognizes the variable redirect_uri in URL, and sends the page to the web address stored in redirect_uri, therefore the redirection method can redirect the third-party client website back to the users. For the security purpose, the returned destination stored in redirect_uri must be registered to IdP under the OAuth process specification. Unlike the tab method, the redirection method does not require a “close” action added to the Facebook Login web page. OAuth process leaves the authentication server after authorization, and automatically sends Internet users to the location where redirect_uri specifies. It solves my problem with closing extra web windows that the tab method created.From the definition of the redirection method, two main features are required. One is to be able to redirect the current page content back and forth between the third-party client website and the IdP login web page; the other feature is to store all the information of the current web page before it moves to the authentication server.A universal redirection method needs to fulfill: 1) inserting a function to the third-party website if it did not yet to have implemented the web SSO authentication system; 2) helping the third-party website replace the current web SSO authentication setup with minimum source code rewrite.JavaScript can manipulate objects in DOM, adding a fabricated element with an attached action is rather not complicated. Creating a JavaScript library set by an onclick action to begin the web SSO user authentication process is a feasible solution.Figure SEQ Figure \* ARABIC 5 Facebook Login with the tab/redirection methodThe Facebook Login button in the redirection method is an anchor element; its HREF attribute contains a value with the RP client ID and returned URL. I used jQuery JavaScript library to add an onclick action on the anchor element to kick off web SSO user authentication process during the document ready state. Internet users click on the Facebook Login button to authorize the third-party client to access their Facebook profile resources on behalf of users themselves. The onclick action sends the users to the Facebook authentication website (), which is under the Facebook domain. REF _Ref414903112 \h Figure 5 shows the custom built URL with client_id and redirect_uri. The Facebook Connect supports OAuth 2.0 protocol. It learns the next destination from the redirect_uri when the authorization process is initialized. The OAuth process sends Internet users to the destination of return_uri once the authentication process is complete, which is the original third-party client website.During the onclick action, the data from name, gender, and text are required to be stored somewhere before the action is completed; otherwise those data will be lost as soon as the new page content finishes loading. Third-party websites have several options to save the data. The traditional HTML and JavaScript use cookies to store user data. A Cookie is a method to store user data on the client web browsers. However the cookie technology has a 4-kilobyte storage limitation, and all cookies from a single domain are stored in a single string, which makes parsing data a difficult task. Compared the traditional cookies, HTML5 web storage and client-side database have a clear size-advantage; the web storage, which contains the session storage and the local storage, can store up to 5-megabyte in most modern web browsers and 10-megabyte in Internet Explorer after version 8. Both the session storage and the local storage are able to reduce the amount of data to transfer between the servers and the clients; the difference between the session storage and the local storage is that the local storage is scoped by each domain instead of each individual TDI. It means two browser tabs can share the same local storage data but each of these tabs has its own session. Data from different tabs cannot be shared between each session; in addition, the data inside the session storage has a shorter life span, they will be deleted once the browser is closed completely. For the purpose of keeping the comment form data to its own tab and erasing all the data once it is done, the session storage is the preferred choice CITATION Ian13 \l 1033 [19].The redirection method is required to store any data that the third-party websites throw at them, but it is not practical to save all elements of DOM to the session storage. What the redirection method wants is to save all values from form elements of the page content. This means that the JavaScript Library needs to scan the entire page content and filter out all unnecessary elements. Some websites use element IDs to differentiate form elements but some use names; therefore the JavaScript search function could not rely on a single type of identifier; it also could not use either element ID or name tag alone as the source of the identifier in session storage. jQuery library provides an .each() function to collect all array-like objects into an array. I kept all elements with :input selectors, which gave me all the form elements. My JavaScript library uses the element ID as the default key to store all form values into the session storage, and uses the element name attribute as the key if the element ID did not exist. Since the session storage is able to store all data until users close their web browsers, the form data will not be lost during the redirection process CITATION The15 \l 1033 [20].My JavaScript library can search and replace Facebook Login as easy as adding one on websites. It seems that the JavaScript library approach is a feasible solution for the websites that already have social login plugin installed. At the same time, it can present a lot of changes for users who visited multiple websites with social logins daily. Developers from different websites may follow the same concept but to create their execution with their style and approach. To standardize the implementation, building a browser extension becomes an easier approach.With the decision finalized, I developed a Firefox extension ( REF _Ref416415990 \h Appendix B: FIREFOX EXTENSION) with the same feature of JavaScript library. One issue I have encountered was using jQuery in the Firefox extension. I had dealt with jQuery library in the past and it was one of my referred JavaScript libraries, but I could not make jQuery to work with my Firefox extension. Even though I had read online document stating that jQuery library could be inserted into the browser extension and work fine with multiple types of browsers, I decided to use plain JavaScript DOM manipulation to complete my task in order to avoid delaying my schedule. I used the getElementsByTagName function to collect all elements with any given tag names, this function gathered every element from the DOM including <html>, <body>, <div>, <a>, <table>, etc. Clearly <html> or <body> tags are not what I wanted. The approach of eliminating these elements is to check if the elements have more than on child element. This element-filtering function can remove unwanted contents because form elements such as INPUT and TEXTAREA do not possess any child elements. Similar to the JavaScript library, the extension also checks each unfiltered element for the element ID. If the element ID is nonexistent, the browser extension then checks the element’s name. This gives us a key and value pair of each unfiltered element with its element ID/name and value. Once the Facebook authorization is completed, the OAuth process redirects users back from the Facebook authentication web page; the redirection method performs the data-restoration process to restore values of form elements from the session storage. The static content remains unchanged.Let us use the same comment form scenario described earlier in the chapter as an example. A third-party client implements a comment form integrated with Facebook Connect using the redirection method. The comment box has three data fields called name, gender, and text. Name is the element ID of a TEXT INPUT field, gender is the element ID of a radio button, and text is the name of a TEXTAREA. Users can either use local accounts or their Facebook accounts to submit their comments. A user, named “Warmstill Lee” (a dummy account I used to test my program) tries to submit a comment with this comment box from. He skips name and gender fields since he plans to log in with his Facebook profile and types “test” in the text. The onclick action triggers a series of events:It triggers the element-filtering function to select from data throughout the page content.It saves the form data into the session storage. REF _Ref414964180 \h Table 1 illustrates the data inside the session storage before retrieving the user’s profile data from Facebook.The last event of the series is to send the user to the Facebook Login website.KeyValuenamegendertexttestTable SEQ Table \* ARABIC 1 Data value before Facebook Web SSO authorizationOnce the user enters his credential and clicks the “Log In” button on the Facebook Login website, the Facebook authentication server starts the authorization process. Once it completes the authorization handshake, the Facebook Connect sends the user back to the third-party website following the value of redirect_uri along with the Facebook access token. At this point, the third-party client receives the access token from Facebook Connect, thus gains the permission to retrieve the user’s profile data from the Facebook resource server.Figure SEQ Figure \* ARABIC 6 Session log after Facebook Connection authorization REF _Ref414966829 \h Figure 6 shows the data that was stored in the session after OAuth redirected the user back to the third-party client website. We are able to see two JSON instances presented in the console log: storage is the session storage; we can see the variable text had a value of “test”; name is empty because the user skipped entering any information in name field; there is no variable called gender because my program ignored radio buttons when there is no value associated with the variables. Object is the data object retrieved from the Facebook Profile. It has keyword name with a value of “Warmstill Lee” and the gender variable with a value of “male”. The redirection method program performs the data-restoration process when the third-party client website is loaded; it retrieves the data from the Facebook profile on behalf of the user with the permission from the Facebook access token, replaces the name and the gender field with new values from the user’s Facebook profile, and then restores the text field from the session storage. Each step is exactly in this sequence. I encountered an issue during this process when both the JASON objects of Facebook profile and the session storage tried to populate the data at the same time. Only one of the JSON objects could be loaded completely after the document DOM was finalized. This problem could be solved by adding a timeout function on restoring data from the session storage. It allowed the program to retrieve data from the Facebook profile first, and then continue to repopulate the data from the session storage. An intermediate content layer with loading animation was created during the time relay, so that the user would not believe they lost their data input before the web SSO authentication while the web page was still loading. KeyValuenameWarmstill LeegendermaletexttestTable SEQ Table \* ARABIC 2 Data value after Facebook Web SSO authorization REF _Ref414970490 \h Table 2 shows values stored in each element after the third-party client website has been loaded completely. Once the JavaScript has replaced each comment box form field with new data from the Facebook profile and the session storage, the comment is ready to be submitted. Just like the local user submission, the server side script reads the current form data and inserts them into the MySQL database.FOCUS GROUP STUDYIn the world of usability engineering, many types of survey methods are used to collect participants’ perception of certain research products. A focus group study is one type of survey method that forms multiple participants into small discussion groups in order to collect subjective data. Its goal is to gather participants’ opinions and judgments about one research topic by serving questionnaires and discussions. The characteristic of my thesis study is to get users’ feedbacks about the redirection method as a new product, which takes the advantages of the concept of focus group studies. The focus group study obligates to determine whether significant differences would be made between various opinions. The results of understanding the web SSO concept and the likelihood of identifying phishing attacks may vary with the participants’ education backgrounds. I decided to use focus group study method instead of recruiting participants to fill out surveys because the characteristic of the former method offered more opportunities to probe the questions. Different from surveys, which require the researchers already know most of the answers, the decision making is based on pure numbers; focus group study is intended to gather detailed information on new theories and products in comparison with current ones. Focus group study can give me more diverse opinions than a multiple point Likert Scale survey, in which the collected answers will not be more than what the survey has already provided. As a computer engineer, my perspective is the importance of network security. I can navigate through complicated technical guidelines without much trouble, but it does not mean normal Internet users would be the same case. Using focus group study takes the advantage of various mind set to uncover ideas and issues that I had not considered but important to the normal Internet users. Surveys, on that other hand, do not often give researchers additional feedbacks on problems that are not included in the original design; asking follow-up questions requires conducting further researches CITATION Kel03 \l 1033 [21] CITATION Kru08 \l 1033 [22].It is important to know whether the sample distribution can validate the perspective of entire target population. I had requested 20 participants to participate my focus group study approved by the UCCS Institutional Review Board (IRB). Do I need more participants instead of 20? I plan to use t-test to analyze my data sets. The t-test does not have a minimum sample size requirement. The very first t-test in the history had a sample size of four. As a matter of fact, if I want to derive results with a sample of more than 40 participants, another tool called z-test shall be used. The z-test requires large samples. A t-test with a sample size of more than 40 participants yields no differences than the one from z-test. The biggest problem of a small sample size in the t-test is not about the size, but representative. Can 20 participants speak on behalf of entire UCCS population? I explained why ages and genders of participants in the sample pool did not matter for the usage study of social media in REF _Ref414972674 \h CHAPTER IV: HYPOTHESES. When I had selected my participants, it turned out that 10 participants had computer science education background and the other 10 majored in other different fields. Equal population gave me equally sized data sample sets to work with. I used the 5-point Likert Scale to gather the data for the t-test. Each data point will be within the range from 0 to 20 since each Liker scale point could not be score higher than 20 due to the limitation of the sample size of my participants. Equal variances combined with equal sample sizes can provide a lower Type I error rate, and Type II error only applies to an extremely large sample size. Therefore, I can safely proclaim that a sample size of 20 participants could represent the entire UCCS population.The entire section of my focus group study can be divided into two phases. The first phase is a questionnaire phase. Participants need to answer an entrance questionnaire during this phase. As mentioned earlier, I used 5-point Likert Scale for each question in the entrance questionnaire. The Likert Scale is widely used in research that evolves surveys and questionnaires when there is an attitude, belief or behavior item. It measures either positive or negative responses of statements listed in surveys and questionnaires from the participants. A course evaluation is a good example that uses the Likert Scale to record opinions about the course and its faculty member from the students. It presents questions with multiple choices between “strongly disagree” (negative) and “strongly agree” (positive). Some research papers have argued that whether having a middle point does not make the Likert Scale more or less favorable; however, a neutral point is more social desirable when participants are not sure in themselves whether to agree or disagree. I did not use an even point Likert Scale because I did not want to force participants to make a more negative or positive decision due to the lack of neutral point presented. As a result I decided to use the 5-point Likert Scale in my entrance questionnaire. REF _Ref414736086 \h \* MERGEFORMAT Table 3 shows the entrance questionnaire. First three survey questions define 5 points as from least knowledgeable to most knowledgeable; the last two questions define 5 points as from least frequent to most frequent CITATION Nor10 \l 1033 [25] CITATION Tsa12 \l 1033 [26].Table SEQ Table \* ARABIC 3 Focus group study – the entrance questionnaireThe main focus of the entrance questionnaire survey is to learn the knowledge background from each participant about web SSO and phishing attacks. Since undoubtedly there were some differences in term of understanding of the web SSO security between participants, the participants may influence each other’s answer if discussions are allowed while they fill out the questionnaire. Therefore, I asked participants not to chat with each other or ask me about anything related to the key words in the questionnaire in order to avoid unnecessary noise to be introduced to the t-test.The t-test uses p-value and null hypothesis to determine whether any hypothesis is valid. The definition of a p-value is “the probability that any given experiment will produce a value of the chosen statistic equal to the observed value in the actual experiment or something more extreme, when the null hypothesis is true and the model assumptions are correct” CITATION Sel14 \l 1033 [24]; it is the level of statistical significance. A null hypothesis is an opposite hypothesis that researchers try to test. For example, I mentioned that I tried to investigate if the redirection method is easier to understand than the popup window method in web SSO user authentication system earlier in this thesis. The null hypothesis would be there is no difference. In a normal circumstance, it is safe to state that the null hypothesis can be rejected if the p-value of two data sets is smaller than 0.05. That means less than 5% chance of finding a difference given that the null hypothesis is true CITATION Sel14 \l 1033 [24].The second phase of the focus group study is the discussion phase. it includes four demonstrations: 1) the use of Facebook Login with the popup window method following the develop guideline from the Facebook Developer website; 2) the use of Facebook Login with my redirection method supported by the JavaScript library; 3) a phishing attack against the first demonstration; and 4) a phishing attack against the second demonstration. The browser extension will not be a part of the demonstration due to its same functionality as the JavaScript library. I chose to present the JavaScript library also because only two demonstrations use the redirection methods, and they do not have existing web SSO systems to be replaced with. The first two demonstrations can be combined into the first part of the discussion phase; these demonstrations will determine if the participants can understand each method, and whether the participants feel one method is easier to understand than the other. The last two demonstrations belong to the second part of the discussion phase; these demonstrations will assist me to determine which methods can help the participants identify phishing attacks against web SSO user authentication systems more efficiently. Focus Group QuestionsUser data submission.When we sign in through the popup window that contains the Facebook Login website (i.e., using the first method), do you know if we have submitted our Facebook account information directly to the Facebook authentication server?When we sign in through the redirected Facebook Login website (i.e., using the second method), do you know if we have submitted our Facebook account information directly to the Facebook authentication server before it redirects our browser back to the previous web page?Comparing the two methods demonstrated in Part I, which method, in your opinion, is easier to use?Now imagine that you are using your Facebook Single Sign-On user authentication on a website, but you do not know whether this website will perform phishing attacks like what we demonstrated in Part II.If you were accustomed to use the popup window that contains the Facebook Login website (i.e., using the first method), would you be able to identify this type of Single Sign-On phishing attacks?If you were accustomed to use the redirected Facebook Login website (i.e., using the second method), would you be able to identify this type of Single Sign-On phishing attacks?Table SEQ Table \* ARABIC 4 Focus group study – the discussion questions REF _Ref414818096 \h Table 4 shows the questions in the discussion phase. There are three questions in total. Question 1 and 2 are directly linked to the first two demonstrations. Participants’ opinions are able to help me determine the likelihood of the redirection method being simpler and more understandable than the popup window method. Question 3 gathered the opinions about phishing attacks from last two demonstrations. It gives me the data set to measure which method can help users easily identify phishing attacks. The comment box scenario described earlier in this chapter is used in the demonstrations to simulate real life web applications. The demonstrations were set up in a LEMP server. LEMP stands for Linux, Nginx, MySQL and PHP. A small MySQL database was created in order to store comments from the comment box. All user login processes during the demonstrations were simulated without using real users’ identities.CHAPTER VI: RESULTS AND ANALYSISDATA COLLECTION10 of the total 20 participants had an education background of computer science, and the other half varied from Journalism, Public Administration, Electrical Engineering and Mechanical Engineering. I did not know whether they had ever used any social login systems prior to their focus group study sections. The participants were separated into six different groups due to their availability. Their genders, ages or education backgrounds were not considered to be the factors for whom to attend the same meeting.Since the focus group study requires human subjects, the UCCS IRB requires investigators to go through a series of approval processes. An ethical training is a major part of the IRB requirement since human being had done many terrible things to each other in the name of “research” throughout the human history. Therefore under the principles of Respect for Persons, Beneficence, and Justice, the IRB Human Research Protection Program standard operation requires me to pass the ethical training and submit an IRB application checklist document describing the procedure of my focus group study. The following text is the statement in my document:Purpose: This proposed study will investigate the security of the web SSO user authentication process. We will perform three demonstrations to present two different methods of web SSO user authentication processes and phishing attacks. We will ask participants to answer one pre-study questionnaire and three groups of questions during the focus group study. We will collect participants’ opinions regarding the login processes demonstrated in the study.Methodology: We expect to recruit about 20 participants in this study. Participants will be asked to answer a web Single Sign-On related pre-study questionnaire. We will perform three demonstrations on web Single Sign-On user authentication processes and phishing attacks. We will ask them to answer questions regarding their opinions related to the user authentication processes and phishing attacks.The participants will observe our demonstrations performed in the focus group, answer a pre-study questionnaire and answer questions asked during the demonstrations. The participants may also try the demonstrations with the provided test accounts.Research Setting: Recruitment, Data Collection within UCCS.Risks/Benefits: At the end of the study, we will explain the mechanisms of web SSO user authentication process, so that each participant can understand more about web SSO user authentication and phishing attacks, and make their online experience more secure and enjoyable.We will provide a few test accounts (username/password pairs) created by us for participants to use if the participants want to try the demonstrations by themselves. Therefore, participants do not need to provide or use any of their own online accounts.There will be no risks to any participant.Participant Recruitment: During the weekdays, we will stop by labs, study areas, and some offices of the UCCS campus and ask if some students, staff and faculty members at the visiting location are interested in participating the focus group study. If some people are interested in our focus group study, we will ask them about their available days and time slots as well as their email addresses. We will group participants who are available at the same time, and invite them via email to come to our lab for the focus group study. We will mention clearly in the invitation email that they are not required to come if they do not want to. The invitation email template is attached to this application checklist.Participants will be selected from students, staff and faculty members of UCCS regardless of their gender, race, citizenship or ethnic background.Available participants in a certain time slot will be placed into one group to participate in the demonstrations and rmed Consent: REF _Ref415425210 \h Table 5 shows the consent document.University of Colorado Colorado Springs (UCCS)Consent to be a Research SubjectTitle: The Investigation of Single Sign-On (SSO) System SecurityPrincipal Investigator: Xiang TanFunding Source: N/AIntroductionYou are being asked to be in a research study. This form is designed to tell you everything you need to think about before you decide to consent (agree) to be in the study or not to be in the study. A member of the research team will describe this study to you and answer any questions. It is entirely your choice. If you decide to take part, you can change your mind later on and withdraw from the research study. You can skip any questions that you do not wish to answer.Before making your decision:Please carefully read this form or have it read to you.Please ask questions about anything that is not clear.Feel free to take your time thinking about whether you would like to participate. By signing this form you will not give up any legal rights. If you are completing this consent form online, you may want to print a copy of the consent form for your records. Study Overview This research is studying the web SSO user authentication process by providing an alternative Facebook/Google+ login method to access social media profile information. We appreciate you joining in to a focus group to visit and discuss three test websites and answer one questionnaire. Everything we talk about will be anonymous and you don’t have to answer anything that you don’t want to. We will provide a few test accounts (username/password pairs) created by us for you to experiment with the test websites. Therefore, you don’t need to provide any of your own online accounts. Having said that, we really want to hear anything that you think will help us understand your experience of the web SSO login process.Procedures We will invite 20 UCCS students, staff and faculty members to participate in this focus group study. The overall procedure takes no more than half an hour. Group members will answer a SSO user authentication related questionnaire in about 2 minutes. Then, we will demonstrate two different types of Facebook SSO login process, and discuss with you about the experience in comparing these two methods of process in about 25 minutes. Group members can try the demonstrations with the provided test accounts.Other people in this studyThe principal investigator and his advisor will jointly host the focus group study and expecting about 20 selected participants to participate in this study.Risks and DiscomfortsYou will use web browsers to perform some regular browsing activities. You don’t need to provide or use any of your own online accounts. There is no risk to your personal information or account.Benefits At the end of the study, we will explain the mechanisms of web SSO user authentication process to you, so that you can understand more about web SSO user authentication and phishing attacks, and make your online experience more secure and enjoyable. Compensation N/AConfidentiality Certain offices and people other than the researchers may have access to study records. Government agencies and UCCS employees overseeing proper study conduct may look at your study records. These offices include the UCCS Institutional Review Board, and the UCCS Office of Sponsored Programs. UCCS will keep any research records confidential to the extent allowed by law. A study number rather than your name will be used on study records wherever possible. Study records may be subject to disclosure pursuant to a court order, subpoena, law or regulation. Voluntary Participation and Withdrawal from the StudyYou have the right to leave a study at any time without penalty. You may refuse to do any procedures you do not feel comfortable with, or answer any questions that you do not wish to answer. If you withdraw from the study, you may request that your research information not be used by contacting the Principal Investigator listed above and below.Contact InformationContact (PI’s info):Xiang TanUniversity of Colorado Colorado Springs, Department of Computer Science1420 Austin Bluffs Parkway, Colorado Springs, 80918Phone: 719-255-3333; Email: xtan@uccs.eduContact the Research Compliance Coordinator at 719-255-3903 or via email at irb@uccs.edu: if you have questions about your rights as a research participant, orif you have questions, concerns or complaints about the research.ConsentA copy of this consent form will be provided to you. I understand the above information and voluntarily consent to participate in the research. By signing this consent, I am confirming that I am 18 years of age or older.Table SEQ Table \* ARABIC 5 IRB Informed ConsentThe procedures dictate that I can only ask faculty members, staff and students of UCCS, and not force anybody to participate in my research study, especially other students who are also under my academic advisor. To make my approval process easier, I decided not to ask any other students from my advisor and my advisor himself to be my participants; I cannot invite each participant to partake more than once. In case they failed to show during their schedule time, they cannot be recalled and replacements will be needed for the future sections; I cannot select my participants regarding their genders, races, citizenships or ethnic backgrounds. After my focus group study was approved by the IRB, I started my search of 20 participants from the faculty members, staff or students in the university. I did not create flyers or advertise my research with payment, but walked around the campus to acquire volunteers. Once I found random people, who were interested in participating the focus group study, I then recorded their names, email addresses and availability. An email, as showing in REF _Ref414880009 \h Table 6, was sent to each potential participant according to their availabilities. FOCUS GROUP STUDY INVITATION EMAIL TEMPLATEDear potential participants,You are invited to join a focus group study on the topic of the Web Single Sign-On User Authentication Process.Location: ______________________Date and Time: ______________________You are not required to provide any credential during the focus group study.You are not required to come if you do not want to come.Thank you very much.Xiang TanUniversity of Colorado Colorado Springs, Department of Computer Science1420 Austin Bluffs Parkway, Colorado Springs, 80910Table SEQ Table \* ARABIC 6 Focus group study - invitation email templateOnce the entrance questionnaires were collected, I explained what the SSO and web SSO user authentication systems are, and where we had used SSO systems in our daily lives. Several participants believed that they had not used SSO authentication systems to log into other web applications frequently, which is a misconception since they had used their school employee IDs or student IDs to access their school emails or any other school managed web services. More details about the data analysis of the entrance questionnaire will be discussed in the DATA ANALYSIS sub-chapter.Data collecting method during the discussion phase is to record participants’ opinions. As mentioned in previous chapters, the first half of the discussion phase shows the Facebook Login authentication process with both the popup window method and the redirection method; the participants were asked to give feedback on comparing the two different methods: which method or both had sent their login credentials to the Facebook authentication server directly, and which method was easier to understand. This part of group study was to determine whether the redirection method was as easy to understand as the normal Facebook popup method. I believed that most participants would use either the Facebook or the HTTPS icon in the URL from the popup window to identify the legitimacy of the login windows, but never thought about how their user information was sent to the Facebook authentication server. The second half has two more demonstration of phishing attacks against each Facebook Login method. Since hackers could not manipulate the official Facebook authentication server web page unless they initiated an attack to the Facebook directly, they needed to add their malicious code onto the third-party website. If they add a link of a malicious website on the third-party website like the traditional link manipulation phishing scams, it will be easy to spot that the URL of the Facebook Login form is not legitimate. Therefore the only feasible attempt is to create a spoofed popup window similar to the popup window method that the current Facebook Login process uses. I expected that the participants were able to easily identify the phishing, because redirection method states that the method is to move the user from the current website to the Facebook authentication server by clicking a link; it will be faulty if the click action initiates a popup window.Due to privacy concern, all users’ opinions during the discussion phase were recorded by handwriting. I did not use any image and voice recording tools, so that the identities of participants would not be recognized. The participants’ private information including, but not limited to their names, gender and age, were not recorded on the entrance questionnaires and discussion opinions sheets.DATA ANALYSISThe entrance questionnaire uses the 5-point Likert Scale to collect the participants’ background knowledge and their frequency of using social login systems. I separate the entire set of the data collection into three different data sets. The entire data collection is of one data set, which called Total. Another data set is called CS; it records all opinions from Computer Science related faculty members, staff and students. Participants who answered “Computer Science” to the first question, “What is/was your major?”, are put into this data set. Participants whose majors are other than “Computer Science” are put into the last data set, which called None CS.The x-axis in Likert Scale charts is the scale of the Likert item; the definition of each point follows the description of the entrance questionnaire ( REF _Ref414736086 \h Table 3); the y-axis was vote counts of each Likert item. The blue color column is the Total counts of each Likert Scale point; Orange shows the vote counts of the None CS alone; Gray color column represents the vote counts from the CS participants only. For the purpose of uniformity, all results of the entrance questionnaire would follow the same setup.Figure SEQ Figure \* ARABIC 7 Survey question 1: Do you know what web Single Sign-On user authentication is, i.e. Facebook? REF _Ref414994218 \h Figure 7 illustrates the opinions of all participants’ personal judgment of their knowledge level about the SSO user authentication system. The background knowledge of the SSO user authentication system among the participants is widely divided. The Likert Scale chart shows 5 (25% of Total) participants have answered most knowledgeable and least knowledgeable; 4 (20% of Total) counts for both somewhat knowledgeable and not very knowledgeable. The CS participants had 1 (total 3 votes) more vote in most knowledgeable and 1 (total 2 votes) less vote in least knowledgeable than the None CS participants; the CS group also had 2 (total 3 votes) more vote in somewhat knowledgeable and 2 (total 1 vote) less in not very knowledgeable in comparison with the None CS. It seems the computer science related participants have more knowledge about the terminology of web SSO user authentication system. But let us use a mathematical tool to help us analyze these data.Figure SEQ Figure \* ARABIC 8 T-test result of survey question 1By using the statistical program R, I calculated that the participants with Computer Science background had an average 3.4 of knowing what the SSO user authentication was, a slightly better comparing with non-computer science participants of 2.6. I want to see if there is a difference between the CS and the None CS data sets; the null hypothesis from the t-test is always the opposite of the alternative hypothesis; in this case, the null hypothesis means that the CS and the None CS participants equally know what the Facebook web SSO user authentication is. The P-value (showing in REF _Ref415038063 \h Figure 8) from the t-test against the CS and the None CS participants is 0.2717 with a 95 percent confidence interval, which is significantly larger than 0.05. By definition, “the most common decision rule is to reject the null hypothesis if the p-value is less than or equal to 0.05 and to retain it otherwise” CITATION Sel14 \l 1033 [24]. Therefore, the null hypothesis was not rejected; the data showed that both the CS and the None CS participants have the same background knowledge level on what the Facebook web SSO authentication is. Figure SEQ Figure \* ARABIC 9 Survey question 2: Do you know what Phishing Attack is? REF _Ref415038194 \h Figure 9 illustrates the result of the second question in the entrance questionnaire. The question asked all participants whether they knew what phishing attacks are. It is to determine whether there is a significant difference of knowing the terminology of phishing attacks between the CS and the None CS participants. Mean value of Total was 3.4 and median value was 4; more than half of the entire sample pool were knowing the meaning of phishing attacks. I expected that it would be a knowledge gap between two participant groups due to the exposure of specific subject related education. On the contrary, both groups had equally 2 (10% of Total) participants selected “most knowledgeable”; and 2 (10% of Total) votes for each leaned more toward negative positions.Figure SEQ Figure \* ARABIC 10 T-test result of survey question 2 REF _Ref415039570 \h Figure 10 shows the t-test result of questions 2. The mean average of the CS group was 3.5 and the mean average of the None CS group 3.3. The mean values between two data sets were fairly close; both are slightly above the neutral point 3. Calculation showed p-value with 95% confidence interval between the CS and the None CS groups was 0.7435. Like the first survey question, it is much higher than 0.05 thresholds. The null hypothesis, “there is no significant difference between the CS and the None CS groups in term of knowing what phishing attacks are”, is retained.Figure SEQ Figure \* ARABIC 11 Survey question 3: Do you know the Phishing Attacks against SSO user authentication?The third survey question asked whether the participants understood how hackers would perform a phishing attack against SSO user authentication system. The graphical presentation of the result is shown in REF _Ref415042078 \h Figure 11. Nobody claimed that they were “most knowledgeable” about phishing attacks against SSO user authentication. 9 out of 20 (45%) of total participants believed they knew nothing about this new form of phishing activities. Among these 9 participants, 4 (40% of CS) of them were in the CS group and 5 (50% of None CS) belonged to the None CS. 6 (60% of Total) of total participants identified themselves as “not very knowledgeable”; vote counts were separated between CS and None CS groups equally. 3 participants selected “somewhat knowledgeable” including 2 (20% of CS) from the CS group and 1 (10% of None CS) from the None CS group. Figure SEQ Figure \* ARABIC 12 T-test result of survey question 3The p-value from REF _Ref415055038 \h Figure 12 is similar to the previous two questions, a 0.5561 between the CS and the None CS data sets with a 95 percent confidence interval. Education background does not affect the outcome. The null hypothesis cannot be rejected. Moreover, both the CS and the None CS data sets showed lower average scores than the first two questions (1.8 vs. 2.1). The mean value of the entire sample pool is 1.95 and the median is 2, which are below the neutral point. It shows that my participants do not have a solid understanding about the phishing attacks against web SSO user authentication systems.Figure SEQ Figure \* ARABIC 13 Survey question 4: How often do you use Facebook or Google+? REF _Ref415039941 \h Figure 13 illustrates the result of question #4. The median of the Total was 2. It was lower than my personal expectation, because Gmail, as a part of Google product, uses Google+ SSO user authentication. 7 participants (35% of Total) stated that they wanted to stay away from the Facebook because of privacy concerns of social media websites. 1 participant (5% of Total) with computer science education declared that he had developed several web applications using the Facebook Login but did not have a personal Facebook account. There were huge amount of fear on using Facebook. Combining with the last question, it seemed that users in fact were lacking of knowledge about web SSO and social login as a whole.Figure SEQ Figure \* ARABIC 14 T-test result of survey question 4 REF _Ref416008020 \h Figure 14 shows the p-value with 95 percent confidence interval for question #4 was 0.6031, much larger than 0.05. Again, since the null hypothesis could not be rejected, it is safe to proclaim that there were no differences in term of willing to use social media websites such as Facebook or Google+ between the CS group and the None CS group.Figure SEQ Figure \* ARABIC 15 Survey question 5: How often do you use Sing Sign-On to log into other websites? REF _Ref415943502 \h Figure 15 illustrates the result of the last question in the entrance questionnaire. The question asked participants how often they would use SSO to log into websites. Among all 20 participants, 4 of them (20% of Total) claimed to ever use SSO to log into other websites more frequently than Likert Scale average score of 3; all of these 4 participants had computer science related education. However, 5 CS participants claimed that they were least frequently or less than likely to use the SSO to log into other websites, more than the counts of the positive response.Although no one asked to clarify, I realized that my interpretation of what each Likert Scale point meant in question #4 and #5 was very vague after the focus group was completed. I simply described “1 being least frequent and 5 being most frequent” in the description, but failed to define the average frequency was. A better explanation can be “1: never used, 2: less than once per month, 3: less than once per week, 4: once per day and 5: more than once per day”. I use Facebook web SSO as frequent as once per week, which I can say this recurrent event is my average frequency; I also access my Gmail inbox daily, therefore I can state that I used SSO to log into other websites much higher than average. Yet this has been all just my personal opinion, every person has his/her own definition of average. There was not any establishment of what the basic time unit was in question #4 and #5. While I can compare the differences between the CS and the None CS participants, I can not state how regularly the participants used IdP.Figure SEQ Figure \* ARABIC 16 T-test result of survey question 5The result of the last entrance questionnaire question has a p-value of 0.07069 (showing in REF _Ref415943341 \h Figure 16). The null hypothesis is not rejected; there is no difference between the CS and the None CS groups in term of how often the participants use the web SSO user authentication systems to access other websites. The gap between both averages of the data sets was large, since no one from the None CS participants group had selected top 2 Likert Scale point.As mentioned in previous chapters, many None CS participants did not realize that they have used SSO daily. The question asked about SSO instead of web SSO; it includes not only all social media websites, but also any kind of enterprise level network authentication accounts. Each participant is either working or studying in UCCS, and the university creates exchange accounts and 365 accounts for its employees and students as the default accounts for many school controlled applications. These applications support AD or LDAP, which both are types of SSO authentication systems. I did not expect the None CS participants to understand they used SSO authentication systems frequently in day-to-day life, what was interesting was the CS participants scored themselves at 1 and 2 more than the top 2 points.Figure SEQ Figure \* ARABIC 17 The average scores of the survey questionsFigure 17 illustrates the average scores of all survey questions. My study revealed that (1) the participants have some knowledge about the web SSO user authentication systems (question 1: M=3); (2) the participants somewhat understand what phishing attacks are (question 2: M=3.4); (3) the participants do not know much about phishing attacks against SSO user authentication systems (question 3: M=1.95); (4) the participants slightly less often use social media and its SSO user authentication (question 4: M=2.7); (5) the participants are less likely to use web SSO user authentication systems to log onto other websites (question 5: M=1.7).The mean averages of the first three questions for Total, CS and None CS are 2.78, 2.57, and 3. The participants’ answers revealed that CS participants have slightly more knowledge about the web SSO user authentication systems and phishing attacks than None CS participants, but the difference is not significant (p-value=0.52). The mean averages of the last two questions for Total, CS and None CS are 2.48, 2.1, and 2.85; the p-value between CS and None CS data sets is 0.31. The participants have a slightly less chance to use social login systems (below the natural point of 3); there is no difference between CS and None CS participants in term of being willing to use social login systems.The discussion phase started with demonstrating both the popup window method and the redirection method. Each participant discussed the first two questions regarding their observations. The first question contains two sub questions: Q1a, “When we sign in through the popup window that contains the Facebook Login website (i.e., using the first method), do you know if we have submitted our Facebook account information directly to the Facebook authentication server?”; Q1b, “When we sign in through the redirected Facebook Login website (i.e., using the second method), do you know if we have submitted our Facebook account information directly to the Facebook authentication server before it redirects our browser back to the previous web page?”. The second question (Q2) is, “Comparing the two methods demonstrated in Part I, which method, in your opinion, is easier to use?” Figure SEQ Figure \* ARABIC 18 Focus group study Q1a REF _Ref415073651 \h \* MERGEFORMAT Figure 18 illustrates participant’s opinions of Q1a. 12 out of 20 participants (60% of Total), including 4 from the CS group and 8 from the None CS group, believed the user credential has been sent directly to the Facebook authentication server without the third-party client stealing the information; 2 None CS participants who chose “yes” also stated that they were not really sure whether the credential has been sent directly to the Facebook authentication server. 3 (15% of Total) participants, including 2 from the CS group, believed the user credential is safe from the third-party client because the web address bar of the popup window displayed a URL from the Facebook domain, and 2 None CS (10% of Total) participants trusted the HTTPS lock icon in the address bar of the popup window.4 participants (20% of Total), including 3 from the CS group and 1 from the None CS group, believed the third-party client has saved the password; these participants stated that they did not trust the popup windows. 4 participants (20% of Total), including 3 from the CS group and 1 from the None CS group, were not sure what happened during the process and did not choose either “yes” or “no”. Both the CS and the None CS groups have 1 participant responded that they “would never care about whether the user data had been breached”.As mentioned in previous chapters, the Facebook SDK creates its login form under the Facebook domain. The login form is within the Facebook’s domains. The RP website cannot retrieve the data from the login form generated by the Facebook SDK. Therefore a real Facebook Login will send users’ credentials directly to the Facebook authentication server. 60% of participants believed the user credential has sent to the Facebook authentication server directly in the first demonstration. Given that there are 2 participants stated “yes” but were not sure whether the credential has been sent directly to the Facebook authentication server; these participants’ statements could truly mean “uncertain”, and then the participants who stated “yes” would be 50% instead of 60%.Figure SEQ Figure \* ARABIC 19 Focus group study Q1b REF _Ref415073068 \h \* MERGEFORMAT Figure 19 illustrates the result of Q1b. 16 out of 20 participants (80% of Total), including 8 from both the CS and the None CS groups, believed the user credential in the redirection method had been sent to the Facebook authentication server directly. 5 participants (25% of Total), including 4 from the None CS group, stated that they trusted the data integrity because the Facebook domain was shown in the address bar after redirecting to the Facebook Login website.3 participants (15% of Total), including 2 from the CS group and 1 from the None CS group, did not believe the user credential had been sent to the Facebook authentication server directly. 1 participant (5% of Total) was not sure about the process. This participant was from the None CS group. None of CS participants was “uncertain”.Figure SEQ Figure \* ARABIC 20 T-test result of Q1a and Q1b REF _Ref416007920 \h Figure 20 shows the t-test results of Q1a and Q1b. Since I may have two different results from Q1a, I have calculated with both 50% and 60%. Both p-values are greater than 0.05. Therefore, the null hypothesis, “there is no difference between the redirection method and the popup window method in term of easiness for users to understand web SSO user authentication”, cannot be rejected.Figure SEQ Figure \* ARABIC 21 Focus group study Q2 REF _Ref415074464 \h \* MERGEFORMAT Figure 21 illustrates the result of Q2. This question gives me the confidence about the usability of the redirection method. I combined all the variations of the participants’ opinions into four categories: “both were fine”, “preferred popup window method”, “preferred the redirection method” and “liked neither”.4 participants (20% of Total), including 1 from the CS group and 3 from the None CS group, believed that both the redirection method and the popup window method were easy to use. 7 participants (35% of Total) agreed that the redirection method is easier to use. More CS participants believed in the redirection method (5 CS vs. 2 None CS). 1 None CS participant professed, “Did not like popups, like the actual web page.” 1 CS participant said, “Rather use redirection, I know where is the page is going to be, window popup looks like a security issue like bank page, don’t like popup window.” (NOTE: the participant referred to fraudulent popup messages from the Elmira Savings Bank website, )8 participants (40% of Total) agreed that the popup window method is easier to use. More None CS participants preferred the popup window method (5 None CS vs. 3 CS). 1 None CS participant said, “Popup is easier to use as a regular user.” 1 None CS participant, who voted for popup method, mentioned, “Popup is easier, another tab will be convenient.” As I mentioned in REF _Ref415078028 \h \* MERGEFORMAT CHAPTER VI: METHODOLOGY, I had to abandon the tab method because of the time constraint; nonetheless, it seemed that there could be a desire for the tab method. Another None CS participant stated his dislike of popup windows but still preferred to use the popup window method for Facebook Login. 2 other None CS participants claimed that the popup window is easier to use once they understood how to detect phishing attacks against the web SSO user authentication system. Other participants were just used to see the popup windows, they would not prefer changes.One of the concern I have heard during the focus group study sections was that users might worry about losing their data with the redirected method. Users can still see everything they typed behind the popup windows during the authentication process, but not the case with the redirection method. 1 CS participant mentioned, “Redirection method is easier to use except one thing, User will think, oh man, I lost all the data I just input in the form.” From Q2, I found that 12 votes are for the popup window method, and 11 votes are for the redirection method. In term of the usability, the popup window method has a slightly more votes, especially from the Nonce CS participants.The second half of the discussion phase started with two demonstrations of phishing attacks. Each participant discussed two questions regarding phishing attacks against web SSO user authentication systems: Q3a, “If you were accustomed to use the popup window that contains the Facebook Login website (i.e., using the first method), would you be able to identify this type of Single Sign-On phishing attacks?”, and Q3b, “If you were accustomed to use the redirected Facebook Login website (i.e., using the second method), would you be able to identify this type of Single Sign-On phishing attacks?”Figure SEQ Figure \* ARABIC 22 Focus group study Q3a REF _Ref416010812 \h Figure 22 illustrates the result of Q3a. The result is really straight forward; nobody believed they would identify the phishing attacks against the popup window method. During the demonstration, I opened both the legitimate and the spoofed Facebook Login forms side by side. Participants were not restricted to the amount of time they could use to check the differences; participants could also stand as close as they wanted in front of the monitor if they wished. Participants from neither the None CS nor the CS group could tell the differences between the legitimate website and the spoofed one. REF _Ref415078866 \h \* MERGEFORMAT Table 7 shows some of the feedbacks from participants, I did not put feedbacks that are “no” or “cannot tell” in the table.GroupFeedbacksNone CS“It is difficult to tell whether the popup window is legitimate or phishing. I would pay attention to the HTTPS and lock image from the popup window. But if the popup window has both of what I mentioned, I would not know for sure if it was fake.”None CS“Cannot tell if it was a phishing attack.”None CS“Considering if at home, and did not know it is a demo of phishing attacks, I could not tell it was a fake.”None CS“By Looking at the demonstration, would not think it was a phishing.” “attack.CS“Cannot tell, Could be legitimate because of the green color HTTPS.”CS“Hard to identify.”CS“The appearance seemed exactly like the real one, cannot identify.”CS“Checking the lock icon at the address bar within the popup window, not sure whether it was real, would like to use Chrome to check the green color lock icon.”Table SEQ Table \* ARABIC 7 Participants’ feedbacks from phishing attacks against the popup window methodThe result shows that the popup window method does not give participants any indications to identify spoofed programs from the real ones. I had purposely made the spoofed popup window with a slightly different appearance than the legitimate one. For example I made the lock icon representing HTTPS connection colored green; as of right now, the green lock icon is exclusive to Chrome, Firefox has a gray color icon. I showed the demonstration in Firefox, and none of the participant noticed the green lock icon. 2 CS participants (10% of Total) specifically mentioned this HTTPS indicator, but failed to identify.Figure SEQ Figure \* ARABIC 23 Focus group study Q3bDifferent from the popup method, phishing attacks against the redirection method had more mixed results (showing in REF _Ref415147634 \h Figure 23). 4 participants (20% of Total), including 2 from both the CS group and the None CS group could identify the phishing attacks against the redirection method; 1 None CS participant (10%) had suspicion about the legitimacy of the popup window in the demonstration. Not much different point of view exists between the CS participants and the None CS participants.Nonetheless, 6 out of 6 None CS participants who chose “no” restated that they would be able to identify the phishing attacks more effectively if Facebook Connect restricts the use of the popup window method and only allows the redirection method. The same thing happened to the CS participants. 6 out of 8 CS participants who failed to identify phishing attacks also agreed the same statements with their None CS counterparts. The reason participants restated their statements is due to the fact that hackers can only modify the contents on third-party client websites; if users knew the Facebook Login form is the redirection method, they will be able to identify phishing scams when popup windows appeared on the screen. If the Facebook only allows the redirection method, 16 out 20 participants (80% of Total) will be able to identify phishing attacks against Facebook Connect user authentication systems. The successful rate of phishing attacks against web SSO user authentication systems will drop dramatically. Therefore if IdPs have restricted the use of the popup window method, the null hypothesis, “There is no difference between the redirection method and the popup window method in term of helping users identify phishing attacks”, can be rejected.CHAPTER VII: RECOMMENDATIONSGiven that the tab method was not a preferred choice due to the characteristic of JavaScript Library, it could not manipulate web page contents from a different domain. Creating a browser extension that has an ability to perform tab manipulation could be a continuation effort to develop a suitable program with the tab method. Such an effort would create an alternative method for replacing the current popup window method with a secure and easily understandable method.While I demonstrated phishing attacks during the focus group study, I created demonstrations following the basic setup recommended by the Facebook developers’ documentation. My implementation of Firefox extension also follows the same setup. It is designed to replace any third-party clients with the basic Facebook Login integration. However professional websites such as CNN or Yahoo! use their own versions of JavaScript functions to call the popup windows. The browser extension would be more valuable by considering more customized implementations including the ones from CNN and Yahoo!, etc.CHAPTER VIII: CONCLUSIONWeb SSO systems make the life simpler for Internet users by reducing the effort of memorizing many individual credentials and the time for filling out the user profile on each website. With one set of user credential, Internet users can access many websites and online applications, which integrate with web SSO user authentication systems. However, phishing attacks against web SSO can cause more damages than tradition phishing because of the nature of web SSO user authentication systems; one set of identity provides access to multiple accounts.Fighting against web SSO phishing attacks require collective efforts. A well-defined procedure from the service providers can help to maximize the authentication security. The result of my focus group study shows that the current web SSO user authentication method could not protect Internet users from phishing attacks. Thousands of apps and Internet games have been developed by known and unknown web developers. Their web servers are the third-party clients that communicate with the web SSO authorization servers. Internet users cannot differentiate the web applications created by less known companies and web developers from the malicious ones. Hackers can easily set up their own RP websites to lure Internet users to give away their identifications. If IdPs could restrict their protocols to only allow the third-party clients to use the redirection method, we can limit the way hackers can use to steal identities from users.Second, an improved web SSO user authentication process can tighten the security measurement. I have described multiple methods of web SSO user authentication process, including the current popup window method and my own implementation of the redirection method. Each method has its strength and weakness. Using the redirection method as an example, most CS participants shared the same view as I have; nonetheless, the None CS participants brought up an interesting point: While the “computer people” concentrate on understanding how their private data are delivered between domains and how secure the delivery channel is; the None CS participants, with their lesser technical point of view, do not care too much about how the data flowed through the network. They pay more attention to the usability instead of security. Many of the None CS participants pointed out that they were used to see the popup windows; therefore, they expected to see popup windows when they tried to log in. However, even though the redirection method scored lower on usability, it helps the users understand how the web SSO user authentication systems work and more easily identify phishing attacks.Last but not least, a proper education effort can help Internet users correctly identify potential attacks and protect their private information. My study clearly shows that Internet users did not fully understand web SSO user authentication systems and their security, and some of my participants were afraid to use social media applications due to the lack of the background knowledge about web SSO. In my last part of focus group study sections, I demonstrated several techniques in my research on how to exam the legitimacy of the current Facebook Login. I received many positive feedbacks from the participants. One of the faculty members, who attended my focus group study, wished to send her students to my focus group study sections to learn more about Facebook Connect and its related security issues. She believed that these knowledge and skills about web SSO user authentication systems might not be something needed in courses, but definitely would be useful for everyone in their daily lives. I appreciate the faculty members’ comments, and urge users to get more education and training to understand and identify web SSO phishing attacks.Appendix A: JAVASCRIPT LIBRARYfb.jsfunction manSession ( ) {/* core function for session data */ var cssProp; var namProp; $("#fbContent_loadMsg").hide(); $("#fbContent_loadMsg").remove(); $("*").each(function() { if (typeof $(this).attr("id") === "undefined" ) {namProp = $(this).attr("name"); }else namProp = $(this).attr("id"); if ( $(this).attr("id")=="fb-root" || $(this).attr("id")=="fb_xdm_frame_http" || $(this).attr("id")=="fb_xdm_frame_https" || $(this).attr("id")=="facebooko-jssdk" ) { } else if ( $(this).is(":input") ) { switch ($(this).attr("type")) { case "radio": $(this).filter("[value="+window.sessionStorage.getItem(namProp)+"]").prop("checked", true); break; default: $(this).val(window.sessionStorage.getItem(namProp)); break; } } else { if ( sessionStorage.getItem(namProp)!= null && sessionStorage.getItem(namProp).length > 0 ) { $(this).html(window.sessionStorage.getItem($(this).attr("id"))); } } });}$(document).ready(function() { /* Create facebook link */ var top=303; var left=20; var counterNo=0; if ( $(".fb-login-button")[0] ) { var offsetBtn=$(".fb-login-button").offset(); $(".fb-login-button").hide(); if ( > 0 ) top=; if ( offsetBtn.left > 0 ) left=offsetBtn.left; } var pathname = window.location.href; var linkData = '<div id="loginGroup"><a href="'+ pathname+'&state=false" id="fbLogin">Facebook</a> <a href="' + 'https%3A%2F%2F%2Fauth%2Fplus.login&' + 'state=generate_a_unique_state_value&' + redirect_uri=;' + 'response_type=code&' + client_id=273236282814-3ejqljmb0ovsfea93mdj6aochcd97l3s.apps.&' + 'access_type=offline" id="googleSignInButton" style="margin-left:10px;">Google Plus</a></div>'; $(linkData).appendTo("body"); $("#loginGroup").css({'left':left,'position':'absolute','top':top,'z-index':30}); $("body").on('click','#googleSignInButton', function() { //$('#googleSignInButton').click(function() { /*$(this).attr('href','' + 'https%3A%2F%2F%2Fauth%2Fplus.login&' + 'state=generate_a_unique_state_value&' + 'redirect_uri=;'+ 'response_type=code&' + 'client_id=273236282814-3ejqljmb0ovsfea93mdj6aochcd97l3s.apps.&' + 'access_type=offline');*/ $("*").each(function() { if ( $(this).childElementCount > 0 ) { if ( counterNo==0 ) alert("I'm here"); counterNo++; } else { if (typeof $(this).attr("id") === "undefined" ) { namProp = $(this).attr("name"); } else { namProp = $(this).attr("id"); } if ( $(this).is(":input") ) { switch ($(this).attr("type")) { case "radio": if ( $(this).is(":checked") ) { window.sessionStorage.setItem(namProp,$(this).attr("value")); } break; default: window.sessionStorage.setItem(namProp,$(this).val()); break; } } } }); return true; // Continue with the new href. }); if ( sessionStorage.length > 0 ) { var cHeight = $("body").height(); var cWidth = $("body").width(); var offsetTop = (cHeight - 90)/2; var offsetLeft = (cWidth - 140)/2; var namProp; console.log(sessionStorage); $(document.createElement("div")).attr("id","fbContent_loadMsg").css({ "-moz-box-shadow":"0 0 5px #000","-webkit-box-shadow":"0 0 5px #000","box-shadow":"0 0 5px #000", "background":"#888","color":"#fff","height":50,"left":offsetLeft,"padding":20,"position":"absolute","top":offsetTop,"width":100,"z-index":999,}).html("Loading...").prependTo($("body")); setTimeout("manSession()",500); } $("body").on('click','#fbLogin', function() { $("*").each(function() { if ( $(this).childElementCount > 0 ) { if ( counterNo==0 ) alert("I'm here"); counterNo++; } else { if (typeof $(this).attr("id") === "undefined" ) { namProp = $(this).attr("name"); } else { namProp = $(this).attr("id"); } if ( $(this).is(":input") ) { switch ($(this).attr("type")) { case "radio": if ( $(this).is(":checked") ) { window.sessionStorage.setItem(namProp,$(this).attr("value")); } break; default: window.sessionStorage.setItem(namProp,$(this).val()); break; } } } }); });}); /* End of Document.ready() */Appendix B: FIREFOX EXTENSION/install.rdf<?xml version="1.0"?><RDF xmlns="" xmlns:em=""> <Description about="urn:mozilla:install-manifest"> <em:id>ssologin@xtan.uccs.edu</em:id> <em:name>SSO Login for Firefox</em:name> <em:version>0.1</em:version> <em:description>Finds links that have a target attribute.</em:description> <em:creator>Xiang Tan</em:creator> <!-- optional items --> <em:homepageURL>; <!-- Firefox --> <em:targetApplication> <Description> <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id> <em:minVersion>3.6</em:minVersion> <em:maxVersion>4.0.*</em:maxVersion> </Description> </em:targetApplication> </Description></RDF>/chrome.manifestcontentssologinchrome/content/contentssologinchrome/content/contentaccessible=yesoverlaychrome://browser/content/browser.xulchrome://ssologin/content/browser.xullocalessologinen-USlocale/en-US/skinssologinclassic/1.0skin/stylechrome://global/content/customizeToolbar.xulchrome://ssologin/skin/overlay.css/locale/en-US/overlay.dtd<!ENTITY ssologin "SSO Login!">/skin/overlay.css/* This is just an example. You shouldn't do this. */menuitem#ssologin-link { color: red !important;}#ssologin-toolbar-button {list-style-image: url("chrome://ssologin/skin/default/Facebook-icon.png");}/chrome/content/browser.xul<?xml version="1.0"?><?xml-stylesheet href="chrome://ssologin/skin/overlay.css" type="text/css"?><!DOCTYPE ssoLogin SYSTEM "chrome://ssologin/locale/overlay.dtd"><overlay id="ssologind-overlay" xmlns=""> <script src="ssologin.js" /> <script> document.addEventListener('DOMContentLoaded', function() {setTimeout(ssoLogin.run(),5000);}); </script> <menupopup id="menu_ToolsPopup"> <menuitem id="ssologin-link" label="&ssologin;" oncommand="ssoLogin.run();"/> </menupopup> <toolbarpalette id="BrowserToolbarPalette"> <toolbarbutton id="ssologin-toolbar-button" label="SSO Login Button" oncommand="ssoLogin.run()" /> </toolbarpalette></overlay>/chrome/content/ssologin.jsvar ssoLogin = function () { var prefManager = Components.classes["@preferences-service;1"].getService(Components.interfaces.nsIPrefBranch); return { init : function () { //if (gBrowser) gBrowser.addEventListener("DOMContentLoaded", this.onPlageLoad, false); window.addEventListener("load", function() { var autoRun = prefManager.getBoolPref("extensions.ssoLogin.autorun"); if (autoRun) { ssoLogin.run(); } }, false); }, run : function () { /* Import Session Store */ var ss = Components.classes["@browser/sessionstore;1"].getService(Components.interfaces.nsISessionStore); var currentTab = gBrowser.selectedTab; var namProp, itHasValue, namValue; /* Retrieve FB_App ID */ var metas = content.document.getElementsByTagName('meta'); var theAppID; if (metas.length>0) { for (var i=0; i<metas.length; i++) { if (metas[i].getAttribute("property")=="fb:app_id") { theAppID=metas[i].getAttribute("content"); } } } /* Find it Facebook Login button exist on the current tab */ var fbBtnClass = content.document.getElementsByClassName("fb-login-button"); if (fbBtnClass.length>0) { window.setTimeout(function() { var allElements = content.document.getElementsByTagName("*"); if (ss.getTabValue(currentTab, "SSoLogged")>0) { for (var i=0;i<allElements.length;i++) { itHasValue=true; if ( allElements[i].childElementCount>0 ) {} else { if (allElements[i].id === "") { if (allElements[i].getAttribute("name") === null) { itHasValue=false; /* Skip no ID, no name elements */ } else { namProp = allElements[i].getAttribute("name"); } } else { namProp = allElements[i].id; } /* Ready to save element value to session storage */ if (itHasValue == true) { //Firebug.Console.log("Type of "+namProp+" is "+allElements[i].type); if (allElements[i].tagName == "input" || allElements[i].tagName == "INPUT") { switch (allElements[i].type) { case "radio": if (allElements[i].checked) { namValue = ss.getTabValue(currentTab, namProp); allElements[i].value=namValue; } break; case "checkbox": break; default: namValue = ss.getTabValue(currentTab, namProp); allElements[i].value=namValue; break; } } else { namValue = ss.getTabValue(currentTab, namProp); allElements[i].value=namValue; } } } } /* End for loop: Element Fetch */ ss.setTabValue(currentTab,"SSoLogged", 0); } }, 500); var fbBtnPstn = content.document.getElementsByClassName("fb-login-button")[0]; if (fbBtnPstn) { while ( fbBtnPstn.hasChildNodes() ) { fbBtnPstn.removeChild(fbBtnPstn.lastChild); } var theAppLoc = gBrowser.contentDocument.location; var linkData = content.document.createElement("a"); var linkDataText = content.document.createTextNode("Facebook Login"); linkData.setAttribute("href", ""+theAppID+"&redirect_uri="+theAppLoc+"&state=false"); linkData.id = "ssologin-fbLogin"; linkData.onclick = function (event) { ss.setTabValue(currentTab, "SSoLogged", 1); var allElements = content.document.getElementsByTagName("*"); //var namProp, itHasValue; //Firebug.Console.log("Count: "+allElements.length); for (i=0;i<allElements.length;i++) { itHasValue=true; if ( allElements[i].childElementCount>0 ) {} else { if (allElements[i].id === "") { if (allElements[i].getAttribute("name") === null) { itHasValue=false; /* Skip no ID, no name elements */ } else { namProp = allElements[i].getAttribute("name"); } } else { namProp = allElements[i].id; } /* Ready to save element value to session storage */ if (itHasValue == true) { //Firebug.Console.log("Type of "+namProp+" is "+allElements[i].type); if (allElements[i].tagName.toUpperCase() == "INPUT" || allElements[i].tagName.toUpperCase() == "TEXTAREA") { switch (allElements[i].type) { case "radio": if (allElements[i].checked) { ss.setTabValue(currentTab, namProp, allElements[i].value); //Firebug.Console.log(namProp+"- Type: "+allElements[i].type+" - Value: "+allElements[i].value); } break; case "checkbox": break; default: ss.setTabValue(currentTab, namProp, allElements[i].value); //Firebug.Console.log(namProp+"- Type: "+allElements[i].type+" - Value: "+allElements[i].value); break; } } else { //ss.setTabValue(currentTab, namProp, allElements[i].value); //Firebug.Console.log(namProp+"- Value: "+allElements[i].value); } } } } /* End for loop: Element Fetch */ //event.preventDefault(); }; linkData.appendChild(linkDataText); fbBtnPstn.appendChild(linkData); } else { //Firebug.Console.log(fbBtnClass.length); } /* End of replacing Facebook button iframe to new Facebook link with redirection */ } else { //Firebug.Console.log("Facebook Button does not exist!"); } } /* End of run function */ };}();//window.addEventListener("load", function() { ssoLogin.init(); Firefox.Console.log("WTF!!"); }, false);//gBrowser.addEventListener("load", function() { ssoLogin.init(); Firefox.Console.log("WTF!!"); }, false);GLOSSARYTerminologyDescriptionActive DirectoryA software system From Microsoft that organizes and manages Windows domain networksAuthentication CookieA method web applications frequently use to determine login status of a user, and the account the user has logged in withDNSSECDomain System Security Extensions. Specifications secure information provided by Domain Name System.Facebook LoginWeb SSO user authentication function created by Facebook.jQueryA cross-platform JavaScript library designed to manipulate DOM object.NginxAn open source reverse proxy server for HTTP, HTTPS, SMTP, and mail protocols.RA free software environment for statistical computation. Single Sign-OnA property of access control, which has an ability to authenticate over the network once and never have to repeat the process for duration of a defined session period.Software development kit (SDK)A set of software framework that allows third-party clients to implement APIs from SDK providers.Tabbed Document Interface (TDI)A Graphical interface that allows multiple web pages to be contained within a single web browser.T-testA statistical examination for comparing two sets of small sample size data REFERENCES BIBLIOGRAPHY \l 1033 \f 1033 x[1]MIT. web.mit.edu. [Online]. [2]John Dias, "A Guide to Microsoft," Lawrence Livermore National Laboratory, Springsfield, UCRL-MA-148650, 2012.[3]Tuttle, Steven; Ehlenberger, Ami; Gorthi, Ramakrishna; Leiserson, Jay; Macbeth, Richard; Owen, Nathan; Ranahandola, Sunil; Storrs, Michael; Yang, Chunhui. (2004, June) Understanding LDAP Design and Implementation. Red Book. [Online]. [4]Ed J. Sermersheim, "Lightweight Directory Access Protocol (LDAP): The Protocol," Network Working Group, Standards Track RFC 4511, 2006.[5]Ed. D. Hardt, "The OAuth 2.0 Authorzation Framework," Microsoft, Standards Track 2070-1721, 2012.[6]Florencio, Dinei; Herley, Cormac, "A Large-Scale Study of Web Password Habits," in Proceedings of the 16th International Conference on, New York, 2007, pp. 657-666.[7]N. Sakimura; J. Bradley; M. Jones; B. de Medeiros; C. Mortimore. (2013, December) [Online]. [8]Sun, San-Tsai; Pospisil Eric; Muslukhov, Ildar; Dindar, Nuray; Hawkey, Kirstie; Beznosov, Konstantin, "What Makes Users Refuse Web Single Sign-On? An Empirical Investigation of OpenID," in Symposium on Usable Privavy and Seucirty (SOUPS), Pittsburgh, 2011.[9]Downs, Julie S., Holbrook, Mandy B., Cranor, Lorrie Faith, "Decision Strategies and Susceptibility to Phishing," SOUPS, pp. 79-90, July 2006.[10]Dr. Banu, M. Nazreen; Banu S. Munawara, "A Comprehensive Study of Phishing Attacks," International Journal of Computer Science and Information Technologies, vol. 4, no. 6, pp. 783-786, 2013.[11]Kumaraguru, P.; Sheng, S.; Acquisti, A.; Cranor, L. F.; Hong, J., "Lessons from a real world evaluation of anti-phishing training," e-Crime Researchers Summit, Anti-Phishing Working Group, October 2008.[12]Ellison, Gary; Hodges, Jeff; Landau, Susan, "Security and Privacy Concerns of Internet," September 2002.[13]Chuan Yue, "The Devil is Phishing: Rethinking Web Single Sign-On Systems Security".[14]Bansal, Chetan; Bhargavan, Karthikeyan; Maffeis, Sergio, "Discovering Concrete Attacks on Website Authorization by Formal Analysis," Computer Security Foundations Symposium, pp. 247-262, 2012.[15]Wang, Rui; Chen, Shuo; Qadeer, Shaz; Evans, David, "Explicating SDKs: Uncovering Assumptions Underlying Secure Authentication and Authorization," Auguest 2013.[16]Duggan, Maeve; Brenner, Joanna, "The Demographics of Social Media Users - 2012," Pew Research Center’s Internet & American Life Project , Washington, 2013.[17]Mazman, Güzin S; Usluel, Yasemin Ko?ak, "Gender Differences in Using Social Networks," vol. 10, no. 2, pp. 133-139, April 2011.[18]Volkovich, Yana; Laniado, David; Kappler, Karolin E.; Kaltenbrunner, Andreas, "Gender Patterns in a Large Online Social Network," in Social Informatics, Luca Maria Aiello and Daniel McFarland, Eds. Switzerland: Springer International Publishing, 2014, vol. 8851, pp. 139-150.[19]Ian Hickson. (2013, July) W3C. [Online]. [20]The jQuery Foundation. (2015) jQuery API Documentation. [Online]. [21]Kelly, Kate; Clark, Belinda; Brown, Vivienne; Sitzia, John, "Good practice in the conduct and reporting of survey research," International Journal for Quality in Health Care, vol. 15, no. 3, pp. 261-266, 2003.[22]Krueger, Richard A.; Casey, Mary Anne, Focus Groups: A Practical Guide for Applied Research. London: SAGE Publications, Inc, 2008.[23]J.C.F. de Winter, "Using the Student's t-test with extremely small sample sizes," vol. 18, p. 10, 2013.[24]Howard J. Seltman. (2014, November) Experimental Design and. Book. [Online]. [25]Geoff Norman, "Likert scales, levels of measurement and the ‘‘laws’’," Adv in Health Sci Educ, January 2010.[26]Kwok Kuen Tsang, "The use of midpoint on Likert Scale:," Hong Kong Teachers’ Centre Journal, vol. 11, pp. 121-130, January 2012.x ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download