Passbolt security audit 2021 shows specification gaps in cryptography

At a glance

What this is: PassBolt’s 2021 audit summary says Cure53 found seven findings and seven informational issues, with the highest-severity issues tied to encryption guidance and nonce handling in authentication.

Why it matters: For IAM and secrets practitioners, the article shows how specification quality shapes the security of authentication flows, server configuration, and credential-handling systems before implementation bugs even appear.

By the numbers:

• PBL-01-001 and PBL-01-004 were marked as high severity because they covered transport layer encryption and nonce generation for authentication operations.
• Wikipedia says 2.71 quintillion random version-4 UUIDs are needed for a 50% probability of at least one collision.

Context

Cryptography specifications define how authentication, transport protection, and nonce handling are supposed to behave before code is written or deployed. In Passbolt’s 2021 audit summary, the issue is not a broken product claim but the risk created when security-critical requirements remain underspecified.

That matters for secrets management and identity systems because ambiguity in protocol behaviour can push implementers toward unsafe defaults, inconsistent controls, or hidden assumptions about trust boundaries. The article treats specification clarity as part of the security model, not as documentation housekeeping.

For teams governing NHIs, shared credential systems, or authenticated collaboration tools, the underlying question is whether security expectations are precise enough to survive implementation across client, server, and deployment environments.

Key questions

Q: What breaks when cryptographic specifications leave transport security undefined?

A: When transport security is left undefined, teams can ship deployments that depend on local judgement rather than a mandatory security baseline. That weakens the trust boundary around authentication and secret exchange, and it makes implementation quality depend on each administrator’s interpretation instead of the system contract.

Q: Why do nonce requirements matter in challenge-based authentication?

A: Nonce requirements matter because the challenge must be unique and used once to preserve authentication integrity. If a system allows reuse, replay, or ambiguous token behaviour, the protocol no longer guarantees the property it was designed to provide. In practice, that turns a cryptographic assurance into a documentation assumption.

Q: How should teams evaluate whether a security specification is complete enough?

A: Teams should check whether the specification defines the security property, the allowed implementation behaviour, and the failure conditions with enough precision that different engineers would reach the same conclusion. If a reviewer can interpret the requirement two ways, it is not complete enough for cryptographic assurance.

Q: What should organisations do when audit findings point to specification gaps rather than code defects?

A: They should treat the gap as a governance issue, not only an engineering task. The right response is to update the protocol contract, align implementation and deployment guidance, and carry the missing requirement into future certification and review cycles.

Technical breakdown

Transport-layer encryption gaps in security specifications

When a specification does not clearly define transport-layer protection, implementers may rely on defaults, hosting conventions, or local judgement to decide whether HTTPS, cipher suite restrictions, and related checks are mandatory. That creates a gap between intended security and deployed security. In Passbolt’s audit summary, the concern is not that encryption is absent in every case, but that the specification left enough undefined behaviour for insecure deployment choices to remain possible. For identity and secret-handling systems, transport security is part of the trust boundary, because credentials and authentication exchanges move across that channel.

Practical implication: Treat transport security requirements as normative specification content, not optional deployment guidance.

Nonce generation and challenge-response authentication

A nonce is a value that should be unique for a single use in a protocol exchange, especially in challenge-based authentication. If a system describes a nonce but implements it with values that are only probabilistically unique, the authentication design can drift from the security property the protocol assumes. Passbolt’s article notes that GpgAuth uses randomly generated UUIDs for challenges, while the report wanted stricter nonce correctness and a larger challenge size. This is a specification problem because the protocol’s security expectations depend on how uniqueness is expressed and enforced.

Practical implication: Define nonce requirements precisely enough that implementation cannot confuse randomness with single-use guarantees.

Why specification quality is part of cryptographic assurance

Cryptographic review is not only about finding code defects. It also tests whether the written security model is complete enough to prevent unsafe implementation decisions. Passbolt’s summary makes that distinction explicit: several findings were framed as missing or unclear specification details, and the report says they may not have an immediate practical impact on the current software. That does not make them harmless. In IAM and secrets systems, specification gaps can propagate into deployment, certification, and future refactoring, where unclear assumptions become durable security debt.

Practical implication: Review the security specification itself as an artefact that can introduce risk independently of code.

Threat narrative

Attacker objective: An attacker would seek to exploit weak transport protection or authentication ambiguity to undermine trust in the secret-handling workflow.

1. Entry occurs through insecure deployment choices when transport-layer requirements are not enforced clearly enough in the specification.
2. Credential or authentication handling is then exposed to protocol ambiguity, especially where nonce behaviour is described loosely.
3. Impact is a larger implementation risk surface, because teams may ship inconsistent security controls even when the underlying software is otherwise sound.

Breaches seen in the wild

• SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Specification ambiguity is itself a security control failure: when cryptographic requirements are not written tightly enough, implementation teams inherit risk through interpretation rather than code. Passbolt’s audit summary shows that the most serious issues were omissions in the specification, not confirmed runtime exploitation. For identity and secret-handling systems, that means governance has to include the written protocol model, not just the deployed stack.

Nonce correctness is a trust property, not a formatting detail: challenge values in authentication protocols must do more than look random. If the protocol says 'nonce' but the implementation relies on values that may not be used exactly once, the security assumption weakens at the design layer. That is a classic example of how authentication assurance depends on precise protocol semantics.

Transport security must be explicit in the system contract: leaving HTTPS enforcement or cipher guidance to hosting discretion creates a split between intended and actual security posture. In a secret-management context, that split matters because transport is part of credential protection, not an adjacent hardening choice. Practitioners should read unclear transport guidance as a governance gap, not a minor documentation issue.

Audit findings of this kind validate the need for specification-led assurance: security certification, code review, and implementation testing all depend on a stable statement of what the system must guarantee. The article indicates that Passbolt planned to refine its specification and whitepaper material, which is the right response class for this problem space. The practitioner lesson is to treat unclear protocol requirements as security debt with lifecycle consequences.

Clear cryptographic specifications are a prerequisite for mature secrets governance: the most durable control is often the one that prevents ambiguous implementation choices before they happen. Where the protocol contract is incomplete, governance must compensate through stricter review, clearer deployment baselines, and stronger assurance boundaries.

What this signals

Cryptographic governance starts with the specification: if a protocol contract leaves transport security or nonce semantics open to interpretation, downstream implementation will absorb that ambiguity. That is why mature IAM and secrets programmes need design review, not just code review, before rollout.

In Passbolt’s case, the highest-severity issues were framed as omitted information in the specification rather than proven exploitation. That pattern is common in identity-adjacent systems, where trust assumptions are often embedded in the architecture and only later tested by deployers.

For practitioners, the real signal is that assurance work has to cover written behaviour, deployment defaults, and authentication semantics together. A clear implementation can still sit on top of an unclear security model, and that is where governance breaks down.

For practitioners

• Tighten protocol requirements in the security specification Write mandatory transport, nonce, and authentication behaviour into the formal specification so implementation teams do not infer security properties from prose or defaults.
• Enforce HTTPS and cipher baseline rules at deployment Make TLS requirements explicit in installation guidance, health checks, and server administration runbooks so insecure transport cannot remain an acceptable operating mode.
• Review authentication assumptions for nonce single-use semantics Check whether challenge-response flows depend on values that are merely random rather than provably single-use, then align the protocol text with the intended security property.
• Treat specification gaps as audit findings in their own right Track missing or undefined cryptographic requirements as governance debt, because unclear design language can survive code review and surface later in implementation.

Key takeaways

• The article’s core risk is specification ambiguity, not a demonstrated compromise of the product.
• The audit summary reports seven findings and seven informational findings, with the highest-severity issues tied to transport-layer encryption guidance and nonce handling.
• Teams should treat cryptographic specifications as enforceable governance artefacts, because unclear protocol language can become implementation risk.

Key terms

• Nonce: A nonce is a value used once to keep encrypted messages unique and prevent reuse or replay. In secure channel implementations, nonce handling is a state-management problem as much as a cryptographic one, because incorrect sequencing can break channel continuity or validation.
• Cryptographic Specification: A cryptographic specification is the written definition of how a security protocol must behave, including message flow, trust assumptions, and failure handling. It is the control plane for implementation quality, because unclear requirements can produce insecure but technically compliant software.
• Transport security: Transport security protects data while it moves between systems, usually with TLS or mTLS. It is not just encryption in transit. It also depends on correct endpoint verification, secure protocol negotiation, and consistent enforcement across web, mobile, API, and service-to-service traffic.
• Challenge-response Authentication: Challenge-response authentication proves identity by requiring the caller to respond to a server-issued challenge rather than sending reusable credentials directly. In API and machine identity contexts, it reduces replay risk, but only when the challenge, signing key, and response verification are all tightly controlled.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.