devopsy.kinsta.cloud

Tag: authentication

  • FIDO/WebAuthn Passkeys is Inevitable: Get on the Train ¦ IBM CEO Hates WFH

    FIDO/WebAuthn Passkeys is Inevitable: Get on the Train ¦ IBM CEO Hates WFH

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: The Passkeys authentication standard gets a huge boost, and IBM’s Arvind Krishna wants workers back in the office. (more…)

  • Okta Makes No-Code Integration Tool for Identity Platform Available

    Okta Makes No-Code Integration Tool for Identity Platform Available

    Okta today made generally available an Actions Integration capability that makes it possible to integrate third-party tools without having to write any code.

    Shiven Ramji, chief product officer for Okta, said this no-code integration capability for the Okta Customer Identity Cloud extends a simpler approach for managing secrets that is invoked via an application programming interface (API).

    At a time when more responsibility for application security is being shifted left toward developers, the Okta Customer Identity Cloud is gaining traction as an alternative for managing secrets more securely, noted Ramji. Rather than developers attempting to manually verify the identity of end users, it becomes easier to manage identity flows within the context of a larger application development workflow using a cloud service, he added.

    In addition to giving developers access to Actions Integration, Okta is also making third-party integrations developed by partners available via the Auth0 Marketplace. The goal is to encourage providers of application development tools to build integrations that development teams can simply download when needed, said Ramji.

    It’s not clear how much influence developers are exerting over how identity is managed as more organizations embrace DevSecOps best practices for building and deploying applications. Regardless of approach, the overall state of application security should continue to improve as developers embrace new methods of managing identity within their applications. One of the issues that frequently creates a security breach is when developers forget to remove secrets created during the application development process before an application is deployed in a production environment. Cybercriminals today routinely scan for secrets that have been inadvertently stored as text within an application.

    Lees clear is the degree to which developers may opt to update existing applications to take advantage of identity management services that can be invoked via an API or whether they will opt to switch to a cloud service for only new applications.

    One way or another, organizations of all sizes will need to find a way to make it easier for developers to manage identities across multiple applications. There is often a tendency to ascribe responsibility for managing identities to development teams without always providing access to a set of tools to manage the process. In about half of the instances in which organizations adopt Okta Customer Identity Cloud, the decision is made by developers, said Ramji. Many of those developers discover the Okta service when they are building a proof-of-concept for their application, he added.

    The other half of the time the decision is made by more senior leaders on behalf of an entire development team, said Ramji. In some of those cases, organizations are even going to far as to create a team of specialists for managing identities across a portfolio of applications, he noted.

    The core issue, as always, is determining how much time and effort developers will want to spend on identity management versus writing business logic code. All things considered, most developers are going to find it a lot more convenient to invoke an API to access a cloud service versus setting up and maintaining a vault full of application secrets on their own.

  • Session Tokens Vs. JWTs: Choosing Your Session Management Solution

    Session Tokens Vs. JWTs: Choosing Your Session Management Solution

    In the world of authentication today, session tokens and JSON Web Tokens (JWTs) are the two most popular ways to manage user sessions and maintain a user’s authentication state between calls. Impassioned debates pit these solutions against each other, but each has pros and cons worth evaluating. Depending on the needs of your application, it’s even worth considering using them together to get the best of both worlds.

    The Main Differences Between Session Tokens and JWTs

    To understand the differences between session tokens and JWTs, it’s helpful to look at their setup and their impact.

    Setup

    The biggest difference in how session tokens and JWTs are set up is in where and how a user’s authentication information is stored.

    With session tokens, the user’s authentication state is stored in a server-side database as a record that includes a primary identifier for the session (typically a random string that is at least 128 bits long), an identifier for the user, the time the session started, the expiry of the session and, sometimes, additional contextual information like the IP address. Once stored in the database, the session identifier is sent back to the client to be stored as a cookie in the user’s browser.

    With JWTs, the user’s authentication data is stored as a JSON object, client-side, as soon as it’s issued by the server. The object contains a header, a payload (where sensitive user information is stored) and a signature that’s created by combining the header and payload, and then hashed with a secret key to protect the user’s information.

    Impact

    You can also look at session tokens and JWTs based on performance and control.

    Generally, JWTs win out based on performance: They enable faster authorization and more interoperability with external apps. But they demand more developer investment to address their security complexities and ensure that the right guardrails are in place to prevent vulnerabilities.

    Session tokens, on the other hand, enable more control but introduce some latency. While they provide stronger guarantees that each individual request is authorized and is simpler to implement securely, their bottleneck on the server-side database validation comes with a latency overhead that might ruin the user experience for highly responsive applications.

    While this framework can be helpful shorthand for summing up JWTs and session tokens, it falls into the trap of pitting security against performance, as if the two are mutually exclusive. But forward-thinking leaders in growth and security alike recognize that the best solutions leverage security to optimize user experience and accelerate product adoption and growth. One of the best ways to do that with session management is to combine JWTs and session tokens into a powerful hybrid.

    Combining JWTs and Session Tokens

    To date, there are a few different ways companies have combined session tokens and JWTs. One of the simplest ways is to return both a session_token and a JWT when a user starts a session. The session_token is a static value that is good for the lifetime of the session (stored server-side), while the JWT has its own, shorter-lived expiry.

    In this setup, expired JWTs can be passed to the session API in order to retrieve a fresh JWT, and the servers ensure that the underlying session is still active before passing back a new JWT. If the user logs out, this revocation of access will take place within whatever token age you set for your JWT. In other words, you only call the server when the JWT expires or before granting access to particularly sensitive actions.

    Configured this way, this approach to secession management greatly reduces the performance overhead while also protecting you and your end users from the risk of authorizing actions based on stale information. Instead of a tradeoff, JWTs and session tokens are leveraged together to optimize both security and performance.

    Picking the Solution That’s Right for You

    Despite new hybrid approaches like the one described above, there are still maximalists out there who will tell you that one approach is always superior. The truth, of course, is that every application is unique and the security and latency tradeoffs need to be evaluated in context.

    Whether you pursue session tokens, JWTs or a hybrid solution like the one described above, the choice of session management really boils down to how you answer four key questions:

    1. How sensitive is the information you’re storing?

    An extremely security-conscious organization, like a bank or government agency, might want to just use session cookies to ensure that every single call is authorized at that exact moment. Choose your solution based on the risk and cost of a data breach weighed against the cost greater latency might have on your customers.

    2. What are your ambitions for the scalability of your product?

    As mentioned earlier, scaling is much easier with JWTs because no call needs to be made to the server to re-authenticate the session. If handling high-volume traffic is a must for your product, you need to have a plan in place to address potential latency issues.

    3. Which modern features does your application rely on?

    For many modern features like serverless computing, cross-domain functionality, mobile-specific, or single-page applications, JWTs are either preferred or required. Understanding which of these features your product uses will help you understand the session management tools available to you.

    4. How important are performance and uptime to my end-users?

    How quickly do I want to get up and running? For companies whose value proposition relies on a fast, smooth user experience (say, live gaming), JWTs may offer the kind of speed and response time they need. For other kinds of products where latency has less of an impact on their user experience, or where they want a guarantee of security with less initial investment, session tokens may provide the stability and assurance they require.

    The Choice is Yours

    While some die-hard loyalists may always insist on choosing between session tokens and JWTs, modern session management solutions are much more nuanced, so companies can optimize the performance and security requirements for their unique products. With the ability to switch between JWTs and session tokens as needed, there’s more choice now than ever.

  • What GitHub’s 2FA Mandate Means for Devs Everywhere

    What GitHub’s 2FA Mandate Means for Devs Everywhere

    Multifactor authentication (MFA) is becoming increasingly standard within software development organizations, with GitHub recently announcing that two-factor authentication (2FA) will be mandatory for all code contributors by the end of 2023.

    This is a smart move. In recent years, bad actors have frequently initiated attacks by accessing source code through the use of stolen developer credentials. Once inside, they quickly penetrate organizations’ entire code repositories and elevate access to company-wide systems. This was the case with the 2021 SolarWinds compromise that ultimately jeopardized federal agencies, corporations and governmental institutions.

    But for some developers with lofty goals and concentrated timelines, MFA is an extra step that has the potential to slow them down. As organizations continue to implement MFA and other foundational security controls, they may face pushback—but they shouldn’t be deterred. MFA is a critical attack barrier that improves individual protections and can contribute to tightened source code security. 

    If organizations approach implementation thoughtfully, they can lay the foundation for subsequent security controls—and build credibility among their users and within the larger development community.

    The Risks of Lax Individual Developer Security

    Organizations’ source code typically powers a host of upstream programs and products, so it’s valuable for bad actors to launch attacks by infiltrating their repositories. Attackers can also hide malware in source code that can be escalated to breach entire systems and third-party organizations. This risk is heightened by the fact that many companies rely solely on antivirus scans and other surface-level monitoring tools to flag source code vulnerabilities instead of combining them with dynamic testing and penetration testing.

    Attackers typically gain access to source code through stolen developer credentials. While single authentication systems—i.e., usernames and passwords—are the easiest to compromise, MFA creates an additional barrier that’s more difficult for attackers to overcome. While this tool does create additional friction in the development process, it’s worth the extra step. Even for hobbyist or open source developers, compromised source code can cause larger repercussions that put other developers at risk. When it comes to cyberattacks, it’s best to assume any entity is a potential target. 

    Beyond individual security, MFA and other foundational controls are critical to safeguarding organizational reputations and adhering to legal privacy standards. By 2023, 65% of the global population will have personal data covered by privacy regulations. Security measures that protect authentication credentials will become even more important in the coming years, especially for organizations producing source code that powers consumer-facing products and programs. With an intentional approach to implementation, MFA can help mitigate potential source code attacks—and form the basis of comprehensive security programs.

    Four Steps to Successful MFA Implementation 

    The benefits of MFA far outweigh the cost of user friction and developer pushback. Get the most out of this authentication technology by following these four steps to implementation.  

    1. Start small and build credibility. Approach implementation gradually to help developers understand MFA’s value. Successful implementation will give your leadership and security teams credibility for future security initiatives, and it will improve processes for security integration into your larger software development life cycle.  
    2. Examine your security program’s value chain. Implementing foundational security controls like MFA provides an opportunity to examine your security program’s entire value chain. Take time to look for potential vulnerabilities beyond your source code repository and flag areas within your development lifecycle that may create risk.
    3. Layer subsequent security controls. With MFA under your belt, build up your security program with other tools and controls—like dynamic and penetration testing, source code scanning, software composition analysis (SCA) and vulnerability management. The more security tools you layer, the harder you make it for attackers to succeed. 
    4. Plan for continuous optimization. Attackers will devise more ways to thwart MFA as more organizations mandate it. For example, the popularity of using SMS as a second form of authentication declined when attackers developed methods to gain control of mobile phones. To keep up with evolving attacker behaviors, continuously optimize your MFA technology and subsequent security controls. 

    MFA Will Become the Industry Standard

    As bad actors evolve attack methods and privacy regulations strengthen, MFA will undoubtedly become an industry standard for protecting source code repositories. 

    To stay ahead of the curve, focus on the concept of MFA throughout your network by ensuring it protects every system entry point. This extra step is an easy price to pay for improved source code protection—and ultimately safeguards every asset, product and program your code powers. Thoughtfully implementing MFA can lay the foundation for comprehensive source code protection.

  • Common RDS Misconfigurations DevSecOps Teams Should Know

    Common RDS Misconfigurations DevSecOps Teams Should Know

    Relational databases have become the option of choice for organizations wishing to streamline and scale the use, storage and retrieval of data. Many organizations choose AWS Relational Database Service (RDS) to forego the resource-intensive tasks related to database administration including management and continuous oversight. RDS is a fully managed service that simplifies and automates these processes, making it easy to set up, operate and manage relational databases in the cloud—including MySQL, PostgreSQL, MariaDB or Aurora—and their various time-consuming activities. Reducing costs and automating processes makes significant business sense and allows organizations to focus on performance, scalability and cost-effectiveness as data grows.

    That said, AWS is not the owner or the party responsible for securing your data—this duty remains in the hands of the organization. As the cloud provider, AWS does offer an impressive suite of security measures for protecting the infrastructure that runs its cloud services, including access controls, database snapshots and encryption. Their policies, however, clearly state that safeguarding data is within the responsibility of the organization and, as the moderator of your environment, you will be accountable for what occurs within it.

    The following are the six most common RDS misconfigurations related to security and compliance that DevSecOps teams should be aware of to secure their data stores and organizational assets.

    Broken Geo-Trust (aka Data Sovereignty): RDS provides the convenient option to distribute data across various AWS regions. There are various benefits to this data migration including minimizing latency, disaster recovery capabilities and scaling operations. However, the security and governance risks of cross-geo replication may significantly outweigh these benefits. A common misconfiguration includes migrating replicas or storing backups and snapshots in another location. When sensitive data travels and is stored in another geographic location, the organization may be at risk of violating international compliance requirements such as Schrems II (for EU-to-U.S. data transfer). Additionally, data traveling to various locations may not be visible to security teams or managed by DevOps teams—without a continuously updated inventory, data will spread unobstructed and ungoverned. 

    The screenshot below displays a copy-snapshot operation of a U.S.-based RDS datastore to an EU region.

     

    Inadequate Retention Periods: AWS allows organizations to retain database instances for a specific period of time as configured by the user. A common misconfiguration of this feature is the existence of unmonitored standalone snapshots, short-lived backups and a failure to permanently delete records. Organizations that retain records for a long period of time may be in breach of their GDPR obligations, whereas short-lived backups may jeopardize the organization’s ability to recover critical data in case of data loss or a ransomware attack. Clear guidelines and open communication between DevOps teams and compliance leads is the first step toward a healthy environment.

    The screenshot below presents a recommended and comprehensive backup retention period configuration from an RDS datastore creation process.

    Exposed Resources (Network Access): Publicly accessible database ports and RDS instances are a lucrative configuration loophole for malicious actors. Common misconfigurations may cause RDS database snapshots to be publicly accessible, thus providing unauthenticated users with privileges to access and abuse it through brute-force attacks, known CVEs and DDoS attacks—thereby exposing sensitive data. This risk will also impact the organization’s ability to comply with international regulatory requirements and should be a high-priority configuration when creating and maintaining such resources.

    The screenshot below presents recommended network (public) access and default port configuration from an RDS datastore creation process.

    Weak Encryption: Encryption of sensitive data—both at rest and in transit—is a necessary security baseline to ensure the integrity and confidentiality of organizational data and make it inaccessible to unauthorized users. Common encryption misconfigurations may include implementing inadequate encryption for communication channels such as TLSv1.2 (and higher), weak cipher suites or untrusted CA which may lead to a false sense of security. For data at rest, another common misstep is a lack of key rotation or exposure of the encryption key to unauthorized entities.

    The screenshot below presents the recommended basic encryption-at-rest configuration to be enforced when creating an RDS datastore.

    The screenshot below presents recommended basic encryption-in-transit configuration to be enforced when creating an RDS datastore.

    Improper Authentication & Authorization (RBAC): A cornerstone of adequate data security hygiene is ensuring that access is only associated with a unique account based on the principle of least-privilege, using strong identification methods with appropriate justification. With RDS, users may not use IAM accounts, provide over-privileged access and permissions to either the main instance or to backups and refrain from implementing a user-access quarterly review.

    The screenshot below presents the recommended authentication configuration to be enforced when creating an RDS datastore.

    Incomplete Audits: Visibility cannot be considered a point-in-time activity. Monitoring of access and use of sensitive data is an essential component of tracking organizational assets and will provide crucial information in case of an incident or potential data breach. Incomplete or misplaced audit records including login/logout events, short-lived audits or leakage of sensitive data from RDS to audit logs increases the risk. 

    The screenshot below presents the recommended audit and log configurations when creating an RDS datastore.

    Misconfigurations and single points of failure in cloud environments may be unavoidable for all organizations, especially those operating at scale, due to knowledge gaps, high velocity of data and changes and a lack of visibility as the amount of data increases. While the security baseline may be covered by RDS configurations, these are only the minimum required to protect your environment. DevSecOps teams are encouraged to work closely with their compliance leads to ensure that customer data is secured; leveraging RDS for its benefits is a complex and entirely more substantial responsibility. Organizations must view their data as an inherent part of their internal assets. As its owner, they should create appropriate ecosystems that allow continuous oversight and monitoring of the data, gaps that may arise and, most importantly, the controls in place to secure it. 

  • Architecting an Auth System for Applications

    Architecting an Auth System for Applications

    Applications today use many login and authentication methods and workflows. Here, I’ll share the most relevant and proven authentication workflows, which you can use as a basis for architecting and designing an authentication system for traditional web applications, single-page applications and native mobile applications.

    Authentication Workflows for Traditional Web Applications

    Traditional web applications load a web page and provide user functionality using a message-based model where a browser makes an HTTP request to a web server based on the URL in the address bar. The server responds to this request with HTML, CSS and JavaScript and then displays a resource in the browser. Along with traditional web apps, new web apps often still provide functionality in this manner.

    When a user submits a form or clicks a link or button, the browser sends a new HTTP request to the web server and changes the URL in the address bar. The server again responds by returning HTML, CSS and JavaScript and then displaying a resource in the browser.

    Browsers support only two HTTP methods for traditional web apps: GET and POST. GET is used to request data from a specified resource and POST is used to send data to a server to create or update a resource.

    Below are several workflows you can use for traditional web app login and authentication. Note that the application backend is the backend of the application (not the identity provider, or IdP) and native login form is a form built directly into the application instead of an external login form.

    Native login form to the application backend using …

    JWTs and refresh tokens stored in cookies

    Sessions

    Sessions plus refresh tokens stored in cookies

    OAuth 2 authorization code grant using …

    JWTs and refresh tokens stored in cookies (RECOMMENDED)

    Sessions (RECOMMENDED)

    Sessions plus refresh tokens stored in cookies

    OAuth 2 resource owner password credentials grant using …

    JWTs and refresh tokens stored in cookies

    Sessions

    Sessions plus refresh tokens stored in cookies

    Authentication Workflows for Single-Page Applications

    A single-page web app (SPA, pronounced as “spa” or “S-P-A”) runs entirely in the browser after loading the HTML, CSS and JavaScript source code from a web page. After retrieving the HTML, CSS and JavaScript that make up the application, the browser invokes a JavaScript framework that bootstraps and then renders the application.

    SPAs call APIs to handle user interactions and input. For example, if a user clicks a link or submits a form, the SPA might render a different page or form.

    APIs are invoked using XMLHttpRequest, a built-in browser object that can make HTTP requests in JavaScript. When the server responds, the JavaScript running in the browser updates the data dynamically without performing a  full page refresh.

    SPAs use a single request and response model. Since the browser uses XMLHttpRequest, it can support GET and POST, as well as other standard HTTP methods, such as PUT and DELETE. (PUT is used to replace all current representations of the specified resource and DELETE is used to, well, delete the specified resource.) The HTTP method chosen tells the server how to handle the request.

    Here are some workflows you can use for SPA login and authentication.

    Native login form to the application backend using …

    JWTs and refresh tokens stored in cookies

    Sessions

    Sessions plus refresh tokens stored in cookies

    Native login form to FusionAuth using …

    JWTs stored in local storage and refresh tokens stored in cookies

    JWTs and refresh tokens stored in cookies

    JWTs and refresh tokens stored in cookies

    OAuth 2 authorization code grant using …

    JWTs and refresh tokens stored in cookies (RECOMMENDED)

    Sessions (RECOMMENDED)

    Sessions plus refresh tokens stored in cookies

    OAuth 2 implicit grant using …

    JWTs stored in cookies

    JWTs stored in local storage

    Sessions

    OAuth 2 resource owner password credentials grant using …

    JWTs and refresh tokens stored in cookies

    Sessions

    Sessions plus refresh tokens stored in cookies

    When using OAuth for SPAs, note that the browser navigates away from the SPA to the OAuth provider. Once the OAuth workflow is complete, the browser is sent back to the SPA page where it quickly restarts the SPA with cached assets.

    Authentication Workflows for Native Mobile Applications

    Native mobile applications are usually installed on a mobile device or any smart device through an online marketplace like App Store and Google Play Store. Clicking the application icon on the device launches the device operating system, which starts the application and its user interface.

    Almost all native applications call APIs on the server to handle user interactions and input, such as button clicks and form submissions. Native applications often use libraries designed to directly access all of the classes, objects, functions and methods of the source code to communicate quickly with APIs and simplify API calls.

    auth mobile

    Here are a few workflows you can use for native mobile application login and authentication:

    Native login form to the application backend using JWTs and refresh tokens

    Native login form to FusionAuth using JWTs and refresh tokens (RECOMMENDED)

    OAuth 2 resource owner password credentials grant using JWTs and refresh tokens

    Note that native mobile applications can also use the OAuth authorization code grant to exchange an authorization code for an access token. This workflow works with many IdPs and is essentially the same as described in the preceding traditional web application and single-page application sections. The main difference is that the native application pulls the JWT and refresh tokens from the web view at the end of the OAuth workflow.

    Authentication System Best Practices

    The workflows listed above should give you a baseline for following authentication system best practices and architecting a sound login and authentication system for your applications. While these examples use FusionAuth as the IdP, any IdP can be used. Most IdPs are capable of a wide variety of login and authentication workflows, and the examples here are not meant to be exhaustive.

    As you’re designing an authentication system for traditional web applications, single-page applications or native mobile applications, keep in mind that some IdP login workflows can pose serious security risks. As with all things having to do with digital identities and user and data security, it’s important to choose both your IdP and your authentication workflow wisely.

  • FusionAuth Adds Support for ARM-Based Architecture

    FusionAuth Adds Support for ARM-Based Architecture

    Most developers need three things in life: Control, interesting projects and the ability to build on the technology of their choice. Now a new development promises to put all three in developers’ hands—FusionAuth’s announcement of its support for ARM-based architecture.

    FusionAuth solutions offer multi-factor authentication, passwordless authentication and single sign-on, among other features. ARM-based architectures offer simplicity with a lower and cooler energy footprint. Translated into DevSecOps benefits, this means that FusionAuth just made it significantly easier for developers to meet identity and authorization requirements and strengthen their security when building on ARM architecture.

    We talked to Daniel DeGroff, co-CTO at FusionAuth, to find out the details on how this support can benefit DevSecOps.

    The Movement to ARM-based Architecture

    You’ve probably noticed many forward-thinking developers are turning toward ARM-based technologies. Developers can count on interoperability across different implementations and different devices—and ARM processors offer a lower operating temperature and reduced power consumption. They’re also inexpensive to produce, making their price point attractive. This has earned them a place in everything from servers to smartphones to the world’s fastest supercomputer.

    With many developers spotting the potential for higher performance and cost savings, it’s no surprise that vendors like FusionAuth would move to support ARM-based infrastructure, as well. By working with ARM processors, the company can support additional use cases such as IoT and high-performance cloud platforms that are built on ARM-based architectures. DeGroff described it as a pragmatic—and inevitable—move, and said, “If you want to use these new machines, you have to support this architecture in some fashion.”

    “We develop on the Apple MacBook, and all new workstations will use Apple’s custom silicon which is based on the ARM architecture,” he pointed out. “ARM is generally faster and less expensive than an equivalent x86 server platform, and many of the low-power IoT devices will utilize the ARM architecture as well.”

    DevSecOps Benefits: Greater Flexibility, Easier Security

    FusionAuth’s ARM support can make the average security-minded dev’s life easier in several ways. FusionAuth runs on any platform, anywhere; by supporting ARM-based technologies, the company is extending developers’ ability to deploy its authentication and authorization platform how and where they want. “We have to ensure FusionAuth runs where our users want to develop,” DeGroff said.

    In helping developers build on ARM-based architecture, FusionAuth also makes it easier for them to use an API to bring in FusionAuth at the early stages of app or software development. One of the platform’s selling points is that it makes it simpler for developers to solve typical authentication obstacles, like weak password policies or difficulty with privileged access rules, DeGroff said. By supporting ARM-based technologies, FusionAuth aims to help developers successfully meet even tough security requirements through flexible, sophisticated identity authentication and access tools—and do so earlier in their development cycles.

    A Seamless Transition to Smarter Authentication

    If you’re a developer interested in exploring the combination of FusionAuth and ARM technologies, DeGroff said any transition will feel seamless. “There is a great business case for moving workloads to this architecture,” he points out. Developers who want to take advantage of the improved performance and lower costs can begin to migrate workloads to ARM-based platforms now.”