Protección contra la repetición de nonces

¿Qué es la protección contra la repetición de nonces?

La protección contra la repetición de nonces es un método de seguridad que impide reutilizar más de una vez una transacción, mensaje, permiso, autorización o acción de contrato inteligente válida en cripto.Un nonce es un número o valor único destinado a usarse una sola vez en un contexto concreto.La protección contra repeticiones significa que, una vez utilizada una acción firmada, la red, wallet, contrato o aplicación rechaza el mismo envío si alguien vuelve a presentarlo.En cripto, esta protección es esencial porque las firmas digitales se pueden copiar exactamente.Si un usuario firma una transacción o mensaje y el sistema no registra si ya se ha utilizado, un atacante podría repetir esa firma para volver a ejecutar la misma acción.La acción repetida podría transferir fondos de nuevo, volver a aprobar el gasto de tokens, ejecutar otra vez una llamada a un contrato inteligente, emitir otro voto, reclamar recompensas de nuevo o activar otra autorización.

La documentación de cuentas de Ethereum explica que una cuenta de Ethereum tiene un campo nonce y que solo puede ejecutarse una transacción con un nonce determinado por cuenta.

La misma documentación indica que esto protege frente a ataques de repetición en los que las transacciones firmadas se difunden y vuelven a ejecutarse repetidamente.Por tanto, la protección contra la repetición de nonces es una de las capas básicas de seguridad que permiten utilizar firmas blockchain para transferir valor real.

Aspectos clave de la protección contra la repetición de nonces

• Impide que se acepte más de una vez la misma acción cripto firmada.
• Un nonce puede ser secuencial, aleatorio, específico de un dominio, cuenta o contrato, o estar organizado en carriles.
• Las cuentas de Ethereum controladas externamente utilizan nonces secuenciales para transacciones y evitar la repetición.
• EIP-155 incorpora el ID de cadena a los datos de la transacción firmada para reducir el riesgo de repetición entre cadenas.
• Los datos tipados de EIP-712 siguen necesitando protección contra repeticiones en la aplicación: las firmas tipadas pueden enviarse varias veces si los contratos no rechazan duplicados.
• El permit de ERC-2612 utiliza nonces del titular y fechas límite para impedir que las firmas de aprobación de tokens se reutilicen indefinidamente.
• ERC-3009 utiliza nonces aleatorios de 32 bytes y el estado de las autorizaciones para impedir la repetición de transferencias firmadas.
• Las cuentas inteligentes ERC-4337 utilizan un diseño de nonce más flexible para la abstracción de cuentas y los flujos de trabajo paralelos.
• La protección debería vincular también las firmas a la cadena, el contrato, la función, el usuario, la fecha límite y la acción previstos.
• Un diseño débil de nonces puede provocar doble gasto, aprobaciones repetidas, transacciones atascadas, daños por robo de firmas, fallos de metatransacciones y ataques de repetición entre cadenas.

Por qué importan los ataques de repetición en cripto

Un ataque de repetición se produce cuando alguien toma una acción firmada válida y vuelve a enviarla en un contexto que todavía la acepta.Las firmas cripto no son como las firmas manuscritas en papel: pueden copiarse y retransmitirse exactamente.Si una transacción firmada es válida una vez y el protocolo no la marca como consumida, puede seguir siendo válida.Esto es peligroso porque las blockchains suelen tratar las firmas válidas como autorizaciones.Una transferencia repetida puede volver a mover fondos.Una aprobación repetida puede restablecer el permiso de gasto.Una reclamación repetida puede vaciar un pool de recompensas.Un voto de gobernanza repetido puede distorsionar una decisión si el contrato no registra el estado de votación.Un mensaje de bridge repetido puede acuñar o liberar activos de forma incorrecta.La protección contra repeticiones convierte una firma reutilizable en una autorización de un solo uso.

Cómo evita una repetición un nonce

Un nonce impide una repetición al hacer que cada acción firmada sea única y rastreable.Al firmar una acción, el nonce se incluye en los datos firmados.Cuando se ejecuta la acción, el protocolo comprueba que el nonce sea válido y no se haya utilizado.Si la comprobación se supera, la acción se ejecuta y el nonce se consume, incrementa o marca como usado.Si alguien intenta enviar de nuevo la misma acción firmada, falla la comprobación del nonce.La firma puede seguir siendo matemáticamente válida, pero el sistema la rechaza porque el nonce ya se ha usado.Esta diferencia es importante.La validez de la firma demuestra que el usuario autorizó un mensaje.La vigencia del nonce demuestra que la autorización todavía no se ha consumido.Un sistema seguro necesita ambas cosas.

Nonces secuenciales

Un nonce secuencial es un contador que aumenta tras cada acción aceptada.Las cuentas de Ethereum controladas externamente utilizan este modelo para las transacciones normales.Si una cuenta tiene el nonce 10, la siguiente transacción válida de esa cuenta normalmente necesita el nonce 10.Una vez incluida esa transacción, la siguiente necesita el nonce 11.Así se impide que se ejecuten dos transacciones distintas con el mismo nonce de cuenta.También se establece un orden, ya que normalmente no se puede procesar un nonce posterior antes de completar los anteriores.Los nonces secuenciales son sencillos y eficaces para las transacciones normales de una cuenta.Pueden resultar poco prácticos para metatransacciones, flujos por lotes, varios dispositivos, sesiones automatizadas y sistemas de abstracción de cuentas.Por eso algunos diseños modernos utilizan nonces aleatorios, carriles de nonces o asignaciones específicas de cada aplicación.

Nonces aleatorios

Un nonce aleatorio es un valor único generado al azar, en lugar de mediante un contador ascendente.Son habituales en autorizaciones firmadas y sistemas de metatransacciones que no necesitan un orden estricto.ERC-3009 utiliza nonces de 32 bytes generados aleatoriamente y únicos para la dirección autorizadora.

El estándar ERC-3009 define una función de estado de autorización y eventos que registran si se ha utilizado o cancelado un nonce de autorización.

Este modelo permite que existan simultáneamente varias autorizaciones firmadas independientes.Evita que un nonce secuencial pendiente bloquee las autorizaciones posteriores.La contrapartida es que el contrato debe almacenar o comprobar los nonces aleatorios usados para que no pueda repetirse la misma autorización.Los nonces aleatorios necesitan una fuente sólida de aleatoriedad.Si un nonce es predecible o se reutiliza por error, la protección puede debilitarse.

Nonces de cuenta

Un nonce de cuenta protege las transacciones de una misma cuenta.En las cuentas controladas externamente, ayuda a hacer única cada transacción y controla su orden.Si un usuario envía dos transacciones con el mismo nonce de cuenta, conforme a las reglas habituales solo puede incluirse una.La otra puede rechazarse, sustituirse o seguir siendo inválida, según la red y las comisiones.Por eso las wallets controlan cuidadosamente el siguiente nonce de cuenta.Si una wallet utiliza un nonce demasiado bajo, puede que ya se haya utilizado y la transacción falle.Si utiliza uno demasiado alto, la transacción puede esperar hasta que se confirmen los nonces anteriores que faltan.Si el usuario difunde una transacción de reemplazo con el mismo nonce y una comisión más alta, esta puede sustituir a la transacción pendiente anterior, según las políticas del nodo.Los nonces de cuenta protegen contra la repetición, pero también plantean dificultades prácticas para gestionar transacciones.Los usuarios las perciben como transacciones atascadas, colas pendientes, reemplazos o intentos de cancelación.

Protección contra repeticiones mediante el ID de cadena

La protección mediante el ID de cadena impide que una transacción firmada para una cadena sea válida en otra que utilice un formato similar.Esto cobró especial importancia tras las divisiones de cadenas y el crecimiento de redes compatibles con EVM.

EIP-155 añadió el ID de cadena a los datos de las transacciones firmadas de Ethereum.

El objetivo es que una transacción sea válida en una cadena e inválida en otra con un ID distinto.Sin esta protección, una transacción difundida en una cadena podría copiarse y enviarse en otra si coincidieran la cuenta, el nonce y el formato de transacción.La protección mediante el ID de cadena es distinta de la protección mediante el nonce de cuenta.El nonce de cuenta impide repetir la misma transacción en la misma cadena.El ID de cadena ayuda a impedir que se utilice la misma transacción firmada en otra cadena.Una protección sólida suele necesitar ambas medidas.

Separación de dominios

La separación de dominios vincula una firma a un contexto de firma específico.Ese contexto puede incluir el ID de cadena, la dirección del contrato, el nombre del protocolo, la versión, el tipo de función, la dirección del usuario, el nonce y la fecha límite.

EIP-712 define la firma de datos estructurados tipados e incluye campos de dominio como el nombre, la versión, chainId y verifyingContract.

La separación de dominios ayuda a impedir que otra aplicación acepte una firma destinada a una aplicación concreta.Por ejemplo, un usuario puede querer firmar un mensaje para un contrato específico en una cadena determinada.Si la firma no incluye la cadena y el contrato verificador, otro contrato o cadena podría interpretarla como válida.Esto supone un riesgo de repetición, porque la misma firma puede trasladarse entre contextos.Un nonce impide reutilizarla en un contexto.La separación de dominios ayuda a evitar que se use en el contexto equivocado.Ambas medidas son necesarias para que las firmas off-chain sean seguras.

Protección contra repeticiones en mensajes EIP-712

EIP-712 facilita que las wallets y los usuarios comprendan los mensajes, pero no hace automáticamente que cada mensaje firmado pueda utilizarse una sola vez.La sección de seguridad de EIP-712 advierte que las aplicaciones deben gestionar correctamente la recepción repetida del mismo mensaje firmado.Esto significa que el contrato o la aplicación debe rechazar los mensajes repetidos o hacer que la acción repetida no tenga efectos adicionales.Un mensaje tipado puede incluir un nonce, pero el contrato receptor debe comprobarlo y consumirlo.Puede incluir una fecha límite, pero esta debe hacerse cumplir on-chain.Puede incluir un contrato verificador, pero el contrato debe verificar correctamente el separador de dominio.Los datos tipados mejoran la claridad, no la protección contra repeticiones por sí solos.La seguridad frente a repeticiones depende del diseño completo.Un flujo EIP-712 seguro combina la separación de dominios, el seguimiento de nonces, la validación de firmas, la vinculación de la acción y la comprobación de fechas límite.Omitir cualquiera de estos elementos puede generar riesgos de repetición.

Protección contra repeticiones en el permit de ERC-2612

ERC-2612 permite al titular de un token aprobar su gasto mediante un mensaje firmado, en lugar de una transacción de aprobación on-chain directa.Esto mejora la experiencia de usuario porque otra parte puede enviar el permit firmado en nombre del titular.

El estándar ERC-2612 exige una función nonces y establece que, si el permit se ejecuta correctamente, debe incrementar el nonce del titular.

El estándar también indica que el mapa de nonces se proporciona para proteger contra repeticiones.Así se impide utilizar varias veces la misma firma de permit.ERC-2612 también incluye un parámetro de fecha límite.Esta limita el tiempo durante el cual el permit firmado sigue siendo válido.Es importante porque el relayer que recibe un permit puede elegir cuándo enviarlo antes de que caduque.Una fecha límite cercana puede reducir el riesgo de que se utilicen firmas antiguas más adelante.Una gestión deficiente del nonce y de la fecha límite en un permit puede generar un riesgo importante de aprobación de tokens.

Protección contra repeticiones en ERC-3009

ERC-3009 es un patrón de autorización de transferencias de tokens mediante firma.En lugar de aprobar primero a un tercero, el titular firma una autorización para una transferencia concreta.Antes de ejecutarla, el contrato comprueba la firma, el periodo de validez y el nonce.ERC-3009 utiliza un mapa authorizationState para registrar si se ha utilizado un nonce.El estándar marca el nonce como usado tras una autorización de transferencia correcta.Así impide volver a ejecutar la misma transferencia firmada.Algunas implementaciones de ERC-3009 también permiten cancelar autorizaciones.Incluye los campos validAfter y validBefore para indicar cuándo es válida la autorización.Este diseño resulta útil para transferencias de tokens sin gas o retransmitidas.También demuestra que la protección contra repeticiones es más que un simple contador.Una autorización segura debería incluir un nonce único, un periodo de validez, un destinatario claro, una cantidad exacta y un dominio correcto.

Protección contra repeticiones en cuentas inteligentes ERC-4337

ERC-4337 introduce la abstracción de cuentas mediante UserOperations y cuentas de contratos inteligentes.

El estándar ERC-4337 define el nonce de UserOperation como un parámetro de protección contra repeticiones.

También exige que las firmas dependan del ID de cadena y de la dirección de EntryPoint para evitar repeticiones entre cadenas o EntryPoint.ERC-4337 utiliza un modelo de nonce semiabstracto.El nonce puede tratarse como una combinación de clave y secuencia.Esto permite que las cuentas inteligentes admitan varios carriles de nonces.Por ejemplo, una wallet podría utilizar un carril para transacciones normales y otro para acciones administrativas.Esto permite que la abstracción de cuentas admita flujos de trabajo paralelos sin perder la protección contra repeticiones.El diseño es más flexible que un único nonce secuencial.La flexibilidad adicional también exige que los desarrolladores de wallets gestionen cuidadosamente los carriles de nonces.

Carriles de nonces

Un carril de nonces es una secuencia independiente de valores nonce.En vez de obligar a que todas las acciones de una cuenta formen una sola secuencia, los carriles permiten que distintas categorías avancen por separado.Esto resulta útil para cuentas inteligentes, claves de sesión, pagos automatizados, suscripciones, acciones de recuperación, movimientos en videojuegos y wallets con complementos.Por ejemplo, un usuario podría tener un carril para gastos diarios y otro para operaciones de recuperación.Una transacción del carril de recuperación no debería bloquear una del carril de gastos diarios.Los carriles pueden aportar flexibilidad y mejorar la experiencia de usuario.También pueden generar complejidad si las wallets no los muestran claramente.Si una wallet firma con el carril equivocado, la acción puede fallar o seguir un orden inesperado.Si un contrato no valida correctamente el carril, la protección contra repeticiones puede quedar incompleta.Los carriles de nonces solo son útiles si sus reglas resultan fáciles de entender.

Protección contra repeticiones en contratos inteligentes

Los contratos inteligentes suelen necesitar su propia protección contra repeticiones, porque los nonces normales de cuenta no protegen todas las autorizaciones a nivel de contrato.Si un contrato acepta una firma, debe determinar si ya se ha utilizado.Por ejemplo, un contrato de reclamación de airdrop puede usar un mapa que marque a un usuario como ya beneficiario.Un contrato de gobernanza puede registrar si un votante ya ha votado una propuesta.Un contrato de permit puede almacenar un nonce por titular.Un contrato de bridge puede almacenar los ID de mensajes procesados.Un escrow de tipo marketplace puede registrar los hashes de las órdenes completadas o canceladas.Todos estos son tipos de protección contra repeticiones.La estructura de datos concreta puede variar, pero el objetivo es el mismo.El contrato debe impedir que la misma autorización provoque cambios de estado repetidos.

Protección contra repeticiones en bridges

Los bridges necesitan una protección sólida porque transfieren valor o mensajes entre cadenas.Un mensaje de bridge puede indicar que se bloquearon activos en una cadena y que deben acuñarse o liberarse en otra.Si el mismo mensaje puede procesarse dos veces, la cadena de destino podría liberar demasiados activos.La protección contra repeticiones en bridges suele utilizar ID de mensaje, ID de cadena de origen y destino, direcciones de contratos de origen, números de secuencia y mapas de mensajes procesados.El contrato de destino debería marcar cada mensaje válido como procesado.Debería rechazar el mismo mensaje si se vuelve a enviar.El riesgo cross-chain es mayor porque las cadenas pueden compartir formatos de dirección, símbolos de tokens e interfaces de contratos inteligentes.Un bridge debe vincular cada mensaje a la cadena de origen y destino, el contrato de bridge, el remitente, el destinatario, la cantidad y el nonce previstos.Una protección débil puede provocar errores de acuñación, pérdida de fondos o riesgo sistémico de liquidez.

Protección contra repeticiones en metatransacciones

Una metatransacción es una instrucción firmada por el usuario y enviada por otra parte.El usuario firma off-chain y un relayer envía la transacción on-chain.Esto puede facilitar el uso de las aplicaciones porque quizá el usuario no tenga que pagar directamente la comisión de gas con el activo nativo.Las metatransacciones requieren una protección cuidadosa contra la repetición de nonces.Si la instrucción firmada puede enviarse varias veces, el relayer o un atacante podría repetir la acción.Los nonces secuenciales pueden causar problemas cuando los usuarios firman varias metatransacciones en distintas aplicaciones al mismo tiempo.Los nonces aleatorios o espacios de nonces por aplicación pueden reducir esas colisiones.Las fechas límite pueden reducir el peligro de las instrucciones firmadas antiguas.La separación de dominios puede impedir que la firma de una metatransacción de una aplicación se utilice en otra.La seguridad de estas transacciones depende tanto de la protección contra repeticiones como de la verificación de firmas.

Protección contra repeticiones en mensajes de inicio de sesión de wallets

Muchas aplicaciones cripto piden a los usuarios que firmen un mensaje para demostrar que controlan una wallet.Esto es habitual para iniciar sesión, vincular cuentas, actualizar perfiles y autenticarse off-chain.El mensaje de inicio de sesión debería incluir un nonce o desafío generado por el servidor.Tras iniciar sesión correctamente, el servidor debería marcar el desafío como usado.Cuando sea posible, el mensaje también debería incluir el dominio, la cadena, la hora de emisión, la fecha de caducidad y la acción prevista.Si no incluye un desafío nuevo, un atacante puede repetir una firma antigua para suplantar al usuario.Si no incluye el dominio correcto, una firma destinada a un sitio web puede utilizarse en otro.Aunque el inicio de sesión con wallet suele ser off-chain, la protección contra repeticiones sigue siendo importante.Una firma que demuestra el control de una wallet no debería convertirse en una contraseña permanente reutilizable.Las firmas de inicio de sesión más seguras son específicas, recientes, limitadas y legibles.

Protección contra repeticiones en la gobernanza

Los sistemas de gobernanza necesitan esta protección para que los votos y las delegaciones no se contabilicen más veces de las previstas.Un contrato de votación puede registrar si una dirección ha votado una propuesta.Un contrato de delegación mediante firma puede utilizar nonces para impedir que se reutilice una firma de delegación.Un sistema de ejecución de propuestas puede marcar una propuesta como ejecutada tras completarse correctamente.La protección también importa entre cadenas si las decisiones de gobernanza se replican en varias redes.Un mensaje de gobernanza firmado para una cadena no debería ejecutarse automáticamente en otra, salvo que esa sea la intención expresa.Los fallos de protección en la gobernanza pueden ser graves porque pueden cambiar parámetros del protocolo, transferir fondos de la tesorería, actualizar contratos o modificar controles de riesgo.Los buenos contratos de gobernanza gestionan cuidadosamente los ID de propuesta, los ID de cadena, las direcciones de contratos, los periodos de votación, los nonces y los estados de ejecución.Un voto solo debería poder reutilizarse si el sistema permite expresamente cambiarlo antes de la fecha límite.Incluso en ese caso, las reglas del cómputo final deben estar claras.

Protección contra repeticiones en airdrops y reclamaciones

Los contratos de reclamación de airdrops y recompensas suelen emplear esta protección para impedir que un usuario reclame más de una vez.Un sistema sencillo puede guardar un registro de reclamaciones para cada dirección que cumpla los requisitos.Un airdrop Merkle puede verificar la prueba del usuario y después marcar la dirección o el índice de reclamación como usado.Una reclamación de recompensa mediante firma puede incluir un nonce, ID de reclamación, ID de campaña, fecha límite y dirección del usuario.Sin protección, una prueba de reclamación válida podría reutilizarse hasta agotar el pool.También debe tenerse en cuenta la separación entre campañas.Una firma de reclamación de la campaña A no debería funcionar en la campaña B.Una reclamación en una cadena no debería funcionar en otra, salvo que se haya diseñado así expresamente.Una reclamación de un token no debería autorizar otro token.Un buen diseño vincula la prueba al usuario, la campaña, la cadena, el token, la cantidad y el nonce correctos.

Protección contra repeticiones y fechas límite

Una fecha límite es el plazo durante el cual una autorización firmada es válida.No sustituye a los nonces, pero reduce el periodo en el que puede utilizarse una firma robada o retrasada.El permit de ERC-2612 utiliza un campo de fecha límite.ERC-3009 utiliza los campos validAfter y validBefore.Las UserOperations de ERC-4337 pueden incluir intervalos de validez mediante datos de validación.La fecha límite resulta especialmente útil cuando el usuario entrega una firma a un relayer o aplicación que puede elegir cuándo enviarla.Sin fecha límite, una autorización firmada antigua podría seguir siendo útil mucho más tiempo de lo previsto por el usuario.Con fecha límite, la firma deja de ser válida tras un momento definido.Las fechas límite breves pueden mejorar la seguridad, pero aumentar los fallos de transacción si hay congestión.La fecha límite más adecuada depende del valor, el riesgo y la urgencia de la acción, así como del tiempo de liquidación previsto.

Protección contra repeticiones e idempotencia

La idempotencia significa que repetir una acción produce el mismo efecto final que ejecutarla una sola vez.EIP-712 indica que las aplicaciones deberían rechazar mensajes firmados repetidos o hacer que la acción autorizada sea idempotente.Por ejemplo, asignar dos veces el mismo nombre de perfil a un usuario puede ser inocuo.Transferir 100 tokens dos veces no lo es.Aprobar dos veces a un gastador puede ser perjudicial o no, según la cantidad y el permiso actual.Emitir dos votos de gobernanza puede ser perjudicial si se cuentan ambos.Reclamar recompensas dos veces es perjudicial si el usuario recibe el doble.Los diseñadores deberían decidir si rechazan la ejecución repetida o hacen que no tenga efectos adicionales.La mayoría de las acciones que mueven valor deberían rechazar repeticiones.La idempotencia puede ser útil para actualizaciones de estado de bajo riesgo, pero no debería aplicarse sin cuidado a acciones financieras.

Protección contra repeticiones y vinculación de firmas

Una firma debería vincularse a la acción exacta que pretende el usuario.Esto significa que el mensaje firmado debería incluir el destinatario, la cantidad, el token, el contrato, el ID de cadena, la finalidad de la función, el nonce, la fecha límite y los parámetros importantes.Si una firma autoriza algo de forma vaga, un atacante podría reutilizarla en un contexto más amplio.Si firma solo un número y no la dirección del token, podría interpretarse para otro token.Si firma solo un destino y no el ID de cadena, podría repetirse en otra cadena.Si firma solo una dirección de usuario y no la dirección del contrato, otro contrato podría aceptarla.La protección es más sólida cuando la firma tiene un alcance limitado.Una firma de alcance limitado especifica exactamente lo permitido, y nada más.Una firma amplia deja margen para repeticiones, usos indebidos y confusión del usuario.Antes de firmar, las wallets deberían mostrar claramente estos detalles.

Protección contra repeticiones y phishing

La protección contra la repetición de nonces no puede proteger completamente a los usuarios frente al phishing.Si un usuario firma un mensaje malicioso con un nonce válido, el atacante puede utilizarlo una vez.El nonce puede impedir que se utilice varias veces, pero el primer uso puede ser perjudicial.Por ejemplo, un sitio de phishing puede pedir al usuario que firme un permit que autoriza el gasto de tokens.El permit puede incluir un nonce válido y una fecha límite.Una vez enviado, el atacante aún puede utilizar esa autorización válida una vez.La protección contra repeticiones impide la duplicación, no las intenciones maliciosas.Los usuarios siguen teniendo que revisar lo que firman.Las wallets deben mostrar advertencias claras y legibles.Los contratos deben limitar el poder de las firmas a acciones concretas.

Protección contra repeticiones y front-running

El front-running ocurre cuando otra parte ve una transacción o firma y envía primero su propia transacción.La protección contra repeticiones puede limitar los daños al permitir que la firma se utilice una sola vez.Sin embargo, no siempre impide que el atacante sea el primero en utilizarla.ERC-2612 señala que otra parte puede adelantarse a la llamada permit antes de que la envíe la parte prevista, aunque el efecto final de la aprobación para el firmante puede ser el mismo.ERC-3009 incluye receiveWithAuthorization para reducir ciertos problemas de front-running al exigir que el beneficiario coincida con quien llama.Esto demuestra que la protección contra repeticiones y la protección contra el front-running están relacionadas, pero son distintas.Un nonce impide la ejecución repetida.Los controles contra front-running determinan quién puede enviar la primera ejecución o beneficiarse de ella.Las firmas de alto valor deberían incluir la vinculación del destinatario, fechas límite e instrucciones específicas sobre la función.Los diseñadores no deberían suponer que las comprobaciones de nonces resuelven por sí solas todos los ataques al mempool.

Protección contra la reutilización entre contratos

La repetición entre contratos se produce cuando un contrato acepta una firma destinada a otro.Puede ocurrir si los datos firmados no incluyen la dirección del contrato verificador.La separación de dominios de EIP-712 ayuda a reducir este riesgo al incluir verifyingContract en el dominio.ERC-2612 recomienda un separador de dominio único para el contrato y la cadena.También puede haber repetición entre contratos si varios utilizan el mismo esquema de firma y no incluyen un dominio específico de cada contrato.Por ejemplo, dos contratos de tokens podrían aceptar el mismo mensaje similar a un permit si los datos firmados son demasiado genéricos.El usuario podría querer aprobar un token, pero otro token podría interpretar la misma firma.Por eso es esencial vincular la dirección del contrato.Una firma válida no debería poder circular libremente entre contratos.Debería pertenecer a un dominio de verificación exacto.

Protección contra la reutilización entre cadenas

La repetición cross-chain ocurre cuando una cadena acepta una transacción o mensaje firmado destinado a otra.EIP-155 reduce este riesgo para las transacciones de estilo Ethereum al añadir el ID de cadena al hash de la transacción firmada.Los datos tipados de EIP-712 también admiten chainId en el dominio de firma.Aun así, pueden producirse repeticiones en mensajes a nivel de aplicación si los datos firmados omiten el ID de cadena.Por ejemplo, un bridge, DAO, permit de token o firma de inicio de sesión debería especificar la cadena prevista cuando importe el contexto de red.Los ID de cadena son especialmente importantes en redes compatibles con EVM, porque las direcciones y el bytecode de los contratos pueden ser similares.Un usuario puede controlar la misma dirección en varias cadenas.Un contrato puede desplegarse en la misma dirección en varias cadenas mediante un despliegue determinista.Sin vinculación a la cadena, una firma puede trasladarse peligrosamente entre redes.Los diseños seguros hacen explícita la cadena.

Protección contra repeticiones y sustitución de transacciones

La sustitución de una transacción se produce cuando un usuario difunde otra transacción con el mismo nonce de cuenta y una comisión más alta para reemplazar una que está pendiente.Esto no constituye por sí mismo un ataque de repetición.Es una técnica normal de gestión de transacciones en muchos flujos de trabajo de tipo Ethereum.La cuestión clave es que, en última instancia, solo puede ejecutarse una transacción con ese nonce.Un usuario puede sustituir una transacción lenta por otra más rápida.También puede enviar una transacción de valor cero a sí mismo con el mismo nonce para cancelar una transacción pendiente.Para que los nodos la acepten, la transacción de reemplazo debe cumplir las reglas de aumento de comisiones de la red.La protección contra repeticiones mediante nonces es lo que permite que el reemplazo tenga sentido.El nonce obliga a la red a elegir una transacción para ese espacio.Los usuarios deben actuar con cuidado, porque reemplazar el nonce equivocado puede cancelar o sustituir una acción que aún querían ejecutar.

Protección contra repeticiones y transacciones atascadas

Una transacción puede atascarse si se mantiene pendiente por tener una comisión baja.Si utiliza el siguiente nonce requerido, las transacciones posteriores de la misma cuenta también pueden quedar bloqueadas tras ella.Es un efecto secundario de los nonces secuenciales.En el orden normal de transacciones, la cuenta no puede saltarse el nonce que falta.El usuario quizá tenga que acelerar o cancelar la transacción atascada enviando un reemplazo con el mismo nonce.Normalmente, las wallets gestionan esto automáticamente, pero configurar nonces manualmente puede generar confusión.Si se establece un nonce demasiado alto, la transacción puede no confirmarse hasta que se completen los anteriores.Si se establece uno demasiado bajo, puede fallar porque ya se ha utilizado.La protección mediante nonces protege la cuenta, pero también exige una secuenciación cuidadosa.Los usuarios avanzados deberían comprender el estado de los nonces antes de modificarlos manualmente.

Protección contra repeticiones y claves de sesión

Las claves de sesión son claves de uso limitado que pueden autorizar ciertas acciones durante un periodo determinado.Son útiles en videojuegos, suscripciones, estrategias automatizadas y wallets de abstracción de cuentas.Necesitan una protección sólida mediante nonces porque pueden firmar muchas acciones pequeñas.La autorización de una clave de sesión debería incluir límites como las funciones permitidas, límites de gasto, contratos de destino, fecha de caducidad, ID de cadena y reglas de nonces.Sin protección mediante nonces, un atacante que capture una firma de clave de sesión podría repetirla.Sin límites de acción, la clave podría tener demasiado poder.Los carriles de nonces pueden separar las acciones de las claves de sesión de las acciones de la wallet principal.Esto puede mejorar la experiencia de usuario y mantener la protección frente a repeticiones.Las claves de sesión deberían poder revocarse fácilmente.También deberían tener un alcance suficientemente limitado para reducir los daños de una repetición.

Protección contra repeticiones y wallets multisig

Las wallets multisig también necesitan protección contra repeticiones.Una transacción multisig suele tener un nonce interno que registra las acciones ejecutadas por la wallet.Los firmantes aprueban un hash de transacción específico que incluye el nonce de la wallet y los detalles de la acción.Cuando la multisig ejecuta la transacción, el nonce avanza o el hash de la transacción se marca como ejecutado.Así se impide volver a utilizar el mismo grupo de firmas para ejecutar dos veces la misma acción.La protección de una multisig debería vincular las firmas a la dirección de la wallet, el ID de cadena, la dirección de destino, el valor, los datos, el tipo de operación y el nonce.Si la wallet está desplegada en varias cadenas, la protección cross-chain cobra especial importancia.Los firmantes deberían confirmar la cadena y la dirección de la wallet antes de aprobar.Una firma multisig no es segura solo porque la hayan firmado varias personas.La carga firmada también debe ser específica y resistente a repeticiones.

Protección contra repeticiones y oráculos

Los sistemas de oráculos pueden firmar actualizaciones de precios, atestaciones de datos, informes de reservas, resultados aleatorios o mensajes cross-chain.Esos paquetes de datos firmados necesitan protección contra repeticiones.No debería aceptarse indefinidamente una actualización de precios obsoleta.Un resultado aleatorio no debería reutilizarse en otra ronda de juego.Una atestación de reservas no debería repetirse después de caducar.Cuando corresponda, un mensaje de oráculo debería incluir el ID del feed, el ID de la ronda, la marca temporal, el número de secuencia, el ID de cadena y el contrato de destino.Los contratos deberían rechazar los mensajes de oráculos obsoletos o ya utilizados.Esta protección es fundamental porque los contratos inteligentes pueden actuar automáticamente en función de datos de oráculos.Si pueden repetirse datos antiguos, las liquidaciones, liquidaciones de contratos, acuñaciones, reembolsos o pagos pueden ser incorrectos.La vigencia de los oráculos y el control de nonces forman parte de la seguridad de los contratos inteligentes.Las firmas correctas no bastan si los datos son antiguos o se reutilizan.

Protección contra repeticiones y aprobaciones de tokens

Las aprobaciones de tokens son una de las áreas más sensibles para la protección contra repeticiones.Una aprobación on-chain normal utiliza el nonce de la transacción de la cuenta y actualiza el estado de la autorización de gasto.Un permit firmado utiliza un nonce de contrato y una fecha límite para autorizar la aprobación sin que el titular envíe directamente una transacción.Si una firma de permit puede repetirse, un gastador podría recuperar una autorización después de que el usuario creyera haberla eliminado.Si el permit omite el gastador, el token, la cantidad, el nonce, la fecha límite o el dominio, la firma puede utilizarse indebidamente.Los usuarios deberían tratar las aprobaciones firmadas como autorizaciones financieras importantes.Las wallets deberían mostrar claramente el gastador, el token, la cantidad, la fecha límite y la aplicación.Los contratos deberían rechazar inmediatamente los nonces de permit ya utilizados.Las aplicaciones deberían evitar solicitar aprobaciones ilimitadas salvo que sea absolutamente necesario.Un diseño de aprobación resistente a repeticiones reduce una de las vías más habituales para vaciar wallets.

Protección contra repeticiones y actualizaciones de contratos inteligentes

Los contratos actualizables plantean consideraciones adicionales sobre repeticiones.Tras una actualización, las firmas antiguas pueden seguir siendo válidas salvo que cambien la versión del dominio, la lógica de nonces o las reglas de validación.Por este motivo, EIP-712 incluye un campo de versión en el dominio de firma.Una actualización importante debería considerar si las autorizaciones antiguas siguen siendo seguras.Si no deberían funcionar después de actualizar, quizá el contrato necesite una nueva versión de dominio o un método para invalidar nonces.Si deberían seguir funcionando, la actualización debe preservar correctamente el estado de los nonces.No migrar ese estado puede permitir repetir firmas antiguas o inutilizar firmas válidas.Los planes de actualización deberían incluir la migración de firmas, cambios de dominio, el diseño de almacenamiento de nonces y la comunicación a los usuarios.La protección contra repeticiones no es solo una cuestión del momento del despliegue.Debe mantenerse tras las actualizaciones y migraciones.

Protección contra repeticiones y bifurcaciones

Una bifurcación de la cadena puede generar riesgo de repetición si ambos lados aceptan el mismo formato de transacción y estado.Si los usuarios conservan las mismas claves privadas y estados de cuenta en ambas cadenas, una transacción de una bifurcación podría repetirse en la otra, salvo que las protecciones sean distintas.La protección por ID de cadena de EIP-155 se diseñó para reducir este riesgo en las transacciones de Ethereum.Sin embargo, las firmas a nivel de aplicación siguen necesitando vinculación a la cadena.Un permit, voto de gobernanza, mensaje de bridge u orden off-chain firmado antes o después de una bifurcación puede comportarse de forma inesperada si no se aclara el contexto de la cadena.Los usuarios deberían actuar con cautela durante las bifurcaciones y divisiones de cadenas.Las wallets y aplicaciones deberían actualizar correctamente los ID de cadena y los separadores de dominio.Los contratos deberían evitar almacenar en caché los ID de cadena de forma que se genere riesgo de repetición tras una división, salvo que el diseño lo gestione de manera segura.La protección frente a repeticiones en bifurcaciones es una cuestión del protocolo y de la aplicación.Ambas capas requieren atención.

Ventajas de la protección contra la repetición de nonces

La primera ventaja es la autorización de un solo uso.Una acción firmada puede consumirse una vez y rechazarse después.La segunda es la unicidad de las transacciones.Las transacciones de una misma cuenta pueden distinguirse mediante nonces.La tercera es el orden.Los nonces secuenciales ayudan a determinar el orden válido de las transacciones de una cuenta.La cuarta es la seguridad cross-chain cuando se combina con los ID de cadena.Las firmas pueden vincularse a la red prevista.La quinta es una mayor seguridad de los contratos inteligentes.Los contratos pueden impedir la repetición de permits, reclamaciones, votos, transferencias y mensajes de bridges.La sexta es una experiencia de usuario más segura.Las wallets pueden detectar con más fiabilidad acciones pendientes, transacciones atascadas y reemplazos.

Riesgos y limitaciones de la protección contra la repetición de nonces

La primera limitación es que la protección no impide el primer uso malicioso de un mensaje firmado.Si un usuario firma una autorización perjudicial, el nonce solo impide que se vuelva a utilizar después de la primera ejecución.La segunda limitación es la complejidad de gestionar transacciones.Los nonces secuenciales pueden atascar transacciones y bloquear colas.La tercera es el coste de almacenamiento.Los contratos que almacenan nonces aleatorios utilizados pueden aumentar el uso de almacenamiento on-chain.La cuarta es el riesgo de implementación.Si falta la comprobación del nonce, las firmas pueden repetirse.La quinta es la complejidad entre dominios.Un nonce puede proteger un contrato, pero no otro contrato o cadena.La sexta es el riesgo de actualización.El estado de los nonces puede romperse durante la migración de contratos si no se gestiona cuidadosamente.

Errores habituales con la protección contra repeticiones

Un error habitual es verificar una firma sin comprobar el nonce.Otro es comprobarlo, pero olvidar incrementarlo o marcarlo como usado.Un tercero es utilizar un único nonce global para todos los usuarios en vez de nonces individuales.Un cuarto es omitir el ID de cadena de los datos firmados.Un quinto es omitir la dirección del contrato verificador de los datos tipados.Un sexto es aceptar firmas sin fecha límite.Un séptimo es permitir que se use el mismo nonce en distintos tipos de acciones.Un octavo es no migrar el almacenamiento de nonces durante las actualizaciones.Un noveno es utilizar nonces aleatorios predecibles.Un décimo es suponer que EIP-712 evita automáticamente todos los ataques de repetición.

Buenas prácticas para desarrolladores

Incluye un nonce en cada autorización off-chain que pueda cambiar el estado o mover valor.Controla los nonces por firmante, no de forma global, salvo que el diseño requiera claramente una secuencia global.Incrementa el nonce o márcalo como usado antes o durante la ejecución, de forma que no pueda eludirse.Incluye el ID de cadena en el dominio firmado cuando importe el contexto de la cadena.Incluye la dirección del contrato verificador en el dominio.Incluye en el mensaje firmado la intención exacta de la función, el destinatario, la cantidad, el token, la fecha límite y los parámetros pertinentes.Utiliza fechas límite o periodos de validez para las firmas retransmitidas.Separa los espacios de nonces para flujos de trabajo independientes cuando se necesite ejecución paralela.Emite eventos cuando se utilicen o cancelen autorizaciones.Antes del despliegue, prueba intentos de repetición, firmas cross-chain, actualizaciones de contratos, cancelaciones y rutas de ejecución fallidas.

Buenas prácticas para wallets y aplicaciones

Antes de firmar, muestra a los usuarios la cadena, el contrato, el gastador, la cantidad, la fecha límite, el contexto del nonce y el tipo de acción.Advierte cuando una firma otorgue capacidad de gasto o una autorización de larga duración.Utiliza desafíos de inicio de sesión recientes para autenticar wallets.Marca los desafíos de autenticación como usados después del inicio de sesión.Evita pedir a los usuarios que firmen mensajes vagos o ilegibles.Cuando sea posible, utiliza datos tipados EIP-712 para estructurar las firmas.Gestiona los nonces de transacciones atascadas con opciones claras para acelerar y cancelar.No ocultes a los usuarios cómo funciona la sustitución de transacciones.Admite carriles de nonces de abstracción de cuentas solo si la interfaz puede explicarlos de forma segura.Protege a los usuarios frente a solicitudes antiguas, caducadas o destinadas a otra cadena.

Buenas prácticas para los usuarios

Lee los avisos de la wallet antes de firmar cualquier mensaje o transacción.Comprueba la cadena antes de firmar.Comprueba qué contrato o aplicación solicita la firma.En aprobaciones tipo permit, comprueba el token, el gastador, la cantidad y la fecha límite.Rechaza las firmas vagas, ilimitadas o ajenas a la acción que vas a realizar.No firmes mensajes de inicio de sesión de dominios sospechosos.No supongas que un nonce hace segura una firma maliciosa.Cuando sea práctico, utiliza hardware wallets o multisig para saldos elevados.Revoca las aprobaciones de tokens innecesarias cuando corresponda.Ten cuidado al configurar nonces manualmente, salvo que entiendas el estado de las transacciones pendientes.

Cuándo es más importante la protección contra la repetición de nonces

Es especialmente importante cuando las firmas autorizan movimientos de valor.Es importante para las transacciones blockchain normales.Es importante para las aprobaciones permit.Es importante para las transferencias de tokens sin gas.Es importante para los mensajes de bridges.Es importante para los votos y delegaciones de gobernanza.Es importante para reclamar airdrops y recompensas.Es importante para los desafíos de inicio de sesión de wallets.Es importante para las transacciones multisig y las UserOperations de abstracción de cuentas.Es importante en cualquier situación en la que una firma copiada pueda causar efectos repetidos o no deseados.

Protección contra la repetición de nonces en una frase

La protección contra la repetición de nonces utiliza valores únicos, rastreados y vinculados al contexto para garantizar que una transacción, mensaje o autorización cripto firmada solo pueda ejecutarse una vez en la cadena, contrato y aplicación previstos.

Preguntas frecuentes

¿Qué significa la protección contra la repetición de nonces?

Significa impedir que una misma acción cripto firmada se acepte más de una vez mediante la comprobación y el consumo de un nonce único.

¿Qué es un nonce en cripto?

Es un número o valor único que se utiliza una sola vez en un contexto concreto para hacer que una transacción, mensaje o autorización sea único.

¿Qué es un ataque de repetición?

Es cuando alguien copia una acción firmada válida y vuelve a enviarla para repetir o utilizar indebidamente la autorización.

¿Cómo utiliza Ethereum los nonces?

Las cuentas de Ethereum utilizan un contador nonce para que solo pueda ejecutarse una transacción con un nonce determinado por cuenta.

¿Qué es la protección contra repeticiones mediante el ID de cadena?

Vincula una transacción o mensaje a una blockchain concreta para dificultar su reutilización en otra cadena.

¿EIP-712 detiene automáticamente los ataques de repetición?

No. EIP-712 estructura los datos firmados, pero las aplicaciones siguen necesitando comprobaciones de nonces, fechas límite y una separación de dominios correcta.

¿Por qué necesitan nonces los permits?

Los necesitan para impedir que se envíe repetidamente la misma aprobación de tokens firmada.

¿Qué diferencia hay entre un nonce y una fecha límite?

El nonce hace que una firma sea de un solo uso, mientras que la fecha límite restringe cuánto tiempo sigue siendo válida.

¿La protección contra repeticiones puede impedir el phishing?

No. Puede impedir usos repetidos, pero no el primer uso perjudicial si el usuario firma una autorización maliciosa.

¿Qué ocurre si se reutiliza un nonce?

Si la gestión funciona correctamente, el segundo uso debería fallar. Si el sistema está mal diseñado, la reutilización puede provocar problemas de repetición o fallos de transacción.

¿Por qué necesitan los contratos inteligentes sus propias comprobaciones de nonces?

Porque los nonces normales de cuenta no protegen automáticamente las firmas off-chain, permits, reclamaciones, votos o mensajes de bridges.

¿Cuál es el diseño de protección contra repeticiones más seguro?

El diseño más seguro combina nonces por firmante, ID de cadena, contrato verificador, detalles exactos de la acción, fecha límite, seguimiento del estado de uso y una validación cuidadosa de firmas.

Conclusión

La protección contra la repetición de nonces es uno de los cimientos discretos de la seguridad de las criptomonedas.Impide que una firma válida se convierta en un cheque en blanco reutilizable.Una firma blockchain demuestra que una clave privada autorizó un mensaje, pero no demuestra automáticamente que la autorización sea reciente, no se haya usado o esté limitada a una sola ejecución.El nonce aporta esa capa de vigencia.Si se comprueba y consume correctamente, la misma acción firmada no puede volver a ejecutarse.Esto protege transacciones normales, permits de tokens, transferencias sin gas, operaciones de cuentas inteligentes, aprobaciones multisig, mensajes de bridges, votos de gobernanza, desafíos de inicio de sesión, reclamaciones de recompensas y muchos otros flujos cripto.La protección moderna contra repeticiones es más que un contador.A menudo combina nonces de cuenta, nonces a nivel de contrato, ID de autorización aleatorios, ID de cadena, direcciones de contratos verificadores, fechas límite, periodos de validez, carriles de nonces y mapas de mensajes procesados.Cada capa resuelve un problema distinto de repetición.Los nonces de cuenta impiden repetir transacciones de una cuenta en la misma cadena.Los ID de cadena impiden copiar transacciones entre cadenas.Los nonces de contrato impiden reutilizar mensajes firmados dentro de las aplicaciones.Las fechas límite impiden que las firmas antiguas sigan siendo válidas indefinidamente.La separación de dominios impide que las firmas se desplacen al contrato o aplicación equivocados.Los carriles de nonces permiten flujos de trabajo paralelos en cuentas inteligentes sin perder la protección.Los riesgos son graves cuando faltan estos controles.Una firma que pueda repetirse puede vaciar fondos, repetir una aprobación, duplicar una reclamación, ejecutar dos veces un mensaje de bridge o distorsionar la gobernanza.Aunque exista protección mediante nonces, el phishing todavía puede perjudicar a los usuarios si firman una autorización maliciosa una sola vez.Por eso, la protección contra repeticiones debe combinarse con avisos claros en las wallets, firmas de alcance limitado, contratos bien diseñados y hábitos prudentes de los usuarios.Para los desarrolladores, la regla es sencilla.Toda firma capaz de mover valor o cambiar un estado importante necesita un nonce, un dominio y una regla clara para consumirla.Para las wallets, la regla es mostrar a los usuarios exactamente qué están autorizando antes de que firmen.Para los usuarios, la regla es tratar cada firma como una acción real, no como una confirmación inocua.La protección contra la repetición de nonces no hace que las criptomonedas estén libres de riesgo.Hace práctico el uso de autorizaciones firmadas al garantizar que una aprobación significa un uso previsto, en un contexto concreto, y no un número ilimitado de repeticiones futuras.