DEV Community: Passwork Team

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.