DEV Community: Passwork Team

Post-quantum password security: What changes and what to do

Passwork Team — Fri, 25 Sep 2026 13:14:16 +0000

Quantum computers will not brute-force a properly hashed 16-character password anytime soon. Grover's algorithm only halves the exponent of a hash search, not the whole problem. What a large enough quantum computer does break is the RSA and elliptic-curve key exchange that carries that password to your server, and NIST has already put a 2030 deadline on replacing it.

Two separate problems get collapsed into one headline: "quantum computers will break your passwords." This guide keeps them apart, then hands IT and security teams a workflow for checking which one actually applies to their own password estate, and which parts of that estate can wait.

Key takeaways

Shor's algorithm breaks RSA and elliptic-curve key exchange. Grover's algorithm only halves the effective strength of a password hash, from roughly 128-bit to 64-bit.
NIST finalized FIPS 203, 204, and 205 in August 2024 and set a 2030 deprecation, 2035 disallowance timeline for RSA, ECDSA, and EdDSA in NIST IR 8547.
Harvest-now-decrypt-later is already active. 61% of security professionals name it their top quantum concern, according to Thales's 2026 report.
The 3-Layer Quantum Exposure Audit sorts a password estate into hashes, key exchange, and long-lived encrypted data. Each layer gets its own verdict.
AES-256 stays quantum-resistant at current key sizes. RSA-2048 is the component every vendor, including password managers, needs a migration plan for.

The two quantum algorithms that matter (Shor vs Grover)

Two quantum algorithms matter for password security, and they do different jobs. Shor's algorithm delivers an exponential speedup against the math behind RSA and elliptic-curve cryptography, which breaks key exchange once a large enough quantum computer exists. Grover's algorithm delivers only a quadratic speedup against symmetric search, cutting effective strength in half rather than to zero.

Algorithm	Speedup	Target	Practical effect
Shor's algorithm	Exponential	RSA, elliptic-curve cryptography (ECC), Diffie-Hellman	Breaks key exchange and digital signatures once a large error-corrected quantum computer exists
Grover's algorithm	Quadratic (square root)	Symmetric search: password hashes, AES keys	Halves effective bit strength (128-bit becomes roughly 64-bit); the algorithm itself stays intact

The gap between exponential and quadratic is the whole story. A quadratic speedup against a 128-bit hash still leaves roughly 2⁶⁴ operations to try, which is computationally enormous today, and a memory-hard function like Argon2id multiplies that cost further. An exponential speedup against RSA-2048 doesn't leave a comparable margin.

For the deeper mechanics of lattice-based and other post-quantum schemes, see our explainer on what is quantum cryptography; this guide stays focused on what changes for password infrastructure specifically.

What is Shor's Algorithm?

  <path d="M12 5V19M5 12H19" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path>
</svg>

Shor's Algorithm — a quantum algorithm developed by Peter Shor in 1994 that efficiently factors large integers into their prime factors in polynomial time. On a quantum computer, it can factor an n-bit number in approximately O(n³) operations, compared to the best known classical algorithms which require exponential time. This algorithm is significant because it can break RSA encryption, which relies on the difficulty of factoring large numbers. For example, while a classical computer might take thousands of years to factor a 2048-bit number, Shor's algorithm on a sufficiently powerful quantum computer could do it in hours.

What is Grover's Algorithm?

  <path d="M12 5V19M5 12H19" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path>
</svg>

Grover's Algorithm — a quantum algorithm developed by Lov Grover in 1996 that searches an unsorted database of N items in O(√N) time, providing a quadratic speedup over classical search which requires O(N) time. The algorithm uses quantum superposition and amplitude amplification to identify a marked element among many unmarked ones. For example, to find a specific item among 1 million items, Grover's algorithm would need approximately 1,000 queries instead of 500,000 on average. While less dramatic than Shor's algorithm, Grover's speedup applies to a broader range of problems including database searching, optimization, and cryptanalysis.

Why your password hash is not the real target

A properly hashed password stays expensive to crack even under Grover's algorithm, because the hashing function's cost applies to every single guess a quantum computer makes. Argon2id and bcrypt are memory-hard by design, so halving the exponent still leaves an attacker paying a steep price per attempt.

Take a 16-character random password drawn from the full 95-character printable set: roughly 105 bits of entropy before hashing touches it. Grover's quadratic speedup roughly halves that exponent, landing an attacker around 2⁵² effective operations. That number stays out of reach for any quantum computer under serious discussion today, and Argon2id's memory-hard cost multiplies the price of each guess on top of it.

Not every hashing function offers that protection equally. PBKDF2 is CPU-bound and cheaper to parallelize on custom hardware. Argon2id and bcrypt force an attacker to pay in memory as well as time, which matters more as GPU and ASIC cracking improves, quantum or not. Salting stays mandatory regardless of algorithm: it stops precomputed rainbow-table attacks and forces every guess to run individually against a single hash.

Our guide to password hashing and salting covers the mechanics of each function in more depth, including why a 16-character minimum has become the practical floor.

What is Argon2id?

  <path d="M12 5V19M5 12H19" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path>
</svg>

Argon2id — a modern password hashing algorithm that won the Password Hashing Competition in 2015. It is designed to be resistant to both GPU and ASIC attacks by requiring significant amounts of memory and computational time. Argon2id combines two variants: Argon2i (resistant to side-channel attacks) and Argon2d (faster but potentially vulnerable to side-channels). It uses configurable parameters for time cost, memory cost, and parallelism, making it highly resistant to brute-force attacks. For example, with recommended settings, hashing a password might take 1-2 seconds and require 64MB of memory, making it impractical for attackers to crack passwords at scale.

What is PBKDF2?

  <path d="M12 5V19M5 12H19" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path>
</svg>

PBKDF2 (Password-Based Key Derivation Function 2) — a key derivation function standardized by NIST that applies a pseudorandom function (like HMAC-SHA256) repeatedly to a password and salt to produce a derived key. It is designed to slow down password hashing by using a configurable iteration count, making brute-force attacks more computationally expensive. PBKDF2 has been widely adopted for password hashing and key derivation in various applications. However, it has limitations compared to modern algorithms like Argon2id because it does not require significant memory, making it vulnerable to GPU and ASIC-based attacks. For example, PBKDF2 with 100,000 iterations is still considered acceptable but less secure than memory-hard alternatives.

What is bcrypt?

  <path d="M12 5V19M5 12H19" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path>
</svg>

bcrypt — a password hashing algorithm based on the Blowfish cipher, designed by Niels Provos and David Mazières in 1999. It incorporates a salt and a configurable cost factor (work factor) to slow down the hashing process, making it resistant to brute-force attacks. The cost factor can be increased over time as computing power grows, allowing bcrypt to remain secure for years. bcrypt automatically generates and stores the salt within the hash output, simplifying implementation. For example, bcrypt with a cost factor of 12 takes approximately 250 milliseconds to hash a password on modern hardware. While bcrypt is still widely used and considered secure, it does not require memory like Argon2id, making it somewhat vulnerable to specialized hardware attacks.

The layer that actually breaks: Key exchange

RSA-2048 and ECDH key exchange are the actual target here. Shor's algorithm makes factoring the math behind RSA and computing the discrete logs behind ECC tractable, which breaks TLS handshakes, SSH sessions, VPN tunnels, and any private-key wrap built on the same primitives.

Public-key cryptography carries that risk into everyday infrastructure in more places than most teams track:

TLS 1.3 handshakes: RSA or ECDHE key exchange, ECDSA certificates
SSH host and user key exchange
VPN tunnel negotiation
Private-key wrapping inside a password manager's key hierarchy
Code-signing and document-signing certificates

The math behind that risk isn't hypothetical. Google Quantum AI published a May 2025 preprint showing that 2048-bit RSA could theoretically be factored by a sufficiently large error-corrected quantum computer. The machine doesn't exist yet. The mathematics that would break it does.

A password manager sits inside this same list. Sharing a vault with a new team member, syncing a record between devices, or unwrapping a private key at login all depend on an asymmetric operation somewhere in the chain. Auditing your password manager's crypto stack belongs in the same inventory as your TLS endpoints and VPN concentrators.

Harvest now, decrypt later: The threat that exists today

Harvest now, decrypt later describes an attacker recording encrypted traffic today and decrypting it once a capable quantum computer exists. It reframes "quantum is ten years away" into "the collection already started," which matters for any data whose confidentiality needs to survive a decade or more.

Thales's 2026 Quantum & AI Threat Report surveyed 3,120 security and IT professionals across 20 countries and found harvest-now-decrypt-later is their top quantum concern, cited by 61% of respondents, ahead of algorithm deprecation or compliance deadlines. Adversaries with the patience to wait years for a payoff, typically nation-state actors, are the ones running this collection today.

The exposure concentrates in data that needs to stay confidential for years: medical records, legal filings, intellectual property, government communications. A TLS session key discarded the moment a connection closes is a poor target. An RSA-wrapped archive from 2024 still sitting on a backup tape in 2034 is exactly what this threat targets, and so is an encrypted vault export sitting in a decommissioned backup that nobody remembered to purge.

What NIST actually decided, and the deadlines that bind you

NIST finalized its first three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM) for key exchange, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. NIST IR 8547 then set the compliance clock, deprecating RSA, ECDSA, and EdDSA after 2030 and disallowing them after 2035.

Date	Milestone
2016	NIST opens its post-quantum cryptography standardization process
August 2024	FIPS 203, 204, and 205 finalized: ML-KEM, ML-DSA, SLH-DSA
November 2024	NIST IR 8547 published, setting the deprecation and disallowance timeline
After 2030	RSA, ECDSA, and EdDSA deprecated
After 2035	RSA, ECDSA, and EdDSA disallowed

Symmetric cryptography at 128-bit security or higher is unaffected by any of this. AES-256 needs no algorithm change. The deadlines target the asymmetric layer specifically: RSA, ECDSA, and EdDSA, replaced by ML-KEM and ML-DSA. The Commercial National Security Algorithm Suite 2.0 mirrors this timeline for U.S. national security systems, one signal of how seriously procurement teams are meant to take it.

NIST IR 8547 frames post-quantum migration as a multi-year engineering effort, on the order of a decade to integrate across products and infrastructure, which is the real argument for starting an inventory now rather than waiting until 2029. IBM's public quantum roadmap targets a system of 100,000-plus qubits by 2033. That's the vendor's own stated goal, not an independent projection, but it puts a rough date on when "large enough" stops being theoretical.

Building crypto agility into procurement now, meaning the ability to swap an algorithm without rearchitecting a product, is what turns this from a scramble into a scheduled migration.

The 3-Layer Quantum Exposure Audit

Running this audit takes an afternoon, not a consulting engagement. Sort your password estate into three layers, and each one gets its own verdict: safe, watch, or act now.

Layer	What it is	Quantum status	Verdict
1. Password hashes	Argon2id, bcrypt, or PBKDF2 protecting stored credentials	Grover halves effective strength; memory-hard functions stay expensive per guess	Safe. Recheck the algorithm and iteration count, but this isn't urgent
2. Key exchange and transport	RSA, ECDH, ECDSA in TLS, SSH, VPN, and private-key wraps	Shor breaks the underlying math once a capable quantum computer exists	Act now. Inventory it and plan a migration to ML-KEM and ML-DSA
3. Long-lived encrypted data at rest	Archives, backups, and records whose confidentiality must outlast a decade	Exposed today via harvest-now-decrypt-later if protected only by an asymmetric key exchange	Watch. Prioritize by data sensitivity and retention period

Layer 1 is the one teams worry about most and need to worry about least. If your login and password-manager master-password hashes already use Argon2id, PBKDF2 or bcrypt with a reasonable work factor, Grover's algorithm doesn't change your risk calculus. The one real gap worth chasing: a legacy system still running MD5 or unsalted SHA-1 was already broken before quantum entered the conversation.

Layer 2 is where an admin usually finds the actual gap: a VPN concentrator still pinned to RSA-2048, an internal PKI issuing ECDSA certificates with no renewal plan, a legacy API that never moved past TLS 1.2. Inventory every place RSA, ECDH, or ECDSA performs a key exchange, and start with whatever protects your longest-lived traffic.

Layer 3 is about what's already been collected, not what gets encrypted tomorrow. Ask what data your organization protects today that still needs confidentiality in 2035: legal holds, cap tables, source code, anything under a multi-year NDA. Then check whether that confidentiality depends on an asymmetric key exchange performed years ago.

Run the audit once, then fold it into whatever cadence your team already uses for a crypto inventory. Annually is reasonable. Faster if you're issuing new PKI or renegotiating a VPN contract this year.

How to read a password manager's crypto documentation

A password manager's crypto documentation should name exactly what protects your vault at each layer. A vague "military-grade encryption" claim doesn't count. Look for named algorithms, stated key sizes, a named key-derivation function, and a public position on post-quantum migration.

What a quantum-aware vendor publishes:

The exact symmetric cipher and key size protecting vault data (AES-128 and AES-256 are not the same margin, so "AES" alone isn't enough)
The exact asymmetric algorithm used for key exchange and private-key wrapping
The key derivation function and iteration count turning a master password into an encryption key
Whether encryption happens client-side, the zero-knowledge model, or only at rest on the server

Passwork's own documentation is a reasonable example of what that transparency looks like in practice. Its client-side encryption applies AES-256 to vault and record data, with a separate AES-256 layer protecting the database at rest. A master password derives a 512-bit master key through PBKDF2 (HMAC-SHA-256), which unwraps an RSA-2048 private key that in turn unwraps per-vault and per-record keys, a hierarchy documented in the cryptography overview.

Run that stack through the 3-Layer Audit and the honest answer is straightforward. The AES-256 data layer stays quantum-resistant at current key sizes; the RSA-2048 key-exchange layer is the component to watch as post-quantum standards mature across the industry. That's the same answer any vendor wrapping keys with RSA should be giving you today: a documented AES-256 layer that doesn't need to change, and an asymmetric layer with an acknowledged migration path, not a claim that everything is already quantum-proof. Our AES-256 explainer covers why the key size margin matters on its own.

What to do today (and what can wait)

Start with what protects TLS, SSH, and VPN key exchange today, since that's the layer with an actual 2030 deadline. Passkey rollout, hybrid key exchange testing, and a documented crypto inventory can run in parallel. Re-keying AES-256 deployments or worrying about password hash strength can wait.

Do now:

Inventory every place RSA, ECDH, or ECDSA performs key exchange: TLS endpoints, SSH hosts, VPN concentrators, internal PKI.
Confirm your password manager and identity provider publish their actual crypto stack instead of a vague "bank-level encryption" claim. If a vendor won't name its algorithms and key sizes on request, treat that as the answer.
Turn on MFA everywhere it isn't already mandatory. It doesn't touch the quantum question directly, but it closes exposure while migration runs.

Plan this year:

Get hybrid key exchange (classical plus ML-KEM) onto your vendor roadmap conversations, especially for anything facing a 2030 deadline.
Prioritize passkey rollout for user-facing authentication. FIDO2's algorithm agility means the migration path already exists, even though today's passkeys still use ECDSA, and rollout itself reduces how much of your estate still depends on a password hash at all.
Close out any lingering TLS 1.2 endpoints. Update TLS 1.3 is a prerequisite for post-quantum key exchange, not a separate project.

Watch:

IBM's and Google's quantum hardware roadmaps. A jump past the milestones in the NIST timeline above would move deadlines up rather than simply confirm them.
NIST guidance on hybrid and pure post-quantum modes as FIPS 203, 204, and 205 implementations mature in mainstream TLS and SSH libraries.

None of this requires replacing an existing password manager. If it already publishes an AES-256/RSA-2048 stack like the one above, the platform is doing its part; the inventory work above is yours.

Conclusion

Quantum computers are not coming for your password hash. They're coming for the RSA and ECC key exchange that carries it, and NIST has already put dates on the calendar: 2030 to deprecate, 2035 to disallow. The 3-Layer Quantum Exposure Audit turns that abstract risk into three concrete checks a team can run this quarter, one of which is probably closeable this afternoon.

Start with Layer 2. Pull the list of everywhere RSA, ECDH, or ECDSA handles a handshake in your environment, and you'll know within a day which vendors need a migration conversation and which ones already have one started.

What is segregation of duties (SoD)? Definition and examples

Passwork Team — Thu, 17 Sep 2026 14:47:09 +0000

A single employee who can create a vendor record and then approve that vendor's invoice doesn't need anyone else's help to push an improper payment through. No collusion is required, and nothing has to be forged: one login with too much reach is enough on its own. Segregation of duties (SoD) is the control that closes that gap. It splits a sensitive process into steps that different people must complete, so no one person can execute a transaction from start to finish unchecked.

The principle sits underneath most internal-control frameworks in finance, IT, and security operations. Auditors ask about it by name. Regulators cite it in specific clauses. And the cost of skipping it keeps climbing: the median case of occupational fraud cost $104,000 in 2026, and the average case ran for about 12 months before anyone caught it, according to the ACFE's Occupational Fraud 2026: A Report to the Nations.

What is segregation of duties (SoD)?

Segregation of duties (SoD) is an internal control that divides a sensitive process into stages, typically authorization, custody or execution, and recordkeeping or reconciliation, and assigns each stage to a different person. No single individual initiates and approves the same transaction, or handles an asset and records its own movement. The goal is to make fraud or error require collusion instead of opportunity.

SoD is not the same as an org chart. A reporting line shows who manages whom, but it says nothing about who can create a vendor, approve its payment, and reconcile the ledger without a second person ever reviewing the transaction. Two people can report to the same manager and still satisfy SoD, as long as neither can complete the full process alone. The four-eyes principle, requiring at least two people to sign off on a sensitive action, is the simplest expression of the idea.

Segregation of duties vs. least privilege vs. RBAC

SoD is not least privilege, and least privilege is not RBAC. Least privilege limits how much access one person has. SoD limits whether one person can complete an entire sensitive process alone, even within their allowed access. RBAC (role-based access control) is the mechanism that usually enforces both, by attaching permissions to roles instead of individuals.

The three ideas fail differently when applied alone. Least privilege without SoD still lets one narrowly scoped account both create and approve the same type of record, because narrow doesn't mean isolated. RBAC without SoD can quietly hand one person two roles that were never meant to overlap, like an accounts-payable clerk covering for an approver during a vacation week. The role definitions look clean, the combination defeats the control.

None of this makes RBAC unnecessary. It's the tool that makes SoD enforceable at scale. See how RBAC assigns access by role for the underlying model: instead of tracking individual permissions, an administrator defines roles, and SoD rules decide which roles a single account can hold at once.

Principle	What it controls	Fails without it
Least privilege	How much access one account has	Accounts accumulate unused, high-risk permissions over time
RBAC	How access maps to job function	Permissions get assigned ad hoc, inconsistently, per person
Segregation of duties	Whether one account can finish a sensitive process alone	A single compromised or careless account can complete fraud or cause damage with no second party involved

Common segregation of duties conflicts (with examples)

A segregation of duties conflict exists whenever one account or one person holds two roles that, combined, let them complete a sensitive process without a second party involved. The clearest examples sit in finance and procurement, but the same failure pattern shows up in DevOps pipelines, HR systems, and credential vaults.

Formalized SoD requirements trace back to the accounting scandals at Enron and WorldCom in the early 2000s, which led directly to the Sarbanes-Oxley Act and its Section 404 internal-controls mandate. That history still shapes how auditors approach the control today: SoD exists because informal trust stops scaling once a company passes a certain size.

When one person can both create a vendor and approve its payment, fraud requires no collusion at all.

Domain	Conflicting duties	What it enables if combined
Finance	Create a vendor + approve its invoice	Fictitious vendor payments with no second reviewer
Procurement	Request a purchase + approve the purchase order	Unauthorized spending routed around budget controls
IT / DevOps	Deploy code + approve the deployment	Unreviewed code reaches production, including backdoors
HR	Set an employee's pay rate + process payroll	Unauthorized pay changes that no one else verifies
Credential management	Create a vault + grant its own admin rights	One account that stores secrets and controls who can see them, with no independent oversight
IT administration	Provision user accounts + approve access requests	Accounts created and approved by the same person, bypassing review

If one row in that table describes how your vault works today, that gap is fixable. Try Passwork free and see how vault policies close it.

How to build a segregation of duties matrix

A segregation of duties matrix maps roles against the actions those roles can take, so conflicts become visible before they cause a problem. Building one takes five steps.

Identify the critical processes. Start with anything that moves money, changes access, or touches production: vendor payments, payroll changes, code deployment, credential and vault administration.
List every role involved. Include job-title roles (accounts-payable clerk, DevOps engineer) and system roles (vault administrator, approver) side by side.
Map roles against actions. Build a grid with roles on one axis and actions, such as create, approve, execute, and record, on the other. Mark every action each role can currently perform.
Flag the overlaps. Any role that can both initiate and approve the same process, or both execute and record it, is a conflict.
Resolve each conflict. Reassign the role, split the process across two roles, or, where reassignment isn't practical, document a compensating control.

A small worked example, three roles against three actions in an accounts-payable process:

Role	Create vendor	Approve payment	Reconcile ledger
AP clerk	Yes	No	No
Finance manager	No	Yes	No
Auditor	No	No	Yes

No single row can check every column. That's the matrix working as intended.

Preventive vs. detective SoD controls (and compensating controls for lean teams)

Preventive SoD controls stop a conflicting assignment before it happens, usually by blocking a role combination in the access system itself. Detective controls catch conflicts after the fact, through audit trails and periodic access review. Compensating controls substitute for either when a team is too small to fully separate a process.

Preventive controls are the strongest, because they remove the opportunity entirely. A role system that refuses to let one account hold both "approver" and "requester" for the same workflow never lets the conflict form in the first place.

Detective controls accept that some overlap is unavoidable and catch it instead. An audit trail that logs who created a record, who approved it, and who accessed it afterward lets a reviewer spot a conflict during an access certification, even if the system allowed it to happen.

Most SoD guidance assumes a dedicated identity governance and administration (IGA) or GRC platform running continuous conflict checks. Small IT teams rarely have that budget, and most guidance skips what to do instead.

Four compensating controls cover most of the gap. Call it the four-control SoD baseline:

Separate roles wherever headcount allows
Route anything that can't be separated through a second approver
Log every privileged action to an exportable audit trail
Review access on a fixed schedule instead of never

None of the four requires a GRC platform. All four require someone to own the schedule.

Segregation of duties and compliance frameworks

Segregation of duties shows up by name or by requirement in most major compliance frameworks, though the legal weight varies by sector and jurisdiction. SOX ties it to financial reporting controls, NIST and ISO frame it as a general security control, and NIS2 folds it into access control policy requirements for essential and important entities in the EU.

None of these frameworks hand over a ready-made SoD matrix. They require that the organization has one and can show how conflicts get resolved.

Framework	What it requires	Citation
SOX	Documented internal controls over financial reporting, including access controls that keep one person from completing certain transactions alone	SOX Section 404, SEC small-business guide
NIST SP 800-53 Rev. 5	Organizations define and document individual duties, then configure system access so no combination of duties lets one account complete a sensitive process alone	NIST AC-5, control AC-5
ISO/IEC 27001:2022	Segregation of duties as a named control area, covering how conflicting duties and responsibilities are separated	ISO/IEC 27001:2022, Annex A control 5.3
NIS2 Directive	Essential and important entities implement measures covering human resources security, access control policies, and asset management	NIS2 Directive, Article 21, Art. 21(2)(i)

SOX's Section 404 mandate is the one most compliance-driven SoD programs cite by reflex, though it applies specifically to public companies' financial reporting controls, not to every framework in this table. Whether SoD is legally required for a given organization depends on sector, jurisdiction, and which frameworks apply. A compliance or legal team is the right source for that determination. This table is a map, not a legal opinion.

Segregation of duties checklist

Use this checklist to move from an ad hoc access setup to a documented segregation of duties program, with or without a dedicated GRC platform.

Map every critical process that moves money, changes access, or touches production.
Build a segregation of duties matrix and flag every role that can both initiate and approve the same action.
Assign non-removable administrators per vault or policy type, so oversight doesn't depend on who created the resource.
Enable AD/LDAP group sync so access changes follow directory updates instead of manual tickets.
Turn on exportable audit logging for every privileged action.
Schedule periodic access review, more often for high-risk roles than for standard ones.
Document compensating controls wherever strict separation isn't feasible, and record who owns each one.

Monthly cybersecurity news: Authentication under siege

Passwork Team — Wed, 02 Sep 2026 23:43:31 +0000

August's cybersecurity news had a common thread: attackers found ways around the login itself instead of attacking it directly. Authentication bypasses, forged tokens, stolen sessions, exposed API keys, and leaked machine credentials repeatedly provided access without requiring attackers to crack a password or defeat MFA.

More than 9,300 active AWS access keys were found in public repositories, build logs, and container images. Among the corporate keys were 526 root keys and 242 IAM keys with full AdministratorAccess permissions.
The March LiteLLM supply-chain incident may have exposed more than 2,500 organizations and 434,000 CI/CD pipelines, according to an impact assessment published in August.
Researchers found 4,576 n8n API tokens in public GitHub repositories; among reachable instances tested, 36% accepted at least one leaked key.
Mirage2FA targeted 9,426 Microsoft 365 email addresses and compromised up to 4,532 of them by stealing authenticated sessions after MFA.

The same pattern showed up in four disclosed vulnerabilities : N-able N-central, Citrix NetScaler, Keycloak, and SharePoint all disclosed flaws capable of bypassing authentication or identity controls. Separately, password-spraying activity rose 155-fold as attackers probed for gaps in MFA enforcement.

The incidents below show how authentication is expanding beyond passwords and login screens — and where IT and security teams need to adjust their controls.

Active exploitation of a critical authentication bypass in N-able N-central remote management platform (CVE-2026-18577)

What happened: The vulnerability CVE-2026-18577 (CVSS 8.1) allows a remote, unauthenticated attacker to fully bypass authentication and gain administrative access to N-central servers. The flaw stems from an incomplete fix for a previous vulnerability, CVE-2026-18556. Active in-the-wild exploitation has been recorded since August 1, 2026, with attackers using the legitimate Take Control feature to reach customer endpoints after compromise and deploying a cloudflared tunnel for persistent remote access.

Why it matters: Remote monitoring and management (RMM) platforms hold the highest privilege level across an organization's entire infrastructure and its connected clients. An authentication bypass in such software immediately creates a supply-chain exposure risk across the whole client base.

The defensive takeaway: IT teams must urgently check their platform version and confirm that N-able hotfix 2026.3.1.10 (2026.3.1 Hotfix 2) is installed. A review of active privileged sessions is also critical.

Source: Rapid7 – August 4, 2026

Remote, zero-interaction authentication bypass in Citrix NetScaler Gateway (CVE-2026-19490)

What happened: Citrix patched a critical alternate-path authentication vulnerability, CVE-2026-19490 (CVSS score 9.3), in NetScaler ADC and NetScaler Gateway. An unauthenticated remote attacker can exploit the flaw on affected gateway configurations (including SSL VPN, ICA Proxy, CVPN, RDP Proxy, and AAA) without any user interaction. Preconditions vary by version: newer affected builds require a SAML configuration in addition to a Gateway or AAA setup, so not every NetScaler deployment is exposed the same way.

Why it matters: Remote access gateways serve as the primary perimeter defense for corporate networks. A successful authentication bypass at this layer completely negates the value of employee corporate credentials and MFA policies.

The defensive takeaway: Because these appliances are directly exposed to the internet, IT teams should perform an emergency update to the patched builds provided by Citrix (14.1-73.32 or 13.1-63.21 and later).

Source: SecurityWeek – August 20, 2026

Perimeter credentials alone can't be the last line of defense against flaws like this one. Passwork adds a centrally managed, audited layer for the credentials and secrets behind your gateways and RMM tools. See how Passwork's access control works.

Critical Keycloak password-reset vulnerability (CVE-2026-18963) leading to remote account takeover

What happened: A critical vulnerability, CVE-2026-18963 (CVSS score 9.1 per Red Hat), was found in Keycloak's password recovery (reset-credentials) flow. Due to improper state validation, a remote, unauthenticated attacker can reset any user's password, including administrators'. Fixes have been released in Keycloak 26.7.2, as well as Red Hat build of Keycloak 26.4.15 and 26.6.6.

Why it matters: Validation flaws in account-recovery flows undermine any strict password-complexity requirements or initial MFA, giving attackers a direct path to compromising the identity provider (IdP).

The defensive takeaway: IT teams should prioritize patching Keycloak servers and test password-reset and account-recovery flows with the same rigor applied to primary authentication methods.

Source: The Hacker News – August 24, 2026

Critical remote code execution vulnerability CVE-2026-69836 (CVSS 10.0) fixed in Microsoft Entra ID's cloud directory

What happened: Microsoft fixed a critical remote code execution vulnerability, CVE-2026-69836, in Entra ID's cloud service, related to deserialization of untrusted data. Unlike the other flaws in this digest, this is a remote code execution issue in cloud infrastructure, not a credential or authentication bypass. Microsoft resolved the issue server-side, requiring no action from customers. The flaw was initially flagged as exploited in real-world attacks, but Microsoft later revised the status to "not exploited."

Why it matters: Entra ID is the central hub for access control and authorization for thousands of companies. Maximum-severity vulnerabilities in identity providers' cloud infrastructure create global risks across the entire trusted ecosystem.

The defensive takeaway: Despite the automatic patch applied by the provider, security teams should monitor for anomalies in cloud identity logs and revisit risk assumptions about access during incidents affecting key service providers.

Source: SecurityWeek / heise online – August 21-24, 2026

Mass exposure of active AWS keys threatens full takeover of corporate accounts

What happened: Research by Truffle Security identified more than 9,300 AWS access keys leaked into public repositories, build logs, and container images, keys that remained valid and active for years. Of these, 817 belonged to companies, including 526 root keys and 242 IAM keys with full AdministratorAccess permissions, granting complete control over cloud infrastructure.

Why it matters: Leaked long-lived access keys, especially those with administrator rights, give attackers unimpeded access to cloud resources, bypassing standard authorization portals and MFA entirely.

The defensive takeaway: IT teams must prohibit the use of AWS root accounts in routine processes, set up continuous scanning of public sources for exposed secrets, and immediately revoke and rotate any compromised keys, following AWS's own root user best practices.

Source: Truffle Security – August 19, 2026

CloudSEK report maps potential exposure from the March LiteLLM supply-chain incident

What happened: On August 11, CloudSEK published an impact assessment of the March 24 compromise involving malicious LiteLLM releases 1.82.7 and 1.82.8. The report estimates that the short-lived PyPI exposure (the packages were publicly available for roughly 40 minutes) may have affected more than 2,500 organizations and over 434,000 CI/CD pipelines worldwide.

The assessment focuses on the potential exposure of high-value machine credentials available to affected development and build environments. CloudSEK’s figures describe reconstructed exposure risk, not confirmed compromise of every named organization or pipeline.

Why it matters: AI development and build automation environments now hold the highest concentration of non-human (machine) secrets in an organization. Compromising tooling at the build stage lets attackers strike deep inside the infrastructure, and the delay between the original incident and a full exposure estimate shows how long that risk can go unquantified.

The defensive takeaway: Machine credentials require strict lifecycle control, rotation, and access-rights auditing. IT teams need to implement security monitoring for third-party libraries and protect environment variables in CI/CD pipelines. Passwork's technical guides cover API-based secret rotation patterns that fit directly into this kind of pipeline hardening.

Source: CloudSEK – August 11, 2026

Vulnerability in the N-able Passportal browser extension exposes users' password vault master keys

What happened: The Passportal browser extension accepted messages from third-party websites and iframe elements. Attackers could send a request and obtain extension access tokens containing secret keys. This allowed extraction of the entire contents of the password vault, including seeds for generating one-time TOTP codes. N-able released a patch adding origin-checking for requests in July 2026; Dark Reading's August coverage detailed the flaw and its impact.

Why it matters: Password managers concentrate an organization's most critical secrets. Compromising a password manager's browser extension effectively bypasses the entire security architecture, MFA factors included. The risk was compounded by refresh tokens remaining valid for 100 days.

The defensive takeaway: Organizations need to enforce regular automatic updates of browser extensions on employee devices, and when selecting IAM solutions, evaluate whether they support end-to-end encryption of client-side operations.

Source: Dark Reading – August 20, 2026

A browser extension is only as trustworthy as its architecture. Passwork uses client-side AES-256 encryption with a zero-knowledge model, so vault data stays encrypted even in transit through the browser layer. Explore Passwork's security architecture.

Mirage2FA phishing campaign bypasses Microsoft 365 multi-factor authentication through session theft

What happened: The Mirage2FA platform uses adversary-in-the-middle (AiTM) phishing to intercept legitimate Microsoft 365 session authorization tokens. The campaign compromised up to 4,532 email addresses, roughly 48% of the 9,426 addresses targeted, across 3,518 organization domains in the US and EU.

Why it matters: Session cookies effectively become the equivalent of user credentials once initial MFA verification has passed. Session theft bypasses standard protection factors without requiring a password or code to be re-entered.

The defensive takeaway: Traditional SMS- or app-code-based MFA is no longer sufficient to protect cloud systems on its own. Organizations need to adopt phishing-resistant authentication methods, shorten session token lifetimes, and set up monitoring for anomalous session behavior.

Source: The Hacker News – August 25, 2026

JWT authentication bypass in Microsoft SharePoint (CVE-2026-55040) allows impersonation of any user

What happened: A vulnerability, CVE-2026-55040, was discovered in SharePoint Server Subscription Edition that lets a remote, unauthenticated attacker generate a forged JWT token and impersonate any user or portal administrator. Microsoft patched the flaw in July 2026. Rapid7's August technical analysis detailed the chain of defects behind it, including a disabled token signature requirement and weak validation of token elements, and confirmed active exploitation.

Why it matters: JWT validation errors let attackers fully bypass authentication without needing to steal user passwords.

The defensive takeaway: Service-to-service trust relationships and token validation must be checked and controlled by IT teams with the same rigor applied to user passwords and MFA sessions.

Source: Rapid7 blog – August 11, 2026

Exploitation of an SSRF vulnerability in MLflow (CVE-2026-64849) for covert credential exfiltration from cloud environments

What happened: A server-side request forgery (SSRF) vulnerability with a CVSS score of 9.3, CVE-2026-64849, was found in the model registry of the MLflow Tracking Server. It lets an unauthenticated attacker bypass webhook safeguards and reach internal cloud metadata services to exfiltrate short-lived credentials. The issue affects all MLflow versions prior to 3.15.0.

Why it matters: Cloud metadata services often issue short-lived access keys that, once compromised, can be used by attackers for rapid lateral movement inside a company's cloud environment.

The defensive takeaway: Teams running machine learning platforms need to patch MLflow to version 3.15.0 and restrict network access to metadata services from containers and AI tooling, following the pattern in AWS's IMDSv2 configuration guidance.

Source: SecurityWeek – August 20, 2026

Thousands of leaked n8n API tokens found in GitHub repositories, threatening compromise of connected IT services

What happened: Researchers found 4,576 unique n8n API tokens in public GitHub repositories, linked to 1,255 hosts. Testing against accessible instances found that 36% of them (321 of 896 reachable hosts) accepted at least one leaked key. With a privileged token, attackers could view automation workflow structures, execution logs, and extract credentials stored in n8n for third-party database and service integrations.

Why it matters: Automation and integration platforms act as hubs where passwords, API keys, and access rights to numerous corporate IT systems accumulate. A single leaked API token to such a hub creates massive risk of cascading compromise across the entire IT infrastructure, even though the exposure itself is not tracked as a CVE.

The defensive takeaway: IT departments need to extend secret-scanning policies beyond core application code, covering configuration files of automation and integration tools as well.

Source: The Hacker News – August 5, 2026

155-fold surge in password-spraying attacks exploiting MFA misconfigurations and exceptions

What happened: Analysts recorded a 155-fold increase in the scale of password-spraying attacks in the first half of 2026. Analysis of 23 affected companies found that 8 of them had no multi-factor authentication (MFA) at all. In the remaining 15 cases, MFA was enabled but failed to work, because IT departments had configured exceptions for "trusted locations," limited policy enforcement to a subset of applications or user groups, or left MFA running in report-only (audit) mode.

Why it matters: Deploying MFA does not guarantee protection if blind spots remain in security policies. Attackers actively search for loopholes and applications left unprotected by MFA to gain initial network access.

The defensive takeaway: IT teams need to eliminate "trusted IP address" exceptions, implement comprehensive MFA coverage across all external entry points, and regularly audit how security policies are actually enforced.

Source: BleepingComputer – August 19, 2026

Unverified claims by hacker "TheHatman" of mass credential theft from Microsoft Entra corporate customers

What happened: Between August 1 and 17, 2026, a hacker forum user going by "TheHatman" posted offers to sell employee data from large enterprises, allegedly obtained from Microsoft Entra cloud environments through compromised credentials. Unit 42 researchers were unable to confirm a specific entry vector or an actual breach of the Entra service itself, leaving the threat classified as an "unverified breach via account credential theft."

Why it matters: Even though the hacker's claims of breaching the provider's infrastructure remain unconfirmed, the incident drew wide attention and illustrated how attackers use compromised passwords to compromise cloud tenants. Unverified claims of this kind should be treated by IT teams as a signal to check their own systems, not as proof that the platform itself was breached.

The defensive takeaway: IT and security teams need to set up regular monitoring for leaked employee credentials and watch for signs of MFA fatigue and password-spraying attempts against cloud identity directories. Unverified threats should be used to build threat-hunting hypotheses, not to trigger panic responses.

Source: Unit 42 report – August 18, 2026

Comparative analysis of SOC response effectiveness based on CISA red team tests

What happened: The Cybersecurity and Infrastructure Security Agency (CISA) evaluated the defenses of two organizations through red team penetration testing. One organization completely missed and failed to contain the attackers' actions, while the other quickly detected initial compromise attempts and isolated the affected hosts. CISA's recommendations include maintaining baseline detection profiles, using Conditional Access policies for workload identities, and promptly rotating and revoking tokens.

Why it matters: Monitoring tools are useless without well-honed incident-response processes. Protecting cloud and hybrid environments depends directly on integrating identity and access management (IAM) systems with security team on-call playbooks.

The defensive takeaway: Privilege inventory processes, Conditional Access verification, and emergency session-token revocation need to be practiced regularly through drills and attack simulations.

Source: CISA Advisory – August 25, 2026

August 2026 recap

In August, attackers went around authentication using forged tokens, stolen sessions, leaked keys and much of this activity doesn't trip the alerts most organizations rely on. In practice, that means password policy alone no longer covers most of your attack surface: sessions, tokens, and machine credentials need the same lifecycle controls that passwords already have.

Three priorities for September:

Patch the four disclosed authentication bypasses. N-central and SharePoint had confirmed in-the-wild exploitation this review period. NetScaler and Keycloak warrant urgent patching given their severity, even without confirmed exploitation to date.
Audit authentication end to end, not just the login screen. MFA at sign-in provides limited protection if account recovery, JWT validation, session lifetimes, or Conditional Access coverage have gaps. Mirage2FA and CaptiveCrunch both bypassed MFA by stealing a session or token after authentication, not by defeating it.
Scan repositories and CI/CD pipelines for exposed keys , the way GitGuardian and Truffle Security did in August, and build revocation and rotation into routine operations rather than incident response.

How to teach children about password security: Tips for parents

Passwork Team — Mon, 31 Aug 2026 14:17:54 +0000

As the new school year begins, children start logging into more apps, school platforms, email accounts, and games on their own.

Many families only think about password security after something goes wrong. For example, a Roblox account taken over by a stranger, or a fake message pretending to come from the school asking a student to “confirm” their login.

We'd rather you start before that happens.

The Create, Protect, Recover routine below takes about ten minutes to teach and continues to work as children move from their first gaming account to managing school and email logins more independently.

Create a password and motivation to protect important things

A password protects the things your child cares about online, including schoolwork, game progress, messages, photos, and personal information. Describe it as a key to a digital room: someone who gets the key may enter the room, change what is inside, or lock its owner out.

This analogy gives children a reason to care without frightening them. Start by showing your child what each account holds.

What it protects	Why it matters
School account	It may contain assignments, messages, and personal details.
Gaming account	It may hold saved progress, purchases, and conversations.
Social account	It can contain photos, contacts, and private messages.
Email account	It may provide the reset route for other accounts.

Give the email password special attention. Email services often receive password-reset links for other accounts, so access to email may lead to access elsewhere. CEOP Education (the UK National Crime Agency's child safety programme) advises families to use a separate, strong password for email.

Ask what your child wants to keep safe in each account. Their answer might be a drawing, a message from a friend, or saved game progress. Password safety for kids makes more sense when the password protects something they value.

Teach children password security in a way that is age-appropriate

Teach children password security by matching responsibility to their age, confidence, and account type. Give every account its own long passphrase , then increase independence gradually. Keep a clear route for asking for help with forgotten passwords, suspicious messages, lost devices, and account recovery.

A passphrase is a longer password made from several words. Choose words the child can remember but other people cannot connect to them. Leave out names, birthdays, school names, addresses, pets, favourite teams, and details posted online.

Each account needs a different passphrase. If a reused password appears in a data breach, someone can try it on the child's other accounts.

NIST's 2025 consumer guidance recommends at least 15 characters when a password is required and treats length as the main priority. Use that figure as guidance for parents rather than a test the child must pass. A password manager can store long passwords that are difficult to remember.

Avoid forcing children to add symbols and numbers unless the website requires them. Substituting a number for a letter often creates an easy-to-predict pattern. Follow the website's rules while prioritising length and uniqueness.

Ages 5–8: Learn the privacy rule

Children in this age range can learn that a password stays secret from friends, classmates, other players, and strangers. A parent or guardian may help them create, enter, store, or recover it.

Keep the lesson short. Say: "This password opens your account. We keep it private, and you can always ask me for help."

Ages 9–12: Create a passphrase together

Let the child choose several unrelated words. Check that the words contain no personal facts, then explain that the finished passphrase belongs to one account.

Ask the child to explain the rule back to you. If they can describe why password reuse is risky, they have understood the reason behind the rule.

Teens: Hand over responsibility gradually

Teens can create and store their own passwords, review recovery options, and manage a second sign-in check. Agree in advance on what they should do if they lose access or respond to a suspicious message.

Respect their growing privacy while keeping a no-shame help rule. Reporting a mistake early should lead to calm action. UNICEF's online privacy checklist for parents recommends giving older children age-appropriate responsibility for their privacy and security.

Try this tonight: The five-minute passphrase check

Choose one low-risk account your child already uses.
Ask what information or activity the account protects.
Check that its password is unique and contains no personal facts.
Decide where the family will store it safely.
Practice this sentence: "Something looks wrong with my account, so I need help."

Protect the password after it is made

A good passphrase works only when the family can keep it private, store it safely, and recover the account if something goes wrong. Start with email, school, gaming, shopping, and social accounts. They may contain personal information, saved purchases, private messages, or payment details.

Use the Create, Store, Add a Second Check plan:

Create a unique password for each account. Use a long passphrase when the child needs to type or remember it. Let a password manager generate a random password when memorisation is unnecessary.
Store it securely. A password manager is a tool that creates and stores different passwords so the family does not need to remember them all. Its master password opens the password vault, so the responsible parent should create and protect it carefully.
Add a second check. Two-factor authentication (2FA) adds another check after the password. This might be an approval on a device or a code from an app. You may also see this called 2-step verification, 2SV, or MFA.

Turn on 2FA for important accounts when the service offers it. Keep recovery codes private and store them separately from the password. Anyone with a working recovery code may be able to enter the account.

A passkey lets someone approve a sign-in with a device PIN, fingerprint, or face scan instead of typing a password. If you see this option, check how the account can be recovered if the device is lost or replaced.

The UK's National Cyber Security Centre recommends passkeys where supported and 2-step verification where passkeys are unavailable. Recovery options still differ by service and the child's age.

Recognize phishing and keep the password private

Give children one exact boundary: "Never share a password with a friend, classmate, other player, or stranger." Younger children may need help from a parent or guardian. As children become more independent, agree on recovery and reporting rules instead of demanding access to every account.

A request for a password can sound friendly or urgent. Another player might offer free game items. A message that seems to come from school might claim the child's account will close unless they sign in immediately.

Phishing is a fake message or website that tries to steal a password, verification code, or personal information. Children do not need to judge every message alone. Teach them to pause and ask for help.

Pause before you sign in

Stop. Do not reply or enter a password.
Do not click the link. Show the message to a trusted adult.
Open the official app , use an existing bookmark, or type a known address.

The FTC gives the same advice. Contact an organisation through an app, phone number, or website you already know is genuine, rather than using details in the suspicious message.

A game message might say, "Confirm your account now to keep your items." Tell your child to stop. If appropriate, take a screenshot and ask an adult to check the account through the normal app.

Never blame a child for clicking. Shame delays reporting. A quick report gives the family more time to change the password, review activity, and stop further changes.

Recover an account without panic

Recover an account through the service's official route, change the exposed password, and check what happened. The child should tell a trusted adult first. Together, they can review recent activity, remove unknown devices, restore the second sign-in check, and store new recovery details safely.

Use the Recover part of the Create, Protect, Recover routine:

Tell a trusted adult. Explain what happened, including any link opened, password entered, code shared, purchase noticed, or unexpected sign-in reported.
Open the official service. Use its known app, a saved bookmark, or an address that the parent types directly. Avoid links and phone numbers from the suspicious message.
Reset the password. Follow the service's official account-recovery process on a familiar, updated device. Create a new, unique password. If the old password was reused, change it on every account where it appears.
Review account activity and devices. Look for unfamiliar sign-ins, messages, purchases, profile changes, or recovery addresses. Sign out of devices the family does not recognise, if the service offers that option.
Restore account protection. Turn 2FA back on, confirm that the passkey still works, and replace any recovery codes that may have been exposed. Treat recovery codes as private credentials and store them securely.

What to check after a reset

The new password is unique.
The recovery email address or phone number is correct.
Unknown devices have been signed out where possible.
2FA or the passkey remains active.
Purchases, messages, and profile changes look familiar.
Saved passwords on shared devices have been updated.
Parental controls and privacy settings remain correct.

Recovery steps differ by service. For example, Google says that changing the password of a supervised child account turns off 2-Step Verification. Families using that account type need to turn it on again after the reset.

Make password security a family habit

To teach children password security, practise the Create, Protect, Recover routine until asking for help feels normal. Start with one account today: review its passphrase, add a second sign-in check if available, and ask your child who they would tell if a login looked wrong.

Por qué los hashes SHA-256 de contraseñas siguen siendo vulnerados

Passwork Team — Fri, 28 Aug 2026 15:36:31 +0000

Uno de los artículos de nuestro blog se ha mantenido consistentemente como el más popular: "Cómo funciona SHA-256: ¿Se puede desencriptar?". Decidimos traer algunas ideas de ese artículo a Dev.to, y esperamos que el tema anime a algunos de ustedes a cuestionar, refinar o ampliar estas ideas en los comentarios. Empecemos.

SHA-256 solo funciona en una dirección

"¿Se puede desencriptar SHA-256?" parece una pregunta razonable, pero mezcla dos operaciones distintas.

El cifrado está diseñado para ser reversible: los datos se transforman usando una clave, y quien tenga la clave adecuada puede recuperar el texto original. SHA-256 funciona de otra manera. Toma una entrada y produce un resumen (digest) de longitud fija, y el algoritmo solo calcula ese resumen hacia adelante.

Los hashes de contraseñas siguen siendo atacables por otra vía: la adivinación (guessing).

Supongamos que un atacante obtiene una base de datos con valores SHA-256(contraseña). Puede tomar una contraseña probable, aplicarle el hash y comparar el resultado con el valor almacenado. Una coincidencia revela la contraseña que produjo ese verificador.

El hashing y el cifrado resuelven problemas diferentes. La resistencia a la reversión bloquea un tipo de ataque. La adivinación sigue disponible como otro.

Qué hace SHA-256

SHA-256 acepta un mensaje de longitud arbitraria y produce un resumen determinista de 256 bits. Una entrada idéntica produce una salida idéntica, e incluso un pequeño cambio en la entrada modifica radicalmente el resumen resultante.

Internamente, SHA-256 rellena el mensaje, lo procesa en bloques de 512 bits, expande cada bloque en un calendario de mensajes (message schedule) y ejecuta una función de compresión durante 64 rondas. Para las decisiones sobre almacenamiento de contraseñas, una característica de diseño importa más que cualquier otra: SHA-256 está construido para calcular resúmenes de forma eficiente.

Esa eficiencia es útil. SHA-256 aparece en verificaciones de integridad, flujos de firma digital y otros sistemas donde procesar datos rápidamente es exactamente lo que los desarrolladores necesitan. Las contraseñas plantean un problema distinto.

Por qué el hashing rápido también ayuda a los atacantes

Durante un inicio de sesión normal, calcular un resumen SHA-256 con rapidez parece ideal. Después de una filtración de base de datos, esa misma velocidad beneficia al atacante.

Un atacante que trabaja sin conexión (offline) opera de forma independiente a tu aplicación. Los límites de frecuencia, la limitación de peticiones (throttling) de la API y los bloqueos de cuenta quedan fuera de juego, porque el atacante prueba contraseñas candidatas contra un verificador robado usando su propio hardware.

Para una función de hash de propósito general, hacer que cada cálculo sea económico es buena ingeniería. Para el almacenamiento de contraseñas, queremos que cada intento tenga un costo computacional significativo.

Por eso la Guía de almacenamiento de contraseñas de OWASP recomienda esquemas de hashing de contraseñas dedicados en lugar de funciones de hash rápidas de propósito general como SHA-256.

La distinción importante está entre un primitivo criptográfico y el sistema construido a su alrededor. SHA-256 puede seguir siendo una función de hash segura mientras que SHA-256(contraseña) sigue siendo un diseño de almacenamiento de contraseñas deficiente.

El salting y la derivación de claves resuelven problemas distintos

Añadir una sal (salt) es una mejora esencial, pero su propósito a veces se malinterpreta.

Una sal es un valor aleatorio único asociado a cada registro de contraseña. Dos usuarios que elijan la misma contraseña producen entonces valores almacenados diferentes. El salting también anula la precomputación reutilizable: un atacante no puede preparar una sola tabla de hashes de contraseñas comunes y aplicarla de forma eficiente en múltiples usuarios o bases de datos.

Una sal convierte cada registro de contraseña almacenado en un objetivo distinto. Hacer que cada intento sea costoso es un trabajo aparte, gestionado por una función de derivación de claves (KDF) para contraseñas.

La sal normalmente se guarda junto al verificador de la contraseña, así que en cuanto un atacante roba la base de datos, la conoce. Aun así puede tomar una contraseña candidata, combinarla con la sal de ese usuario, calcular el resultado y compararlo con el verificador almacenado.

Una KDF para contraseñas diseñada específicamente se encarga de ese segundo trabajo, incrementando deliberadamente el costo de cada intento. Argon2id y PBKDF2, por ejemplo, permiten a los sistemas ajustar la cantidad de trabajo necesaria para derivar un verificador.

Los controles resuelven problemas distintos:

Control	Función principal	Dónde queda corto
Sal aleatoria única	Evita la precomputación compartida y hace que contraseñas idénticas generen hashes diferentes	La velocidad de adivinación contra un registro conocido no cambia
Argon2id / PBKDF2	Hace que cada intento offline sea más costoso	Una contraseña débil sigue siendo débil
Limitación de frecuencia + MFA	Reduce el riesgo de apropiación de cuenta en línea	Una base de hashes robada sigue necesitando su propia protección

Estos mecanismos se complementan entre sí. Cada uno cubre una parte distinta de la amenaza.

Qué usar en un sistema nuevo

Para una aplicación nueva, una opción por defecto razonable suele ser Argon2id. OWASP recomienda actualmente esta opción como la preferida para el hashing de contraseñas. Cuando aplican requisitos FIPS-140, OWASP recomienda PBKDF2-HMAC-SHA-256 con un factor de trabajo de al menos 600,000.

Trata PBKDF2-HMAC-SHA-256 como una construcción distinta de SHA-256 puro. SHA-256 puede formar parte de la construcción, pero PBKDF2 combina una función pseudoaleatoria con una sal y un factor de trabajo configurable, específicamente para hacer que las adivinaciones repetidas sean más costosas.

NIST SP 800-63B describe de forma similar el hashing de contraseñas en torno a sales y factores de costo, incrementando este último a medida que el rendimiento del sistema lo permite.

Trata esos parámetros como configuración: pon a prueba su rendimiento (benchmark) en tu infraestructura, documenta la decisión y revísala conforme evolucionen el hardware y las recomendaciones.

Las aplicaciones también necesitan una vía de actualización. Un framework o una biblioteca criptográfica mantenida activamente facilita esto más que implementar el esquema por cuenta propia. Almacena suficientes metadatos junto a cada verificador, incluyendo la versión del algoritmo, la sal, los parámetros y el verificador, para poder reconocer registros antiguos y migrarlos más adelante.

Más allá del hashing de contraseñas: los controles que aún necesitas

Una buena KDF para contraseñas cambia principalmente la economía de la adivinación offline después de que se ha robado una base de verificadores. Aborda un modelo de amenaza: la adivinación offline tras una filtración. Otras vías de ataque requieren controles independientes.

Los sistemas en producción todavía necesitan controles alrededor del flujo de inicio de sesión. La limitación de frecuencia incrementa el costo de la adivinación en línea. La MFA reduce el valor de una contraseña robada. Las políticas de contraseñas y las verificaciones contra contraseñas filtradas reducen las credenciales predecibles. La autenticación resistente al phishing aborda ataques que el hashing de contraseñas nunca llega a ver.

La planificación operativa también importa. Parámetros que parecían razonables hace varios años pueden llegar a ser económicos de calcular con el tiempo. Una estrategia de migración práctica consiste en detectar un verificador desactualizado tras un inicio de sesión exitoso y derivar uno nuevo usando el esquema y los parámetros actuales.

Para el almacenamiento de contraseñas, elige un esquema de hashing diseñado para ese propósito, como Argon2id o PBKDF2-HMAC-SHA-256. Usa bibliotecas mantenidas activamente, diseña pensando en actualizaciones de parámetros y trata la autenticación como un sistema: el hashing de contraseñas es solo uno de varios componentes.

SHA-256(contraseña) crea un problema de seguridad, mientras que SHA-256 en sí mismo sigue siendo criptográficamente sólido. La verdadera pregunta es cuán costoso hacemos cada intento del atacante una vez que la base de datos ya está fuera de nuestro control.

¿Qué esquema de hashing de contraseñas usa tu stack hoy en día, y cómo planificas y ejecutas las actualizaciones de parámetros o algoritmos como un despliegue gradual en lugar de una migración riesgosa de una sola vez?

Referencias

Why SHA-256 password hashes still get cracked

Passwork Team — Fri, 28 Aug 2026 10:56:34 +0000

One article on our blog has consistently remained our most popular: "How SHA-256 works: Can you decrypt it?" We decided to bring a few ideas from it to Dev.to, and we hope the topic prompts some of you to challenge, refine, or expand on these ideas in the comments. Let's get into it.

SHA-256 only runs one direction

"Can SHA-256 be decrypted?" sounds like a reasonable question, but it mixes two different operations.

Encryption is designed to be reversible: data is transformed using a key, and someone with the appropriate key can recover the original plaintext. SHA-256 works differently. It takes an input and produces a fixed-length digest, and the algorithm only computes that digest forward.

Password hashes remain attackable through a different route: guessing.
Suppose an attacker obtains a database containing SHA-256(password) values. They can take a likely password, hash it, and compare the result with the stored value. A match reveals the password that produced that verifier.

Hashing and encryption solve different problems. Reversal resistance blocks one type of attack. Guessing remains available as another.

What SHA-256 does

SHA-256 accepts a message of arbitrary length and produces a deterministic 256-bit digest. Identical input produces identical output, and even a small change to the input radically changes the resulting digest.

Internally, SHA-256 pads the message, processes it in 512-bit blocks, expands each block into a message schedule, and runs a compression function for 64 rounds. For password-storage decisions, one design characteristic matters most: SHA-256 is built to compute digests efficiently.

That efficiency is useful. SHA-256 appears in integrity checks, digital-signature workflows, and other systems where processing data quickly is exactly what developers want. Passwords create a different problem.

Why fast hashing helps attackers too

During a normal login, computing one SHA-256 digest quickly looks ideal. After a database leak, that same speed benefits the attacker.

An offline attacker works independently of your application. Rate limits, API throttling, and account lockouts stay outside the loop, because the attacker tests candidate passwords against a stolen verifier using their own hardware.

For a general-purpose hash function, making each calculation inexpensive is useful engineering. For password storage, we want each guess to carry a meaningful computational cost.

That is why the OWASP Password Storage Cheat Sheet recommends dedicated password-hashing schemes over fast general-purpose hashes such as SHA-256.
The important distinction sits between a cryptographic primitive and the system built around it. SHA-256 can remain a secure hash function while SHA-256(password) remains a poor password-storage design.

Salting and key derivation solve different problems

Adding a salt is an essential improvement, but its purpose is sometimes misunderstood.

A salt is a unique random value associated with each password record. Two users choosing the same password therefore produce different stored values. Salting also defeats reusable precomputation: an attacker cannot prepare one table of common password hashes and apply it efficiently across many users or databases.

A salt makes every stored password record a distinct target. Making each guess expensive is a separate job, handled by a password key derivation function (KDF).

The salt normally sits alongside the password verifier, so once an attacker steals the database, they know it. They can still take a candidate password, combine it with that user's salt, calculate the result, and compare it with the stored verifier.

A purpose-built password KDF handles that second job by deliberately increasing the cost of each attempt. Argon2id and PBKDF2, for example, let systems tune the amount of work required to derive a verifier.

The controls solve different problems:

Control	Main job	Where it falls short
Unique random salt	Prevents shared precomputation and makes identical passwords hash differently	Guessing speed against one known record stays the same
Argon2id / PBKDF2	Makes each offline guess more expensive	A weak password stays weak
Rate limiting + MFA	Reduces online account-takeover risk	A stolen hash database still needs its own protection

These mechanisms complement each other. Each covers a different part of the threat.

What to use in a new system

For a new application, a sensible default is usually Argon2id. OWASP currently recommends it as the preferred password-hashing choice. When FIPS-140 requirements apply, OWASP recommends PBKDF2-HMAC-SHA-256 with a work factor of at least 600,000.

Treat PBKDF2-HMAC-SHA-256 as a distinct construction from plain SHA-256. SHA-256 may be part of the construction, but PBKDF2 combines a pseudorandom function with a salt and configurable work factor specifically to make repeated guesses more expensive.

NIST SP 800-63B similarly describes password hashing around salts and cost factors, with the cost increased over time as system performance permits.
Treat those parameters as configuration: benchmark them on your infrastructure, document the decision, and revisit it as hardware and recommendations evolve.

Applications also need an upgrade path. A maintained framework or cryptographic library makes that easier than implementing the scheme yourself. Store enough metadata with each verifier, including algorithm version, salt, parameters, and verifier, to recognize older records and migrate them later.

Beyond password hashing: the controls you still need

A good password KDF mainly changes the economics of offline guessing after a verifier database has been stolen. It addresses one threat model: offline guessing after a leak. Other attack paths need separate controls.
Production systems still need controls around the login flow.

Rate limiting raises the cost of online guessing. MFA reduces the value of a stolen password. Password policies and breached-password checks reduce predictable credentials. Phishing-resistant authentication addresses attacks that password hashing never sees.

Operational planning matters too. Parameters that looked reasonable several years ago may eventually become cheap to compute. One practical migration strategy detects an outdated verifier after a successful login and derives a new one using the current scheme and parameters.

For password storage, choose a purpose-built password-hashing scheme such as Argon2id or PBKDF2-HMAC-SHA-256. Use maintained libraries, design for parameter upgrades, and treat authentication as a system: password hashing is one component among several.

SHA-256(password) creates a security problem while SHA-256 itself remains cryptographically sound. The real question is how expensive we make each attacker guess after the database is already outside our control.

What password-hashing scheme does your stack use today, and how do you plan and execute parameter or algorithm upgrades as a gradual rollout instead of a risky big-bang migration?

References
How SHA-256 works: Can you decrypt it? — Passwork.pro
OWASP Password Storage Cheat Sheet
NIST SP 800-63B: Digital Identity Guidelines

Why your password manager shouldn't have a "god mode"

Passwork Team — Mon, 24 Aug 2026 23:53:17 +0000

Your lead DevOps engineer quits on a Friday, no notice, master password included. Or maybe it's simpler: your company's sole founder comes back from a two-week trip and just... can't remember it.

Either way, someone in the room asks the question we hear on almost every technical call about Passwork: "Is there a backdoor for this? A way to just unlock everything?"

The honest answer is no, and that's on purpose. Any "restore everything" button that can instantly decrypt all data in a password manager is a massive single point of failure (SPOF). If you build a backdoor for emergencies, you've also built a front door for attackers. Compromise one account, get everything. That's not a feature, that's the whole system's threat model collapsing into a single credential.

This post is about how we designed access recovery for a zero-knowledge password manager without that button. Instead of one god-mode admin, we split recovery into three isolated layers, each with a narrow job and a hard boundary on what it can't do. We think the pattern generalizes past our own product, so we're sharing the reasoning, not just the feature list.

The zero-knowledge dilemma

Zero-knowledge architecture means the server only ever sees ciphertext. Encryption and decryption happen client-side; the server stores encrypted blobs and has no way to read them without a cryptographic grant, a wrapped key handed to a specific user for a specific vault.

This is great for security and terrible for anyone who assumes recovery works "somehow." If nobody sets up a recovery path before an incident, the math is unambiguous: the data is gone. Not "hard to get," not "requires a support ticket." Gone, because the server never had the key in the first place.

We treat this as the correct trade-off, not a bug to work around. The alternative, a server that can always decrypt on demand, means every password in the vault is one server compromise away from a breach. But it does mean recovery can't be an afterthought. It has to be architecture, decided and configured before anyone needs it, not improvised during an incident at 2 a.m.

So the design question becomes: how do you let an organization recover from losing an account, a device, or an employee, without ever creating a single credential that can decrypt the whole system?

Deconstructing "god mode": our three-tier recovery model

We ended up splitting recovery into three tiers, each solving one narrow problem. None of them, alone or combined, produces a master key to everything. That's the point.

Tier 1: Infrastructure level, the emergency console

The first tier answers a login problem, not a data problem: what if the Owner (the top-level system administrator) can't get into their own account and normal recovery, like an email link, isn't available?

For this we built an emergency console: a set of CLI commands that run on the server itself, not through the web UI. An admin with server access can use it to reset the Owner's password or two-factor authentication when the normal recovery path isn't available.

Two things gate this deliberately:

It requires server-level access, via SSH or console, rather than a button in the interface.
The emergency commands are locked behind a state flag that the server admin has to explicitly enable before they can run.

The emergency commands stay disabled by default and become available only after a server administrator explicitly enables the required state flag. Deliberate activation protects the recovery path from accidental use and keeps it beyond the reach of someone with web application access alone.

The key boundary is that the emergency console restores login access while preserving the existing cryptographic access model. Resetting the Owner's password lets them sign in again with exactly the vault permissions they had before the incident.

Vault decryption still depends on cryptographic grants issued in advance. In other words, the emergency console solves the account-access problem, while access to vault data remains governed by the existing grants.

Every use of it gets logged as a distinct event: password reset, 2FA reset, whatever ran. It's traceable, not a quiet backdoor.

Tier 2: Data level, the offline recovery account

Fixing login solves half the problem. The other half: what if the person who actually had the cryptographic grant to a vault is the one who's gone?

Our approach relies on pre-shared cryptographic grants, set up before anything goes wrong rather than improvised during the incident.

In practice: create a standard user account (not an Owner, not a service account), assign it as administrator for the specific vault types your team cares about, then print the master password and put it in a physical safe, a bank deposit box, or another team's offline vault.

The classic break-glass pattern works because the cryptographic access is already in place before the emergency. There's no way to retroactively grant access to a vault after the fact if nobody set up the grant beforehand. If your recovery account only has access to two vault types today, that's exactly what it'll be able to recover next year, no more.

The scope is deliberately narrow. This account isn't root. It's a targeted key to a defined set of vaults that someone consciously decided were worth this level of insurance. Wider coverage means assigning more vault types to it, and thinking harder about how you're storing that offline password.

Tier 3: Automation level, service accounts aren't a backdoor

The third tier is less about recovery and more about closing a mistake we've seen teams make: treating a service account as an emergency login.

A service account exists for automation, onboarding scripts, CI/CD pipelines, identity provider sync, anything that needs programmatic access to the API without a human typing a password. It authenticates with API tokens.

Critically, a service account is designed exclusively for programmatic access through API tokens. Interactive login remains unavailable. That separation is a deliberate design decision: allowing interactive access would turn a narrowly scoped automation credential into a quiet backdoor, potentially sitting in a CI secret store with privileges beyond its intended purpose.

If a token leaks, the blast radius is whatever that integration was explicitly granted, and nothing else. It's still bound by the same access-grant rules as any other account. It doesn't become a master key just because it's automated.

The architecture at a glance

The three recovery tiers solve different problems and deliberately stop at different boundaries.

The emergency console restores access to the Owner account when normal login recovery is unavailable. It requires server-level access and explicit activation, and it cannot decrypt vaults the Owner was never granted access to.

The offline recovery account restores access to selected vault types through cryptographic grants created in advance. Its reach is limited to those pre-assigned vaults: it cannot gain new access retroactively during an incident.

The service account handles programmatic access for integrations and automation. Its API token is limited to explicitly granted resources and cannot be turned into an interactive web login.

This separation is the important part. Recovery does not depend on one privileged credential with access to everything. Each mechanism has its own trigger, scope, and boundary, so compromising one recovery path does not automatically compromise the entire system.

Together, the three tiers provide different paths for account recovery, data recovery, and automation without creating a universal master key.

Security is about distributing trust, not concentrating it

The engineering takeaway is simple, even if implementing it took real work: a password manager with a god-mode admin isn't actually zero-knowledge, whatever the marketing says. If one account, one password, or one command can unlock every secret in the system, you've built a single point of failure with extra steps.

The harder, more useful design goal is recovery without concentration: multiple isolated mechanisms, each auditable, each scoped to a narrow job, none of them capable of becoming a universal key on its own.

We're curious how other teams solve this. How does your org handle the bus factor for critical infrastructure secrets? Physical safe, Shamir's Secret Sharing, something homegrown with HashiCorp Vault, or are you still crossing your fingers? Drop it in the comments, we'd like to compare notes.

IBM’s 2026 breach report: 5 security controls engineering teams should review

Passwork Team — Mon, 24 Aug 2026 23:08:08 +0000

IBM’s 2026 Cost of a Data Breach Report (wich was published in July'26) contains a number that caught the Passwork team’s attention: AI-enabled attacks now account for more than one in four malicious breaches, up 56% year over year.

The average cost of those incidents reached $6.04 million, about $1 million above the global average.

At Passwork, we build a self-hosted password and secrets management platform, so we looked at IBM’s findings from a specific engineering perspective: what they mean for software delivery, AI identities, secrets, and access management.

A $6 million average breach does not mean a vulnerable dependency, exposed API, or leaked token in your repository is a "$6 million bug." IBM studied 602 organizations that had already experienced breaches, so its numbers are better treated as directional benchmarks than as a risk calculator for an individual application.

The more useful question for developers is what happens to the time between vulnerability discovery and exploitation as AI capabilities improve.

Research into frontier models suggests that AI can accelerate vulnerability discovery and validation. If attackers can move through that part of the process faster, security teams cannot leave triage and remediation on the same schedule they used a few years ago.

For us, that changes the engineering question from:

How much could a breach cost?
to:

What controls need to become continuous parts of software delivery?

Here are five areas we think are worth reviewing.

1. AI changes the remediation clock

Vulnerability management has always involved a race between discovery and remediation. AI potentially changes the speed of one side of that race.

That makes a quarterly vulnerability review increasingly difficult to justify for internet-facing systems.

The answer is not necessarily to put an AI agent into every CI/CD pipeline. Automation can help with classification, enrichment, or even suggesting a patch, but it does not solve the harder engineering questions: Who owns the vulnerable component? How urgent is the finding? What happens if the fix cannot be deployed immediately? And how do we know the fix actually reached production?

A practical workflow needs to answer those questions before the vulnerability appears.

For internet-facing services, we think that means at least:

maintaining an inventory with a clear owner for every exposed service;
creating a separate path for known-exploited and actively exploited vulnerabilities;
defining remediation SLAs based on exploitability and exposure, not severity alone;
having compensating controls when an immediate patch is impossible;
verifying that the fix reached production rather than treating a merged PR as remediation.

The compensating control matters. Sometimes upgrading a dependency immediately is not realistic. But reducing exposure may be: disable the vulnerable feature, add a WAF rule, restrict a network path, introduce a feature flag, or temporarily remove the service from the public surface.

The objective is not "patch everything immediately." It is to make sure a critical finding never enters a backlog with no owner and no next action.

2. The 18% gap: detection is not secure delivery

One of the most interesting findings in IBM’s report is where organizations are actually deploying AI agents.

Among breached organizations, about half reported using AI agents in their SOCs. Their most common uses were threat hunting (56%) and response and containment (54%).

Only 18% used them for vulnerability scanning and management.

That gap matters more to us than the question of whether a team uses AI security tooling at all.

Detection and response happen after something suspicious has occurred. Vulnerability management sits closer to the software delivery process, where engineering teams can remove or reduce exposure before exploitation.

The practical lesson from the 18% figure is not "put an AI agent everywhere." It is to make vulnerability work part of delivery.

For example, we would review four places.

PR and CI. Which security findings actually block a merge, and which simply disappear into the backlog? Define clear CI gate rules that combine severity with exploitability instead of treating every finding the same way.

Dependencies. Which critical direct and transitive dependencies have no clear owner? Assign ownership and maintain an up-to-date SBOM so that a vulnerability can be mapped to the team responsible for fixing it.

External surface. Who owns staging environments, demo instances, and services that were deployed and then forgotten? Connect the asset inventory to owners and use expiry or tagging policies for temporary services.

Remediation. What happens when a patch cannot ship today? Define compensating controls in advance: restrict network exposure, disable the affected feature, introduce a WAF rule or feature flag, or temporarily remove the vulnerable service from the public surface.

AI may make parts of this workflow faster. It can enrich an alert, correlate it with asset exposure, summarize a CVE, or propose a patch.

But ownership, review and safe rollout remain engineering responsibilities.

3. AI security is mostly systems security

IBM also found that more than 20% of organizations reported an incident targeting an AI model or application. Among organizations experiencing AI-related breaches, 92% lacked proper AI access controls.

The obvious reaction is to focus on the model.

We think the more useful place to look is everything around it.

A production AI feature rarely consists of a model call in isolation. It may connect to APIs, vector stores, queues, databases, internal tools, SaaS applications, cloud infrastructure and CI/CD systems.

An agent may also be allowed to perform actions rather than simply generate text.

That turns familiar software architecture decisions into AI security decisions.

When reviewing an AI workflow, we would ask:

Which tools can the agent call by default?
Which data sources can it query?
What data is used for retrieval, generation, evaluation and telemetry?
Can its account read data unrelated to its current task?
Can it modify production state?
Where are credentials for model providers, databases, queues and cloud services stored?
Are development, staging and production using separate identities?
Can an action be traced back to a specific user, service or agent?

Prompt injection and model inversion introduce new attack patterns, but many of the controls around them are not new.

API boundaries still matter. Least privilege still matters. Secret handling still matters. Logging still matters. Safe defaults still matter.

In other words:

AI security is largely systems security applied to a new type of application.

4. Treat an AI agent as a production identity

IBM reports that fewer than half of organizations actively secure non-human identities such as API keys, service accounts and machine credentials in their AI workflows.

As agentic systems expand, that becomes difficult to treat as an IAM detail.

An AI agent is not only a model call. In production, it is an identity with tools, data paths, permissions and secrets.

We think it should be managed accordingly.

A basic review can start with five questions:

Does every agent or service account have an owner and defined purpose? "AI-agent-prod" is not enough documentation if nobody knows which application owns it or why it has access.
Where do its secrets live? They should not be embedded in source code, prompt templates, configuration copied into chat, or shared documents.
Are permissions scoped to the task? A workflow that needs read access to one data source should not inherit a credential that can administer the entire environment.
Can access expire or be revoked? Long-lived credentials with no rotation or lifecycle owner increase blast radius when something goes wrong.
Are environments separated? An experimental agent running in development should not quietly inherit production credentials because using the same service account was easier.

As AI creates more machine identities, existing weaknesses in secret management and access governance become easier to multiply.

5. Shadow AI is an enablement problem before it becomes an enforcement problem

IBM reports that Shadow AI was associated with 43% of AI-related incidents in its 2026 study, while only about a third of organizations enforced strict approval processes for internal AI tools.

The simplest response is to ban unapproved LLMs. But a clear policy alone doesn’t solve the engineering problem.

If the approved workflow is too slow or too restrictive for actual development work, people will find alternatives. A better starting point is to give teams a secure path that is easy enough to use.

That might include:

approved models and providers;
corporate accounts and SSO;
clear rules for code, logs and customer data;
secret redaction before prompts are sent;
a lightweight approval path for new AI tools;
a test environment for agent experiments.

The data policy should also be concrete.

"Do not send sensitive data to AI" leaves developers to decide what "sensitive" means in the middle of a task.

A more useful policy explicitly covers things such as production database dumps, API tokens, private keys, customer or personal data, credentials and unredacted production logs.

And it should provide alternatives: masked logs, synthetic datasets, least-privilege test environments, approved enterprise workspaces or local/offline workflows where appropriate.

For us, Shadow AI is an enablement problem before it becomes an enforcement problem.

Automation matters when it closes a queue

There is one more IBM result worth putting into engineering context.

Organizations reporting extensive use of security AI and automation had average breach costs $1.93 million lower and breach lifecycles 65 days shorter than organizations using no AI or automation.

That is an association in IBM’s sample, not proof that adding AI automatically produces those savings.

But the mechanism behind useful automation is familiar to engineering teams: reduce the time between a signal and a safe action.

That can be much less glamorous than deploying an autonomous security agent.

It could mean:

dependency update PRs that automatically run the relevant test suite;
vulnerability alerts enriched with service ownership and exposure data;
secret scanning before credentials reach the repository;
infrastructure-as-code checks in CI;
deterministic rollback for risky deployments;
security alerts automatically routed to the team that owns the affected service.

Each removes queue time or manual context switching.

That logic applies even to small engineering teams with no dedicated SOC and no budget for security AI agents.

Three controls to inspect this sprint

IBM’s 2026 report is framed around breach economics. For engineering teams, we think its more useful message is about asymmetric speed.

AI can accelerate vulnerability discovery and attack workflows. At the same time, AI adoption is creating more applications, integrations, service accounts, tokens and machine identities that need to be governed.

Adding another detection tool does not close that gap by itself.

If we had to turn the report into three tickets for the next sprint, they would be:

1. Create a fast path for actively exploited vulnerabilities.
Identify internet-facing assets, assign owners, define escalation rules and document what to do when immediate patching is impossible.

2. Inventory AI-agent identities and secrets.
For each agent or AI-enabled service, record its owner, purpose, permissions, credentials, environment, rotation policy and revocation path.

3. Give developers an approved way to use AI.
Define allowed providers, accounts and data types, plus a practical process for testing or requesting new tools.

None of these controls depends on predicting exactly how capable the next frontier model will be.

They address a simpler problem: when discovery and exploitation get faster, the gap between finding, prioritizing and fixing a weakness becomes more important.

Security controls have to move closer to where software is built and shipped.

Read the full IBM’s 2026 Cost of a Data Breach Report analysis on our blog.

What is zero-knowledge encryption? How it works in 5 minutes

Passwork Team — Tue, 21 Jul 2026 16:12:48 +0000

Zero-knowledge encryption is an architecture where encryption and decryption happen exclusively on the user's device. The server stores only ciphertext and encrypted keys. Even if the provider is breached, subpoenaed, or has a rogue employee with database access, the plaintext stays out of reach.

Zero-knowledge encryption in brief

The server never holds the decryption key. It stores ciphertext and encrypted keys only, so a breach, subpoena, or rogue admin gets nothing readable.
Keys are generated and used exclusively on the user's device , derived from a master password through PBKDF2, RSA, and AES-256 layers.
It protects data at rest, in transit, and in use, but not against phishing, careless sharing, or metadata exposure.
Pairing it with MFA, strong master password hygiene, and air-gapped deployment closes the gaps encryption alone doesn't cover.
Verify a vendor's claim through a published documentation, independent audits, an honest recovery flow, and, ideally, auditable source code.

What zero knowledge means

Zero-knowledge architecture means the provider has no way to read your plaintext data, not that it simply chooses not to look. The distinction that matters: keys are generated and used entirely on the client, and the server only ever holds encrypted blobs it cannot decrypt on its own, even under legal compulsion.

Compare that with ordinary "encrypted storage." A provider might encrypt your data at rest, but if it also holds the decryption key, it can technically read that data whenever it wants. Encryption at rest protects against physical theft of hard drives. It doesn't protect against the provider itself, or against anyone who compromises the provider's infrastructure.

Three properties separate real zero knowledge from marketing copy:

Keys are generated client-side, using a cryptographically secure pseudo-random number generator (CSPRNG), not on a server.
The private key never leaves the device in plaintext and is never transmitted to the server unencrypted.
The server stores only encrypted blobs, including encrypted copies of the keys themselves.

Aspect	Standard encryption	Zero-knowledge architecture
Who generates the keys	Provider (server)	User's device (client)
Where keys live	Server, sometimes in reversible form	Encrypted, never in plaintext on the server
Can the provider read your data	Technically yes	Cryptographically no
What a breach exposes	Plaintext or weakly wrapped data	Ciphertext only

How the encryption chain works: a real example

Zero-knowledge encryption runs on a chain of key derivation and encryption steps, each one unlocking the next. In Passwork's cryptography model, a master password becomes a master key through PBKDF2. That master key decrypts a private RSA key, which decrypts vault keys, which decrypt the record keys protecting the actual passwords and secrets.

Here's the client-side chain, step by step:

Master password → master key. The user enters their master password. PBKDF2 (HMAC-SHA-256, 300,000 iterations) derives a 512-bit master key, and the server-side derivation runs at 600,000 iterations for an added layer. The high iteration count exists for one reason: it makes brute-forcing the password computationally expensive.
Master key → private RSA key. The master key decrypts the user's private RSA-2048 key (RSA-OAEP, SHA-256) with AES-256. That private key sits encrypted on the server. Without the master password, it's inert data.
Private key → vault key. The private RSA key decrypts a symmetric vault key (256-bit, roughly 596 bits of entropy). A vault holds a collection of records shared among team members, and each vault carries its own unique key.
Vault key → record key → record data. The vault key decrypts individual record keys, which in turn decrypt the actual passwords, secrets, and attached files, all through AES-256.
A second, independent layer. Separately from the client-side chain, a server key (256-bit, OpenSSL-generated) encrypts the database with AES-256. Two independent keys, two independent layers. Compromising one doesn't compromise the other.

What the server actually stores. Not the master password. Not the plaintext of anything. It stores: the encrypted master key hash for identity verification, the encrypted private key, encrypted vault and record keys, encrypted record data, and a verification hash used to confirm a login attempt without ever seeing the password itself.

Because the server never holds the client-side decryption key, a database breach yields only ciphertext. That's the payoff of the whole chain: anyone who steals the database, backups, or server-side key gets nothing usable.

That protection has a limit, though. It defends against infrastructure compromise, not against an attacker who obtains a valid master password and logs in as the user. IBM's 2025 Cost of a Data Breach Report notes that attackers increasingly rely on stolen credentials rather than exploiting infrastructure directly, a path zero-knowledge architecture doesn't cover. It's a reason to pair the architecture with MFA.

What zero-knowledge protects, and what it doesn't

Zero-knowledge is powerful, but it isn't magic. It defends the storage layer, not the endpoint, and understanding that boundary is what separates an informed buyer from someone repeating a vendor's tagline.

Protects against:

Server breaches. An attacker who dumps the database gets encrypted blobs, nothing more.
Insider access. Database administrators, backup operators, and support staff can't read plaintext, because none of them hold the client-side keys. This is what enforces separation of duties: the person who maintains the server doesn't automatically get to read the passwords stored inside it.
Subpoenas and legal orders. Whoever operates the infrastructure has nothing readable to hand over, since the decryption keys never leave the client.
Database leaks or stolen backups. Exposed records are ciphertext, useless without the client-side keys.

Does not protect against:

Phishing. If you hand your master password to an attacker, the architecture can't stop them.
Public sharing of decrypted data. Once you've decrypted something and pasted it somewhere insecure, encryption is no longer the relevant control.
Metadata leakage. The server typically knows when you accessed a vault, even if it doesn't know what you accessed.

Data security is usually described across three states: at rest, in transit, and in use. Zero-knowledge architecture is fundamentally about at rest: the server stores ciphertext it cannot decrypt, regardless of how it's accessed.

In transit, protection comes from TLS, a separate control. What zero-knowledge adds here is a side effect, not a substitute: data leaves the client already encrypted, so even a TLS failure wouldn't expose plaintext.

In use, when the vault is unlocked and a record gets decrypted, that decryption happens only inside the authenticated user's own client, for that one user. The server never receives or observes the plaintext at any point in that process.

Reinforcing zero-knowledge in practice

Zero-knowledge encryption protects data, but it doesn't cover authentication habits or network exposure. Pairing it with MFA, master password hygiene, organizational controls, and air-gapped deployment closes the remaining gaps.

Security foundation:

Multi-factor authentication (MFA). An attacker who phishes the master password still needs the second factor to unlock the vault.
Master password hygiene. PBKDF2's iteration count slows brute-forcing, but it can't fix a weak or reused password. Length and uniqueness still matter more than the KDF around them.
Organizational controls. Role-based access, group permissions synced from AD/LDAP, and a full audit log limit how much damage one compromised account can do.

Air-gapped deployment: Running a self-hosted password manager with no outbound connection removes remote exploitation, cloud supply-chain compromise, and network interception as attack vectors entirely.

How to verify a zero-knowledge claim

Verifying a zero-knowledge claim without reading source code comes down to checking five things a legitimate vendor will readily document: a technical whitepaper, proof of client-side key generation, independent audits, an honest recovery flow, and open cryptography. Vague marketing pages that skip these details are a signal, not proof, of a problem.

Zero-knowledge verification checklist (5 points):

Confirm client-side encryption. Check whether encryption happens before data leaves the browser or app. If keys are generated on the server, it isn't zero-knowledge, regardless of what the marketing says.
Look for independent validation. Third-party penetration tests and certifications such as ISO/IEC 27001 or SOC 2 Type II provide external evidence, not self-reported claims.
Examine the recovery flow. True zero-knowledge means no "password reset" in the traditional sense. If support can reset your access, they hold a key somewhere. Legitimate recovery relies on a pre-generated recovery key that only the user stores.
Favor auditable cryptography. You don't need to read every line, but publicly documented algorithms and parameters is a meaningful trust signal.

The bottom line

Zero-knowledge encryption comes down to one design decision: the server stores only what it structurally cannot read. Everything else, the PBKDF2 iterations, the RSA key exchange, the two-level encryption, exists to enforce that one guarantee at every step of the chain.

For an enterprise team, this is about shrinking the blast radius of a breach. A stolen database, a compromised backup, a support agent with too much access: none of it matters if what leaks is ciphertext nobody can use.