GEORGIA INSTITUTE OF TECHNOLOGY Multi Factor Authentication API Yusuf Nadir Saghar Amay Singhal
CONTENTS Abstract... 3 Motivation... 3 Overall Design:... 4 MFA Architecture... 5 Authentication Workflow... 7 Analysis Of MFA Extensions... 10 Resources... 12 Technologies Used... 12 Break-up of effort spent... 12 2 P a g e
MULTI FACTOR AUTHENTICATION API ABSTRACT The purpose of this project is to develop a secure multi-factor authentication API that would provide off-the-shelve components that application developers can configure and use in their own web-applications. The resulting web-application will thus provide multi-factor authentication capability with robust security measures to provide safeguards against the most common attacks on web-applications. This report focuses on the design of the API with respect to security considerations. We have also done security analysis of our multi-factor authentication extensions with respect to security, usability, performance and vulnerabilities. MOTIVATION In the war of functionality versus security, the former wins more often. Security has always been viewed upon as an overhead or afterthought by software developers. Nevertheless, there is a growing awareness in developer community regarding security due to several attacks that have surfaced off late. One of the key challenges in designing a web-application revolves around the problem of identity management. Depending on the need, most websites have authentication mechanisms to identify a particular user and render services accordingly. Single factor authentication has been around for a while now. Yet it s not enough for having any meaningful security. The solution is to have multi-factor authentication which may be something you have ( mobile phone, hardware token, etc ), something you are ( biometric, etc ) or something you know ( passwords, secret question, etc ). Our motivation for developing this API is to eliminate the need for application developers to know the intricate details of security implementation of multi-factor authentication (MFA) and rather focus on the core functionality of the application. Our design is somewhat analogous to Java Authentication and Authorization Services (JAAS) which provides API for performing common authentication and authorization tasks. Our scope is limited to web-applications that are built atop Java Enterprise Edition (JEE) technology. We have incorporated Spring MVC to make our API modular and easily configurable. With our API, the developers can add MFA to their existing web- 3 P a g e
applications just by making some configuration changes. This approach not just increases the productivity of a developer but also reduces the chances of security misconfiguration that renders web-applications vulnerable to attacks. OVERALL DESIGN: As described in the diagram below, the design of an application with MFA incorporated is pretty simple. Typically any web-application will have following main components: view, business logic, MFA and data sources. Web Container View Multi Factor Authentication Module Business Logic Data Sources 4 P a g e
View: The view component is responsible for constructing a response that s rendered for display on browsers. The business module and MFA communicate with the view to display the html content relevant for the website. Views may render in formats like HTML, XML, PDF, XLS, JSP, TXT etc. The developer is responsible for this component. Business Logic: This component hosts all the business logic together with workflows relevant for the application. It also interacts with the various data sources. Data Source: This component refers to data sources like databases, xml, flat files, other applications etc. MFA module: MFA module is responsible for providing views and workflow required to authenticate a user. Once a user identity is established this module is also responsible for proper access control on resources exposed by web-application. MFA ARCHITECTURE MFA API can be split into two major parts: MFA core and MFA extension. 5 P a g e
MFA core: The core includes classes required to make the extensions work. It defines the authentication workflow. From a security standpoint this api ensures that extension incorporates proper security measures while performing authentication. The authentication workflow as described in later section ensures that circumventing the authentication mechanism becomes impossible. MFA extension: The extension api exposes set of interfaces the extension developers are required to implement. The extension glues into the core api and provides actual implementation of the underlying multi-factor authentication mechanism. The extensions that we have developed are: one-time password using email, mobile based and hardware token (simulated via a mobile app). 6 P a g e
AUTHENTICATION WORKFLOW Timing Diagram User Agent(browser) FrontController AuthController Web Resource 1.HTTP request for login 2.check Username 3.HTTP mfa response 4.HTTP request of mfa auth 5.perform mfa 6.HTTP response with resource Activate session if mfa was successful 7.Request resource 8.perform credential check 9.Respond with resource 1. A User agent (browser) initiates a request by hitting the URL of the website. Browser displays an html form where user is required to provide username. After providing the username request goes to the server where further processing is done. SECURITY DESIGN DESICION: during the interaction, user is first required to feed just its username not the password. If the username itself is incorrect we don t proceed to the page where we ask for further information. This prevents an imposter from even going any far 7 P a g e
ahead in case he is just trying some random usernames. implemented such measures on their online-banking websites. Majority of the banks have 2. The FrontController (server side component) receives the request and checks if the username is a valid one or not. If the username is invalid the user is redirected to an error page. If not then following operations are performed on the server side : a. A security state is established with the incoming request. Every incoming request is associated with a unique number that helps us maps the request with current state of the user (authenticated or not). The security state contains information about the unique requestid, time created (used for checking expiration), and multi-factor credentials. b. The first factor for authentication in our API is always the password user knows. Instead of storing the actual password, we store the hash (password, salt) on our servers with every username. This hashed password is stored in the security state of the user. c. For audit purpose, all the operations that are being performed are logged. SECURITY DESIGN DESICION: We don t store passwords on our servers. Instead, we store their hashed value. Hence even if the servers get compromised there is no way an adversary will know the real password of that user. Additionally, we hash the password with salt that is different for each user to enhance security. This salt is changed periodically. Although the developer can specify his choice of hashing algorithm our default is SHA-1. 3. Assuming that the username was valid, the user is now displayed a web-page where he is required to feed following information: a. Password: This is the password that user is enrolled with. b. Second factor for authentication: This may vary depending on the type of extension used. SECURITY DESIGN DESICION: The channel of communication between the server and the browser is encrypted via SSL. Additionally, the password is first hashed and then sent 8 P a g e
over the network. Hence even if somehow the channel was intercepted an adversary won t be able to figure out the real password of the user. The second factor for authentication is generally one-time-password (OTP) or something that s dynamic, unpredictable and shared only between the server and user. The various extensions that we have developed comply with these requirements. 4. The AuthController (server side component) is responsible for taking the input from the user and performing credential validation. It checks for the security state to perform correct association of request with presented credentials. Once the credentials are validated, user is redirected to home page of the application if it was successful or else to the error page. SECURITY DESIGN DESICION: Major source of injection attacks come from nonvalidated user input. For this reason we have provided ParameterRequestExtractor class that performs all necessary input sanitization. This class can be extended to provide variety of validation checks like: username regular expressions to use, minimum password length, etc. Another source of vulnerability in a web-application arises from rogue URL or URL that are unguarded. In order to prevent such cases our API keep tracks of each user request and guarantees to expires it when user is either inactive of a long time(configurable) or logs-out of the website. 5. After the user is successfully logged-in, the MFA api creates a Session and sets a security token inside this session. This token contains information related to current session of the user. The purpose of this token is to validate every incoming request by checking for this token. The presence of this token indicates that a user has authenticated itself and that he is allowed to access the requested resource. SECURITY DESIGN DESICION: the API has been designed in such a way that the security token can well as well be a SAML assertion or an OAuth token, which may enable Single Sign On (SSO) capability for advanced usage. 9 P a g e
ANALYSIS OF MFA EXTENSIONS One-Time-Password via Email: In this extension a OPT is generated using a secure hash algorithm. This OTP is sent to the email address enrolled in the system. The email is sent over an encrypted channel using SSL. Assumptions: a. A valid email address is enrolled by the user in the system. b. The user has access to his email account while performing the authentication. c. The email is received instantly. Pros: a. Ideally only the user will have access to his email account. b. OTP is sufficiently random and cannot be guessed c. Cost effective way obviating need for hardware tokens or biometrics. Cons: a. If user s email account gets compromised, and assuming that adversary also know the password MFA will fail b. Network delays in emails may cause authentication request to expire. c. Requires access to email account at the time of login. : Phone based: In this extension the mobile phone of the user is used as the second factor for authentication. During the authentication process the phone of the user rings. The user is required to press the # button to proceed with the authentication process. If the user realizes that it was a fraudulent attempt then the user also has an option to report this incident. 10 P a g e
Assumptions: a. A valid mobile number in USA is required. b. The user must be in possession of his mobile phone when authenticating. Pros: d. User doesn t need to feed an OTP manually. e. User can report a fraudulent attempt for authentication. Cons: c. A mobile phone can be lost or stolen in which case authentication will fail. d. Telephone carriers will charge money for incoming calls. e. Authentication may not go through due to connectivity problems. Hardware Token simulated by a mobile app: In this extension a mobile phone application is used to generate a unique OTP. The OTP generation algorithm is synced with the server so that the mobile application doesn t have to communicate with the server at all. The OPT is generated by using user s password, unique device id and a random QR code generated on the server. This OTP must be manually entered by the user on the form displayed on the website for authentication. Assumptions: a. An android mobile phone with camera is required. b. The user must be in possession of his mobile phone when authenticating. Pros: f. OTP generated based on shared secret (password), unique device id retrieved thru device API and a randomly generated QR code displayed in the website. g. No need to communicate with the server. Thus avoiding network intrusion and communication overheads h. Since the QR code API generates has a limited lifetime and it never repeats; replay attacks are defeated. 11 P a g e
Cons: c. The mobile application works only with Android phones. d. If an adversary knows user s password and device id of the user s phone he can easily generate the OTP and get authenticated. RESOURCES We have started this project with a view of making it open-source so that everyone can leverage our API to secure their web-applications. The official website of the MFA API is http://code.google.com/a/eclipselabs.org/p/mfa/ The source code of the API can be found in SVN repository http://code.google.com/a/eclipselabs.org/p/mfa/source/checkout Additional documentation including the API docs can be found at http://code.google.com/a/eclipselabs.org/p/mfa/downloads/list TECHNOLOGIES USED Spring Framework Used Spring MVC for designing the entire API Apache Velocity Used as templating engine for rendering views Java Cryptographic Extensions For hashing algorithms and encryption Apache Tomcat Web server for hosting web-applications Phone Factor Third party API for Mobile based authentication Android OS for mobile application development BREAK-UP OF EFFORT SPENT Security design: 40% Learning: 20% Actual implementation: 30% Testing: 5% Documentation: 5% 12 P a g e