Demystifying Tokens for Securing Enterprise Apis

DEVELOPING AND CONNECTING ISSA Demystifying Tokens for CYBERSECURITY LEADERS GLOBALLY Securing Enterprise APIs Demystifying Tokens for Securing Enterprise APIs By Sandeep Jayashankar – ISSA member Delaware Chapter and Subin Thayyile Kandy – ISSA member Delaware Chapter This article is mainly designed for a software architect to help understand the problems tokens tend to solve, with illustrations of different types of tokens in use. The authors also explain the token implementation methods for an enterprise API mechanism and provide security best practices to be taken care of when implementing the same. Abstract able products, both as a software and a service, to handle the authentication security controls. The security community has Tokens have been the de-facto means that support scalable striven to set many authentication policy definitions, such as and performance-focused security solutions in the current password policies, user lockout policies, captcha frameworks, technological environments. There are currently many op- and provided many scan engines to check the implemented tions and operation modes for anybody thinking of imple- authentication policies. Enterprise organizations have priori- menting a token-based security measure with support of tized their strategic plans concerning security by utilizing the cryptographic mechanisms. With the web-attack landscapes best products to support the applications’ authentication and changing to APIs, and with APIs managed as a decoupled password handling requirements. data handling entity, APIs need to have stringent authorization decision engines that ensure an authorized entity re- Implementing single sign-on with compulsory multi-factor quests each data retrieval. This article is mainly designed for authentication sequences has become a de facto for appli- a software architect to help understand the problems tokens cations and web components in an enterprise environment. tend to solve, with illustrations of different types of tokens Also, organizations have taken the acceptable password pol- in use. The article also explains the token implementation icies seriously, and have taken steps to ensure their users are methods for an enterprise API mechanism and provides se- using only adequately complex passwords for their accounts. curity best practices to be taken care of when implementing The password rotation policies in enterprise organizations the same. are now aptly defined, and employees lose their access if the passwords are not changed before they expire. Furthermore, uthentication (AuthN) and authorization (AuthZ) organizations have taken additional precautions to store sen- have always been the essential security controls in a sitive information such as passwords, tokens, and private programmable system or entity. The program needs keys in centralized key storage locations, and procure them Ato identify who is using it and what features of the program are only during runtime. From an authentication perspective, unrestricted to the user. There are many commercially avail- there have been significant advancements in recent years, 14 – ISSA Journal | July 2020 Demystifying Tokens for Securing Enterprise APIs | Sandeep Jayashankar and Subin Thayyile Kandy and enterprise organizations are taking additional measures and an administrator, the API entity cannot limit what to close security gaps. So, does the buck stops here? data should be available in the response, and thus blindly sends all information back to the application. Eventually, Traditional authorization sequences the application decides whether to show this data to the One of the common security gaps prevalent in current enter- end user or not (depending on the user’s role authenticated prise environments is not to effectively build authorization to the application front-end). definitions in API endpoints. Many API endpoints still use • Not effectively utilizing the existing single sign-on: Single server-based authentication and authorization using basic sign-on (SSO) deployments at enterprise organizations authentication or master tokens for accessing APIs and other support many approaches for APIs to authorize the user external resources. In this architecture scheme, the applica- and retrieve the data. Using service account credentials or tion or an API client uses a single username/password pair master tokens means the APIs would lose the authenticat- or a long-lived token to access the APIs. This design results in ed users’ session context, eventually missing the point of users having full control of the API endpoints, once authenti- utilizing SSO mechanisms for internal applications. Since cated, eventually making it impossible to define and establish most of the enterprise application’s authenticated users authorization rules. Figure 1 considers how API endpoints are under the SSO context, the authenticated users’ ses- authenticate using server-based authorization via master to- sion context should be forward to the underlying APIs for kens or basic authentication [4]. them to authorize the user, and return appropriate data. • Growing dependency on passwords or master tokens: The dependency on passwords or keys would limit developers from not being able to provide features that require some level of automation. This limitation eventually results in an administrative overhead of securing and recycling passwords. To overcome this limitation, developers store the passwords or master tokens and erroneously publish in GitHub. Furthermore, if attackers steal these passwords Figure 1 – Authentication to API servers using Basic Auth or master tokens or master tokens, they would be able to retrieve all the data Following are some of the security loopholes that may result provided by the API. from applications/API endpoints utilizing server-based au- Growing dependency on front-end applications: If APIs do thentication: • not handle authorization mechanisms on their own, they • Inadequate checks in the API or data layer: Data entities eventually depend on the front-end web or mobile appli- such as the API may never be able to deduce who is re- cations to dictate the authorization sequences. To fix the questing the data and which part of the application is uti- created design and security gaps, architects would eventu- lizing it. If the application has more than one role, like user ally make the APIs entirely dependent upon external ap- Members Join ISSA to: l Earn CPEs through Conferences and Education l Network with Industry Leaders l Advance their Careers www.issa.org l Attend Chapter Events to Meet Local Colleagues l Become part of Special Interest Groups (SIGs) that focus on particular topics Join Today: www.issa.org/join Regular Membership $95* CISO Executive Membership $995 (+Chapter Dues: $0-$35*) (Includes Quarterly Forums) *US Dollars/Year July 2020 | ISSA Journal – 15 Demystifying Tokens for Securing Enterprise APIs | Sandeep Jayashankar and Subin Thayyile Kandy plications for all security-related activities, thus changing dependent applications. Also, the conventional methods of the established trust boundaries. If any strategic changes session management, utilizing cookies, have been replaced to the APIs are outlined, for example, to support or service with tokenization systems that ensure granular access con- a mobile application, the APIs should be positioned to be trols and independent implementations. Internet facing. Eventually, the trust boundaries break, and they now have a very minimalistic authentication and Tokens and security controls no authorization mechanism. While designing the security controls in our applications, we need the right tokenization system for the right token con- • Scalability limitations: Due to the dependency of sessions, the application’s scalability factor will always be at stake. tent. Below is a list of common tokenization mechanisms With seasonal or incremental traffic influx, applications that relate to what security controls or the security problem should have a way to increase the number of machines it it solves: uses or its computational power. If an application is de- • Session cookie: Technically a type of a token, session cook- pendent on user sessions, the mechanisms to add new de- ies are used to ensure that an application maintains the vices to support traffic cannot be implemented or will be user session after the user authenticates. Since HTTP is a cumbersome. stateless protocol, the application requires the contents of the cookies to validate every request from the user. Ses- • Lacking defenses against phishing attacks: If an application uses external authentication/authorization sequences, sion identifiers are stored as cookies, and the application’s and if generated master tokens are used, the applications session management sequence verifies whether the user would never consent from their users to use the feature session is valid or not every time the browser submits a or perform actions on users’ behalf. This design gap can request. The cookies are used extensively in server-based be utilized by attackers to formulate a successful phishing authentication and are generally extended further for oth- campaign, and eventually implement complicated cross- er API endpoints. site request forgery attacks. • Authentication tokens: Authentication tokens usually are So, the solution is to ensure that we are utilizing short-lived used instead of the username/password combinations. The dynamic tokens on all our APIs. Dynamic tokens (user to- first time

Load more