The Secret Life of Secrets

The Secret Life of Secrets

Speakers: Dylan Ayrey, Hon Kwok

Conference: BSidesSF 2024

YouTube: https://www.youtube.com/watch?v=D2ldUyiwV54

Overview

This talk, "The Secret Life of Secrets," delivered by Dylan Ayrey and Hon Kwok at BSidesSF 2024, delves into the often-overlooked yet critical impact of user experience (UX) and design choices on the security of API keys, secrets, and cryptographic tokens. The presenters argue that the way secrets are designed—their "shape and texture"—fundamentally influences how users interact with them, leading either to increased security or widespread leakage and vulnerabilities. The core premise is that design dictates behavior, and even seemingly minor design decisions can have profound, far-reaching security implications across the industry.

Dylan Ayrey, a security researcher and founder of Truffle Security, known for the open-source secret-finding tool TruffleHog, brings extensive experience in identifying leaked secrets in the wild. Hon Kwok, working at the intersection of software security and UX, complements this perspective by highlighting how human factors and design patterns contribute to these security outcomes. Together, they challenge the conventional wisdom surrounding secret management, urging developers and security professionals to critically examine the underlying design principles of authentication tokens and API keys rather than blindly adopting popular patterns.

The presentation uses compelling real-world and illustrative examples, from the pervasive issue of webhook URLs to the complexities of JSON Web Tokens (JWTs) and the pitfalls of user-generated keys. It underscores that security is not solely a technical implementation challenge but is deeply intertwined with how systems are designed for human interaction. By dissecting specific design flaws and their consequences, the speakers provide actionable insights for creating more secure systems by prioritizing thoughtful design and user experience in the lifecycle of secrets.

Background

▶ Watch: Core thesis: UX design of API keys directly impacts security outcomes. (4:00)

The talk begins by establishing a foundational principle: user experience and design have a dramatic influence on outcomes, even in non-security contexts. Dylan Ayrey illustrates this with two compelling anecdotes. First, a study on medication packaging design revealed that simple changes in branding, active ingredient display, and dosage information could reduce medication confusion errors by two-thirds. For a younger group, errors dropped from 41% to 8%, and for an older group, from 68% to 16%. Second, the founder of Code for America highlighted that improving the user experience of the US welfare system by just 10% could provide more aid to people in need than all US charities combined, simply by making it easier for eligible individuals to sign up. These examples set the stage for the central argument: if UX can dramatically improve health outcomes or social welfare, it can certainly impact security.

In the realm of API keys and secrets, this principle is often overlooked. The speakers note a significant gap in existing documentation: while guides for API design abound (e.g., Postman's top search result), they rarely, if ever, provide comprehensive advice on how to design the keys themselves. Security considerations, when present, typically focus on API access controls (like role-based access control or IDOR) rather than the form factor and user experience of the keys. This omission is critical because, as the speakers emphasize, the "shape and texture" of keys directly influences how they are handled by developers and users, thereby impacting their likelihood of being leaked or misused.

The problem is exacerbated by the tendency to blindly copy design patterns without understanding their origins or implications. The talk references the outdated "change your password once a month" rule, which originated from concerns about brute-forcing non-networked mainframes. This rule persisted long after its relevance diminished, demonstrating how patterns can become entrenched without critical re-evaluation. Similarly, in API key design, patterns emerge and are copied, often without security input, leading to widespread vulnerabilities. The speakers, drawing on their extensive experience with tools like TruffleHog that find leaked secrets, aim to shed light on these design-driven security issues.

Key Findings

▶ Watch: Consequence: Webhook URLs are the most leaked SAS keys due to their URL-like ... (13:00)

The presentation uncovers several critical findings regarding the design and handling of secrets, demonstrating how user experience directly correlates with security outcomes:

1. Webhooks as Leaky API Keys: The design pattern of embedding API keys directly into URLs, commonly known as webhooks, has led to them becoming the most frequently leaked SaaS key type (excluding cloud keys). This is because their URL-like appearance encourages users to treat them as ordinary URLs, leading to insecure handling such as logging, caching, and sharing. A fictitious reenactment of a product manager overriding security concerns at "Catchat" (a stand-in for real companies like Slack, Microsoft Teams, and Discord) illustrated how this pattern became widespread, despite initial security warnings. The inventor of the term "webhook," Jeff, confirmed that these do not align with his original definition, further highlighting the design misinterpretation.

1. JSON Web Token (JWT) Design Flaws:

• URL-Safe Encoding: JWTs are specifically designed using URL-safe Base64 encoding, which, while seemingly convenient, encourages their inclusion in URLs. This design choice directly contributes to their exposure in logs, caches, and browser histories, undermining their intended security.
• Weak Symmetric Keys: A significant vulnerability arises from the use of weak symmetric keys (often simple passwords) to sign JWTs. The speakers demonstrated this by analyzing thousands of symmetric key JWTs scraped from Shodan. They successfully cracked over 2% of these production keys using Hashcat, enabling the manufacturing of arbitrary tokens with any claims. This highlights that if a non-negligible percentage of developers will misuse a feature, its recommendation becomes problematic.
• The "None" Algorithm Vulnerability: The JWT specification's inclusion of "none" as a valid algorithm type, coupled with initial library implementations that treated it as a verified signature by default if no algorithm was specified, created a critical bypass. This allowed attackers to create unsigned tokens that would be accepted as valid, leading to numerous takeover vulnerabilities.
• Cryptographic Complexity Burden: JWTs introduce a wide array of complex cryptographic considerations (e.g., algorithm choices, key management, revocation) that developers are expected to understand and implement correctly. The speakers argue that this burden is too high, leading to frequent misconfigurations and vulnerabilities, a point even acknowledged by one of the original authors of the JWT specification.

1. Insecure User-Generated Keys (Bring Your Own Key - BYOK): Allowing users to generate and upload their own keys, such as SSH private keys for platforms like GitHub or Oracle Cloud, introduces significant security risks.

• Weak Key Generation: Users often generate keys that are too short or otherwise insecure. The speakers demonstrated that GitHub, despite recommending 2048-bit keys, accepts 1024-bit keys, which are theoretically factorable (the largest factored key to date was 1039 bits). An analysis of all SSH public keys on GitHub revealed over 11,000 keys that were 1024 bits or smaller, making them potentially vulnerable to factoring attacks.
• Key Reuse: A common user behavior is the reuse of keys across multiple accounts or the copying of insecure keys from public sources, further compromising security. This highlights that giving users autonomy over security-critical components without strong guardrails inevitably leads to insecure practices.

In essence, the overarching finding is that design influences behavior, and when security-critical components like API keys or tokens are designed without considering human interaction patterns or the potential for misuse, widespread vulnerabilities are an inevitable consequence.

Technical Deep Dive

▶ Watch: JWT design flaws: URL-safe encoding, 'none' algorithm, and weak symmetric key... (17:00)

The talk provides a detailed examination of how specific design choices in API keys and tokens lead to security vulnerabilities, focusing on webhooks, JSON Web Tokens (JWTs), and user-generated keys.

Webhooks: API Keys in URL Form

The core technical issue with webhooks, as highlighted by the "Catchat" reenactment, is the conflation of an API key with a URL.

• Problematic Design: A webhook URL, such as https://example.com/webhook/api_key_value, allows arbitrary messages, usernames, profile pictures, and file attachments to be sent to a channel. From a security perspective, this is functionally an API key.
• User Interaction Patterns: Users are accustomed to URLs being shareable, cacheable, and logged. This ingrained behavior directly conflicts with the secure handling required for an API key.
• Logging and Caching: URLs are routinely logged by web servers, proxies, and browsers, and can be cached by various network components. This means that sensitive API keys embedded in webhook URLs are persistently recorded in numerous locations, making them highly susceptible to exposure. The speakers referenced CWE around sensitive query strings in URLs as a known vulnerability pattern.
• Real-World Impact: The analysis of leaked secrets showed that webhook URLs are the number one most commonly leaked SaaS key (excluding cloud keys). This prevalence is a direct consequence of their URL-like design, which encourages insecure handling. The speakers noted that companies like Slack, Microsoft Teams, and Discord all adopted this pattern.
• Distinction from Capability URLs: The concept of capability URLs was discussed, which are URLs that can perform stateful actions, often initiated by a user (e.g., password reset links). However, webhooks are typically initiated by services to transact with an API, making them distinct and more akin to traditional API keys, but with the added risk of URL-based exposure.

JSON Web Tokens (JWTs): Cryptographic Complexity and Design Flaws

JWTs are designed for creating compact, URL-safe tokens that can be used for authentication and information exchange. However, their design introduces significant cryptographic and UX challenges.

• Structure: A JWT consists of three parts: a header, a payload, and a signature, separated by dots.
• Header: Specifies the algorithm used for the signature (e.g., HS256, RS256).
• Payload: Contains a set of claims (e.g., user ID, roles, expiration time).
• Signature: Cryptographically verifies the integrity of the header and payload.
• Encoding: JWTs use URL-safe Base64 encoding, not standard Base64. This design choice, intended for easy transmission in URLs, paradoxically contributes to their leakage by making them appear suitable for URL inclusion, leading to logging and caching issues similar to webhooks.
• Symmetric vs. Asymmetric Keys: The algorithm specified in the header determines whether a symmetric key (e.g., HMAC with HS256) or an asymmetric key pair (e.g., RSA with RS256) is used for signing.
• Weak Symmetric Keys: When symmetric keys are used, they are often implemented as simple passwords by developers. The speakers demonstrated this vulnerability by downloading "a few thousand" symmetric key JWTs from Shodan. Using Hashcat, they were able to guess the password for over 2% of these production tokens. This offline cracking capability allows an attacker to then manufacture arbitrary JWTs with any desired claims, impersonating users or elevating privileges.
• Expiration and Revocation: The expiration (exp) claim in the payload is optional. If omitted, JWTs cannot be revoked until they naturally expire (if an expiration is set). The stateless nature of JWTs, designed to avoid database lookups, makes real-time revocation challenging without reintroducing a database check, which defeats one of their primary benefits.
• The "None" Algorithm Vulnerability: A critical design flaw was the inclusion of none as a valid algorithm in the JWT specification. This allowed for the creation of JWTs without any cryptographic signature. Early JWT libraries, when a developer did not explicitly specify an algorithm, would often default to accepting none as a valid, verified token. This led to numerous bypasses where attackers could forge tokens by simply setting the algorithm to none and removing the signature, and the application would accept them as legitimate.
• Cryptographic Burden: The speakers emphasized that introducing cryptography into a system inevitably introduces cryptographic problems. The latest JWT specification lists numerous cryptographic considerations, including algorithm agility, key rotation, side-channel attacks, and more. This complexity places a significant burden on developers, leading to a "non-negligible percentage" making mistakes, even according to one of the original authors of the JWT spec.

Bring Your Own Key (BYOK) Patterns: User Autonomy vs. Security

Platforms like GitHub and Oracle Cloud allow users to upload their own SSH private keys for API interaction. This "bring your own key" model delegates key generation and management to the end-user, with significant security consequences.

• Insecure Key Generation: Users frequently generate keys that are too short or otherwise cryptographically weak.
• GitHub Example: GitHub recommends 2048-bit keys. The speakers tested uploading a 512-bit key, which GitHub rejected. However, a 1024-bit key, generated by ChatGPT, was accepted. This is problematic because the largest integer factored to date was 1039 bits, meaning 1024-bit keys are theoretically within the realm of being factorable.
• Real-World Analysis: By downloading and analyzing "every single SSH public key" from GitHub, the speakers found over 11,000 keys that were 1024 bits or smaller. These keys were associated with pushes to "pretty big named repos," indicating a significant risk.
• Key Reuse: The analysis also revealed instances of SSH keys being reused across multiple user accounts, a practice that severely compromises security if one instance of the key is compromised.
• Lack of Guard Rails: While GitHub provides recommendations, the acceptance of weaker keys demonstrates insufficient guard rails. When users are given autonomy over security-critical functions, a percentage will inevitably make insecure choices.

mTLS (Brief Mention):

The talk briefly touched on mTLS (mutual TLS) as another design pattern involving cryptography. It was noted that mTLS introduces similar challenges to JWTs, including revocation issues, key reuse, and complex cryptographic configuration options. This reinforces the general principle that introducing cryptography adds complexity and potential vulnerabilities if not managed meticulously.

Demo / Proof of Concept

▶ Watch: BYOK (Bring Your Own Key) patterns: user autonomy leads to insecure key gener... (26:00)

The presentation incorporated several demonstrations and proofs of concept to illustrate the real-world impact of their findings:

1. Catchat Webhook Reenactment: The speakers performed a fictitious reenactment of a product design meeting at "Catchat," a company designed to make cats collaborate. This scenario vividly depicted how a product manager, prioritizing API adoption and user engagement with URLs, pushed for the creation of "webhook URLs" despite strong objections from a security team member. The security professional's concerns about URLs being logged, cached, and shared, and the lack of user awareness regarding their sensitive nature, were dismissed. This reenactment served as a powerful illustration of how critical security decisions are often made without adequate security input, leading to widespread adoption of insecure design patterns by real companies like Slack, Microsoft Teams, and Discord.

1. JWT Weak Symmetric Key Cracking: To demonstrate the vulnerability of JWTs signed with weak symmetric keys, the speakers conducted a practical experiment. They scraped "a few thousand" symmetric key JWTs from Shodan, a search engine for internet-connected devices. These were production keys found on the internet. They then used Hashcat, a powerful password recovery tool, to attempt to crack the symmetric keys (passwords) used to sign these JWTs. The results were striking: they were able to guess the password for over 2% of these production JWTs. This proof of concept highlighted that even with a "not the most sophisticated password cracking setup," a significant number of real-world JWTs are vulnerable to offline cracking, allowing attackers to forge tokens and impersonate users.

1. GitHub SSH Key Upload Test: The speakers demonstrated the lack of robust guard rails in "Bring Your Own Key" (BYOK) systems using GitHub as an example.

• They first attempted to upload a 512-bit SSH key to GitHub, which was rejected with a message recommending at least 2048 bits. This showed some level of protection.
• However, they then generated a 1024-bit SSH key using ChatGPT and successfully uploaded it to GitHub. This was a critical demonstration because, as they noted, the largest integer factored to date was 1039 bits, meaning 1024-bit keys are theoretically within the realm of being factorable. GitHub's acceptance of such a key, despite its own recommendation, illustrated that user autonomy without strict enforcement can lead to insecure configurations.

1. GitHub SSH Key Analysis: Building on the upload test, the speakers conducted a large-scale analysis of all SSH public keys uploaded to GitHub. They downloaded "every single SSH public key off of the platform from every single user" and analyzed them. Their findings revealed that over 11,000 of these keys were 1024 bits or smaller, making them potentially vulnerable to factoring attacks. Furthermore, they observed instances of keys being reused between accounts, a practice that severely compromises security. While specific repository names were not disclosed, the speakers stated that these keys were associated with pushes to "pretty big named repos," underscoring the potential impact of such vulnerabilities.

These demonstrations collectively provided concrete evidence for the talk's central thesis: design choices and user experience profoundly influence the security posture of secrets, often leading to widespread, exploitable vulnerabilities in production environments.

Defensive Implications

▶ Watch: Key recommendations: Generate keys for users, use prefixes, be cautious with ... (31:00)

The insights from "The Secret Life of Secrets" offer crucial guidance for defenders looking to improve the security posture of their systems, particularly concerning API keys, secrets, and authentication tokens. The recommendations focus on proactive design choices and robust guard rails rather than reactive measures.

1. Generate Security Keys for Users: The most critical recommendation is to never rely on end-users to generate their own security keys. As demonstrated with the GitHub SSH key example, when given the autonomy to generate keys, a non-negligible percentage of users will make insecure choices (e.g., too short, reused, or copied from insecure sources). Instead, systems should generate strong, cryptographically secure keys for users, ensuring they meet minimum length and entropy requirements.

1. Exercise Caution When Introducing Cryptography: Cryptography is a powerful tool, but it introduces significant complexity and its own set of potential problems. Defenders should carefully evaluate whether cryptography is truly necessary for a given problem. If a simpler, non-cryptographic solution can achieve the desired outcome without introducing the complexities of key management, algorithm choices, and revocation, it should be preferred. For instance, if a system frequently hits a database anyway, the stateless benefits of JWTs might not outweigh their cryptographic risks.

1. Make Leaked Keys Easily Discoverable: Design keys in a way that makes them immediately identifiable as secrets, especially in logs or when found by secret scanners.

• Prefixing Keys: A highly effective strategy is to prefix keys with a clear, consistent identifier (e.g., sk_live_, ghs_). This allows security teams and automated tools to quickly identify potential secrets in logs or codebases. The talk cited GitHub's past issue with tokens resembling SHA-1 hashes, which were hard to distinguish from legitimate hashes, as a cautionary tale. Companies like AWS, GitHub, Tailscale, Twilio, and Stripe successfully employ this pattern.
• Consistent Length and Texture: Keys should have a consistent, secure length and a random, non-guessable "texture" that clearly distinguishes them from ordinary strings or hashes.

1. Follow Established Secure Design Patterns: Avoid "reinventing the wheel" when secure patterns already exist and have proven effective. The pattern of generating a securely random, fixed-length, prefixed key for users is widely adopted by leading technology companies for a reason: it influences good security behavior and reduces leakage. Defenders should adopt and adapt these proven patterns rather than creating novel, potentially insecure designs.

1. Implement Robust Guard Rails: Even when some user autonomy is necessary, systems must implement strong guard rails to prevent insecure choices. For example, if users must upload keys, the system should strictly enforce minimum cryptographic strength (e.g., rejecting keys below 2048 bits for RSA) and check for known insecure patterns or reuse. The GitHub example of accepting 1024-bit keys despite recommending 2048-bit highlights a gap in guard rail implementation.

1. Question the "Why": Defenders should cultivate a critical mindset, always questioning the underlying reasons behind existing or proposed design patterns. Why is a key designed in a certain way? How might this design influence user behavior? Does it align with security best practices, or is it a legacy pattern that no longer serves its original purpose (like the "change password monthly" rule)? This critical examination can prevent the adoption of insecure patterns.

1. Prioritize Simplicity: As the (misattributed) Einstein quote suggests, "Make things as simple as possible, but not simpler." Unnecessary complexity in secret design or cryptographic implementation increases the likelihood of errors and vulnerabilities. If a simpler, less risky approach can achieve the security objectives, it should be chosen.

By integrating these defensive implications into the design and development lifecycle, organizations can significantly reduce the attack surface related to secrets and API keys, moving towards a more secure and user-friendly ecosystem.

Key Takeaways

• Design Drives Behavior: The user experience and design of API keys and secrets profoundly influence how they are handled, directly impacting their security posture.
• Webhooks are Leaky by Design: API keys disguised as URLs (webhooks) are highly prone to leakage due logging, caching, and sharing, making them the most commonly leaked SaaS key type (excluding cloud keys).
• JWTs Introduce Complex Risks: JSON Web Tokens (JWTs) bring significant cryptographic complexity, leading to vulnerabilities such as weak symmetric keys (over 2% cracked in the wild) and critical bypasses like the "none" algorithm.
• User-Generated Keys are Often Insecure: Allowing users to generate their own keys (e.g., SSH keys) frequently results in insecure choices (e.g., 1024-bit keys accepted by GitHub despite recommendations) and widespread key reuse.
• Prioritize Secure Key Generation and Discoverability: Systems should generate strong, prefixed keys for users and avoid unnecessary cryptographic complexity. Prefixes make leaked keys easily discoverable by scanners and in logs.
• Implement Strong Guard Rails and Question Patterns: Always provide robust guard rails to prevent insecure user actions and critically evaluate the "why" behind design patterns to avoid blindly adopting insecure practices.

About the Speaker(s)

Dylan Ayrey is a security researcher and the founder of Truffle Security. He is also the author of the popular open-source tool TruffleHog, which is designed to find leaked secrets. Dylan has a strong background in the security community, having spoken at major conferences such as Def Con and Black Hat. His work at Truffle Security and with TruffleHog has given him extensive experience and insight into the prevalence and patterns of leaked secrets.

Hon Kwok works at the intersection of software security and user experience (UX). Her expertise lies in understanding how design choices impact security outcomes and user behavior. Hon has also shared her knowledge at various security conferences, including BSides SF and Black Hat Arsenal. Her contributions to the talk emphasize the critical role of UX in preventing security vulnerabilities related to secrets.