Protección contra ataques de repetición

¿Qué es la protección contra ataques de repetición en cripto?

La protección contra ataques de repetición es un método de seguridad que impide copiar y reutilizar una transacción, firma o autorización válida de criptomonedas en otro lugar en el que el usuario no tenía intención de que funcionara.

En los sistemas blockchain, esta protección es especialmente importante después de hard forks, divisiones de cadenas, implementaciones cross-chain, firmas de contratos inteligentes, procesos de abstracción de cuentas, uso de bridges y aprobaciones de wallets.

Se produce un ataque de repetición cuando un mensaje firmado es válido más de una vez de forma peligrosa.

Por ejemplo, un usuario puede firmar una transacción en una blockchain después de un fork, y un atacante podría copiar esa misma transacción a otra cadena si ambas siguen aceptando el mismo formato de firma.

La protección contra ataques de repetición añade información adicional o reglas de validación para que la firma solo sea válida en el contexto correcto.

La EIP-155 de Ethereum introdujo una protección sencilla contra los ataques de repetición al incluir el ID de cadena en los datos de la transacción firmada.

La especificación técnica UAHF de Bitcoin Cash describe la protección obligatoria contra ataques de repetición SIGHASH_FORKID para el diseño de su división de cadena.

Para los usuarios de criptomonedas, esta protección significa que una firma solo debería ejecutar lo que el usuario ha aprobado, en la red, el contrato, el activo y el contexto de transacción previstos.

Definición sencilla de la protección contra ataques de repetición

La protección contra ataques de repetición es una regla o característica de diseño que impide reutilizar una acción cripto firmada en el lugar equivocado o en el momento equivocado.

Hace que una transacción o firma sea única para una cadena, contrato, usuario, nonce, fecha límite o acción específicos.

Sin esta protección, una firma válida puede ser peligrosa porque la misma aprobación podría funcionar en otro lugar.

Con la protección activada, la firma copiada falla porque el segundo contexto no coincide con las condiciones originales de la firma.

Esto protege a los usuarios frente al doble gasto accidental entre cadenas bifurcadas.

También impide que los contratos inteligentes acepten de nuevo firmas antiguas.

Ayuda a wallets, bridges, aplicaciones DeFi y sistemas de pago a verificar que una autorización sea reciente y específica del contexto.

El objetivo es sencillo: una acción firmada no debería convertirse en un cheque en blanco ilimitado.

Por qué es importante la protección contra ataques de repetición

Esta protección es importante porque las firmas en blockchain tienen mucho poder.

Una firma puede transferir fondos, aprobar el gasto de tokens, reclamar recompensas, delegar poder de voto, actualizar ajustes de una cuenta o autorizar acciones de un contrato inteligente.

Si esa firma se puede copiar y reutilizar, el usuario puede perder activos sin tener que firmar una segunda vez.

Los ataques de repetición también pueden generar confusión después de un hard fork, ya que los usuarios pueden tener activos en ambas cadenas y no darse cuenta de que una transacción en una de ellas puede afectar a la otra.

Por tanto, la protección contra ataques de repetición es un elemento básico del diseño seguro de transacciones.

También es fundamental para diseñar wallets seguras, ya que los usuarios a menudo no pueden ver todos los campos técnicos de una firma.

La guía de FINRA sobre los riesgos de los criptoactivos advierte de que estos pueden conllevar fraude, volatilidad, problemas de liquidez y riesgos tecnológicos.

Los ataques de repetición son uno de esos riesgos tecnológicos, porque convierten una firma válida en una acción no deseada.

Cómo funciona un ataque de repetición

Un ataque de repetición comienza con una transacción o un mensaje firmado válido.

El atacante copia esos datos firmados.

A continuación, envía los mismos datos a otra cadena, contrato, sesión o contexto en el que la firma aún se considera válida.

Si el sistema no comprueba que el contexto sea el correcto, la acción copiada puede ejecutarse.

En un escenario de hard fork, esto puede ocurrir cuando dos cadenas comparten el mismo historial de cuentas, formato de transacción y reglas de firma.

En el caso de un contrato inteligente, puede suceder si el contrato acepta más de una vez la misma firma off-chain.

En un entorno cross-chain, puede ocurrir cuando la misma dirección de contrato, firmante y formato de mensaje existen en varias cadenas sin un dominio específico de cadena.

La protección contra ataques de repetición evita que esto ocurra al hacer que la firma copiada falle fuera del contexto previsto.

Protección contra ataques de repetición tras un hard fork

Un hard fork puede crear dos cadenas que comparten el mismo historial hasta el punto de división.

Después de la división, los usuarios pueden tener monedas o tokens en ambas cadenas porque se copió el estado del libro mayor anterior al fork.

Si ambas cadenas aceptan las mismas firmas de transacción, una transacción firmada para una de ellas también podría ser válida en la otra.

Esto genera riesgo de repetición.

Por ejemplo, un usuario puede intentar enviar monedas en la Cadena A, pero esa misma transacción firmada también podría transferir las monedas correspondientes en la Cadena B.

Una protección sólida modifica las reglas de firma para que las transacciones solo sean válidas en uno de los lados del fork.

Ethereum utilizó la lógica del ID de cadena de EIP-155 para impedir que una transacción destinada a una cadena también fuera válida en otra cadena con un ID distinto.

Bitcoin Cash utilizó una protección basada en SIGHASH_FORKID para diferenciar las transacciones posteriores al fork de las de la cadena original.

Protección contra ataques de repetición e ID de cadena

El ID de cadena es un número que identifica una red blockchain durante el proceso de firma de transacciones.

Cuando el ID de cadena se incluye en los datos firmados, la firma queda vinculada a esa cadena.

Esto significa que la misma transacción firmada no debería ser válida en otra cadena con un ID diferente.

EIP-155 es el ejemplo más conocido de protección contra ataques de repetición mediante el ID de cadena en el diseño de transacciones de Ethereum.

La EIP indica que este cambio permite enviar transacciones que funcionan en una red de tipo Ethereum, pero no en otra que tenga un ID de cadena diferente.

La protección mediante el ID de cadena es ahora una medida de seguridad estándar en muchos entornos compatibles con EVM.

Normalmente, los usuarios no tienen que introducir el ID de cadena manualmente, ya que las wallets y las bibliotecas se encargan de ello.

Aun así, los desarrolladores deben asegurarse de que su código de firma incluya el ID de cadena correcto y rechace los formatos antiguos no seguros cuando corresponda.

Protección contra ataques de repetición y nonces

Un nonce es un número que se utiliza una sola vez.

En las blockchains basadas en cuentas, los nonces suelen garantizar que las transacciones de una misma cuenta se ejecuten en orden y no puedan repetirse.

En los contratos inteligentes, un nonce puede hacer que cada autorización firmada sea única.

Si un contrato acepta una firma con el nonce 5, debería marcar ese nonce como utilizado.

Si alguien intenta enviar de nuevo la misma firma, el contrato debería rechazarla porque el nonce ya se ha consumido.

La protección basada en nonces es habitual en permisos, meta-transacciones, abstracción de cuentas, votaciones, reclamaciones, airdrops y sistemas de órdenes off-chain.

La ausencia de un nonce es una señal de alerta de seguridad importante, porque puede permitir que la misma firma se utilice más de una vez.

Un contrato bien diseñado hace que las firmas solo puedan utilizarse una vez, salvo que el diseño requiera claramente otra regla.

Protección contra ataques de repetición y fechas límite

Una fecha límite es el momento en que caduca un mensaje firmado o una autorización de transacción.

Las fechas límite reducen el riesgo de repetición al limitar el tiempo durante el que una firma sigue siendo válida.

Por ejemplo, un usuario puede firmar una aprobación de tokens o una autorización de swap que caduque en 10 minutos.

Si un atacante encuentra la firma más tarde, el contrato la rechazará porque habrá vencido la fecha límite.

Las fechas límite no sustituyen por completo a los nonces, ya que una firma podría reproducirse antes de caducar si no se utiliza un nonce.

El mejor diseño suele combinar un nonce y una fecha límite.

Así, la firma solo puede utilizarse una vez y tiene un periodo de validez limitado.

Los usuarios deben tener cuidado si una wallet les pide firmar mensajes sin una fecha de caducidad visible o con un alcance ilimitado.

Protección contra ataques de repetición y EIP-712

EIP-712 es un estándar para firmar datos estructurados y tipados en sistemas de tipo Ethereum.

Ayuda a las wallets a mostrar información de firma más legible y permite a los desarrolladores definir con precisión qué autoriza el usuario.

La documentación de criptografía de OpenZeppelin incluye utilidades EIP712 para procesar datos tipados firmados.

La documentación anterior de las utilidades de OpenZeppelin explica que el separador de dominio de EIP-712 actualiza el ID de cadena para proteger contra ataques de repetición en un posible fork futuro.

El dominio EIP-712 puede incluir detalles como el nombre, la versión, el ID de cadena y el contrato verificador.

Estos campos vinculan la firma a un contexto de aplicación concreto.

Si un contrato malicioso intenta reutilizar la firma en otro lugar, el dominio no debería coincidir.

Los desarrolladores deben incluir los campos de dominio correctos y evitar mensajes genéricos que puedan reutilizarse fácilmente.

Protección contra ataques de repetición y contratos inteligentes

Los contratos inteligentes suelen aceptar firmas creadas off-chain y enviadas más tarde on-chain.

Esto resulta eficiente porque los usuarios pueden aprobar una acción sin enviar inmediatamente una transacción por su cuenta.

Sin embargo, genera riesgo de repetición si el contrato no comprueba los nonces, las fechas límite, el ID de cadena, el firmante, la dirección del contrato y los detalles de la acción.

Un contrato seguro debe verificar que la firma corresponda exactamente a la acción que se está ejecutando.

También debe marcar las firmas o los nonces utilizados para que no se puedan volver a usar.

La protección es especialmente importante para permisos de tokens, votaciones delegadas, órdenes off-chain, transacciones sin gas, reclamaciones, acuñaciones con whitelist, retiradas de bridges y procesos de recuperación de cuentas.

Todo contrato que solicite «enviar un mensaje firmado» debería revisarse para comprobar que incluya protección contra ataques de repetición.

La falta de una comprobación puede convertir una aprobación en transferencias repetidas de activos.

Protección contra ataques de repetición y permisos de tokens

Un permiso de token permite al usuario aprobar el gasto de tokens firmando un mensaje en lugar de enviar una transacción de aprobación normal.

Esto puede ahorrar tiempo y comisiones de red.

También puede mejorar la experiencia de usuario en las aplicaciones DeFi.

Sin embargo, los permisos deben incorporar protección contra ataques de repetición, ya que el permiso firmado puede permitir que otra dirección gaste tokens.

Un diseño seguro de permisos suele incluir información sobre el titular, el autorizado a gastar, el valor, el nonce, la fecha límite, el ID de cadena y el contrato verificador.

El nonce impide volver a utilizar el mismo permiso.

La fecha límite limita el periodo de validez.

Los datos de la cadena y del contrato impiden que se utilice en un dominio incorrecto.

Protección contra ataques de repetición y meta-transacciones

Una meta-transacción permite al usuario firmar una acción mientras otra parte la envía y paga la comisión de gas.

Esto puede facilitar el uso de aplicaciones blockchain a quienes no tienen el token nativo necesario para pagar el gas.

Las meta-transacciones son sensibles a los ataques de repetición porque el mensaje firmado puede pasar entre relayers, aplicaciones o contratos.

Un buen sistema de meta-transacciones utiliza nonces, IDs de cadena, direcciones de contratos verificadores, fechas límite y campos de acción claros.

El contrato debería rechazar las firmas de meta-transacciones antiguas o ya utilizadas.

El relayer también debería evitar procesar dos veces la misma solicitud firmada.

Los usuarios deben revisar la acción exacta antes de firmar, ya que una meta-transacción puede transferir activos o cambiar permisos.

Que una transacción no requiera gas no significa que esté libre de riesgos.

Protección contra ataques de repetición y bridges

Los bridges transfieren valor o mensajes entre cadenas.

La protección contra ataques de repetición es importante porque un mensaje de un bridge puede representar un depósito, una retirada, una acuñación, una quema, un desbloqueo o una llamada cross-chain.

Si un mensaje del bridge se puede reproducir, el sistema podría liberar o acuñar activos más de una vez.

Un bridge seguro suele comprobar la cadena de origen, la cadena de destino, el ID del mensaje, el nonce, el emisor, el destinatario, el token, la cantidad y el estado de la prueba.

Debe marcar los mensajes procesados para impedir que se ejecuten otra vez.

La protección también es importante cuando el mismo contrato se despliega en la misma dirección en varias cadenas.

Los desarrolladores deben asegurarse de que un mensaje destinado a una cadena no pueda ser aceptado por un contrato similar en otra cadena.

Los errores de protección contra ataques de repetición en bridges pueden ser graves, ya que los sistemas cross-chain suelen gestionar grandes cantidades de valor.

Protección contra ataques de repetición y wallets

Las wallets son la primera línea de defensa del usuario frente al riesgo de repetición.

Una buena wallet muestra la red, el contrato, el token, la cantidad, el autorizado a gastar, la fecha límite y el tipo de mensaje antes de que el usuario firme.

También debería advertir al usuario cuando una firma parezca amplia, ilimitada o difícil de entender.

Las wallets deben firmar transacciones con el ID de cadena correcto y utilizar estándares de firma modernos.

No deberían firmar silenciosamente transacciones con formatos antiguos que carezcan de protección contra ataques de repetición cuando haya formatos más seguros disponibles.

Los usuarios deben evitar firmar mensajes en sitios web desconocidos, ya que el mensaje podría reutilizarse de una forma que no entiendan.

También deben comprobar que están conectados a la red correcta antes de firmar.

Una interfaz de wallet segura puede reducir el riesgo de repetición, pero no puede proteger a los usuarios que aprueban solicitudes poco claras o maliciosas sin revisarlas.

Protección contra ataques de repetición y divisiones de cadenas

Una división de cadena es uno de los ejemplos más habituales de la necesidad de protección contra ataques de repetición.

Durante una división, dos cadenas pueden compartir las mismas direcciones, saldos e historial de transacciones previos a la separación.

Si la protección no está integrada en el fork, es posible que los usuarios tengan que seguir pasos especiales para separar los fondos de forma segura.

Estos pasos pueden consistir en esperar, utilizar wallets compatibles con la división, enviar fondos mediante transacciones específicas de cada cadena o recurrir a herramientas de separación de fuentes fiables.

Los usuarios deben tener cuidado, ya que durante los forks suelen aparecer estafadores que ofrecen ayuda para separar monedas.

La protección contra ataques de repetición a nivel de protocolo es más segura que obligar a cada usuario a protegerse manualmente.

Los forks con una protección poco clara pueden confundir a los usuarios minoristas y a las plataformas.

Antes de mover fondos después de un fork, los usuarios deben consultar la información técnica oficial de los desarrolladores de la cadena y de los proveedores de wallets.

Protección sólida frente a protección débil contra ataques de repetición

Una protección sólida significa que, por diseño, una transacción válida en una cadena no es válida en la otra.

Normalmente, esto requiere modificar las reglas de firma, las reglas sighash, los IDs de cadena o el formato de las transacciones.

Una protección débil significa que los usuarios pueden hacer que las transacciones no se puedan reproducir siguiendo pasos adicionales, pero la protección no se aplica automáticamente a todas las transacciones.

La protección sólida es más sencilla para los usuarios corrientes porque reduce el gasto accidental de fondos en varias cadenas.

La protección débil puede ser arriesgada porque los usuarios deben entender pasos técnicos y plazos.

En una división de cadena, suele preferirse una protección sólida porque hace que el fork sea más seguro.

Los desarrolladores no deben dar por sentado que los usuarios se protegerán manualmente de forma correcta.

Una protección predeterminada y clara es mejor que una protección opcional y complicada.

Protección contra ataques de repetición opcional

La protección opcional significa que el usuario o la wallet debe elegir un método de transacción especial para evitar el riesgo de repetición.

Puede funcionar para usuarios avanzados, pero es peligrosa para los principiantes.

Si el usuario olvida activarla, la transacción podría seguir siendo reproducible.

Los sistemas opcionales también generan un comportamiento incoherente entre wallets y servicios.

Algunos usuarios pueden creer que están protegidos cuando su wallet en realidad no utiliza el formato protector.

Las comunidades de cadenas bifurcadas a veces recurren a esta protección opcional cuando no se ha incluido una protección completa a nivel de protocolo.

Los usuarios minoristas deben tener cuidado con cualquier fork que requiera activar manualmente la protección contra ataques de repetición.

En caso de duda, deben esperar a recibir indicaciones de una wallet fiable antes de mover fondos.

Protección contra ataques de repetición a nivel de protocolo

La protección a nivel de protocolo está integrada en las reglas de la blockchain.

No depende de que cada usuario recuerde seguir un paso especial.

La EIP-155 de Ethereum es un ejemplo de protección a nivel de protocolo que utiliza IDs de cadena en las transacciones firmadas.

El enfoque SIGHASH_FORKID de Bitcoin Cash es otro ejemplo de protección específica para forks.

La protección a nivel de protocolo es eficaz porque hace que las transacciones en un contexto no válido fallen automáticamente.

También facilita el análisis del comportamiento de wallets, nodos y servicios.

Sin embargo, debe implementarse con cuidado, ya que los cambios en las firmas pueden afectar a la compatibilidad.

Los desarrolladores deben probar esta protección antes de que un fork o una actualización llegue a los usuarios.

Protección contra ataques de repetición a nivel de aplicación

La protección a nivel de aplicación se implementa en un contrato inteligente, una wallet, un bridge o una aplicación, en lugar de en la cadena base.

Algunos ejemplos son los nonces de contrato, los hashes de mensajes utilizados, los ID de órdenes, las fechas límite, los separadores de dominio y los registros de retiradas procesadas.

Esta protección es necesaria porque muchos riesgos de repetición se producen por encima de la capa base de la blockchain.

Una cadena base puede incluir un ID de cadena y, aun así, un contrato inteligente mal programado puede aceptar dos veces la misma firma.

Los desarrolladores deben diseñar protección contra ataques de repetición en cada capa que acepte firmas o mensajes.

Los auditores deben comprobar si otro usuario, contrato, cadena o momento pueden reutilizar una firma del mismo usuario.

Los usuarios deben tener cuidado con las aplicaciones que solicitan repetidamente firmas off-chain sin una explicación clara.

La buena seguridad se construye por capas porque el riesgo de repetición también existe en varias capas.

Protección contra ataques de repetición y dominios de firma

Un dominio de firma define dónde es válida una firma.

Un dominio bien diseñado puede incluir el ID de cadena, la dirección del contrato, el nombre de la aplicación, la versión y la finalidad.

Esto impide que una firma para una aplicación se reutilice en otra.

También impide reutilizar la firma de una versión del sistema después de una actualización importante, si cambia la versión.

La separación de dominios de EIP-712 es una de las formas más habituales de implementar esta idea en aplicaciones de tipo Ethereum.

Es importante separar los dominios porque los usuarios suelen firmar mensajes que no se registran inmediatamente on-chain.

Si el dominio es demasiado genérico, la firma podría ser peligrosa en más contextos de los previstos.

Los desarrolladores nunca deberían recurrir a un mensaje de texto sin formato cuando sea posible firmar datos estructurados y específicos del dominio.

Protección contra ataques de repetición y hashes de transacción

El hash de una transacción identifica una transacción concreta después de firmarla y enviarla.

Los hashes de transacción pueden ayudar a usuarios y servicios a comprobar si una transacción ya se ha procesado.

Sin embargo, por sí solo, un hash de transacción no siempre basta para proteger contra ataques de repetición en diferentes contextos.

Cuando corresponda, el sistema también debería comprobar el ID de cadena, el nonce, la cuenta, el contrato, el ID del mensaje y el estado final.

En el caso de bridges y procesadores de pagos, registrar los hashes de las transacciones procesadas puede evitar que se complete dos veces la misma solicitud.

En los contratos inteligentes, registrar los hashes de los mensajes utilizados puede impedir que una firma se ejecute dos veces.

El método exacto de seguimiento depende del diseño del sistema.

La regla fundamental es que cada autorización debe tener una identidad única que no pueda reutilizarse por accidente.

Protección contra ataques de repetición y maleabilidad de firmas

La maleabilidad de firmas es un problema distinto de la protección contra ataques de repetición, aunque ambos pueden interactuar.

La maleabilidad de firmas significa que una firma válida puede transformarse en otra forma también válida.

Si un sistema solo registra una forma de la firma, un atacante podría enviar una versión modificada.

Los sistemas de contratos inteligentes bien diseñados deben utilizar bibliotecas seguras de verificación de firmas y normalizar o rechazar formatos de firma no seguros.

Los desarrolladores utilizan ampliamente las herramientas de criptografía de OpenZeppelin para verificar firmas y datos tipados de forma segura.

La protección contra ataques de repetición debe combinarse con una validación correcta de las firmas.

Un nonce o un separador de dominio no bastan si la lógica de verificación de la firma presenta fallos.

La seguridad depende tanto del diseño del mensaje como de la implementación criptográfica.

Protección contra ataques de repetición y abstracción de cuentas

La abstracción de cuentas permite que las wallets y las cuentas funcionen más como contratos inteligentes programables.

Esto puede habilitar recuperación social, acciones por lotes, patrocinio del gas, límites de gasto y claves de sesión.

También genera nuevas necesidades de protección contra ataques de repetición, ya que la autorización puede implicar operaciones de usuario, paymasters, bundlers, puntos de entrada y lógica de cuentas inteligentes.

Una cuenta inteligente debe comprobar cuidadosamente los nonces y los dominios.

Siempre que sea posible, las claves de sesión deben limitarse por cadena, contrato, token, cantidad, función, fecha límite y política.

Una autorización de sesión reutilizable puede ser peligrosa si se acepta fuera de los límites previstos.

La abstracción de cuentas hace que las wallets sean más flexibles, pero también complica la protección contra ataques de repetición.

Los usuarios deben tener presente que las wallets programables también requieren revisar cuidadosamente las firmas.

Protección contra ataques de repetición y aplicaciones cross-chain

Las aplicaciones cross-chain funcionan en más de una blockchain.

A menudo utilizan contratos, direcciones, interfaces y formatos de mensaje similares en distintas cadenas.

Esta similitud puede aumentar el riesgo de repetición si los mensajes no especifican claramente la cadena.

Una firma para un contrato de la Cadena A no debería funcionar automáticamente en un contrato aparentemente idéntico de la Cadena B.

Las aplicaciones cross-chain deben incluir en los mensajes firmados el ID de la cadena de origen y el de la cadena de destino.

También deben incluir las direcciones de los contratos verificadores y los nonces de los mensajes.

Los usuarios deben comprobar qué red está activa antes de firmar cualquier acción cross-chain.

Una aplicación cross-chain con una protección deficiente puede convertir la comodidad en un riesgo de seguridad grave.

Protección contra ataques de repetición y órdenes DeFi

Las órdenes DeFi pueden crearse off-chain y ejecutarse on-chain.

Por ejemplo, un usuario puede firmar una orden que permita realizar un swap cuando se cumplan determinadas condiciones.

La protección contra ataques de repetición es esencial para que la misma orden no se ejecute más veces de las previstas.

Una orden segura incluye la dirección del Maker, las reglas del Taker, las direcciones de los tokens, las cantidades, la fecha límite, el nonce, el ID de cadena y el contrato verificador.

El contrato debe marcar las órdenes ejecutadas o canceladas para impedir que se reutilicen.

Si se permiten ejecuciones parciales, el contrato debe registrar qué cantidad se ha ejecutado ya.

Los errores de repetición de órdenes pueden agotar la liquidez o ejecutar operaciones obsoletas a precios desfavorables.

Los usuarios minoristas deben tener cuidado al firmar órdenes off-chain cuyo contenido no puedan leer claramente.

Protección contra ataques de repetición y firmas NFT

Los marketplaces de NFT y las aplicaciones de acuñación suelen utilizar firmas para listados, ofertas, listas de permitidos y reclamaciones.

La protección contra ataques de repetición impide que un listado o una reclamación de NFT firmados se reutilicen de forma inesperada.

Una firma NFT segura debería incluir, cuando corresponda, la dirección de la colección, el ID del token, el precio, la moneda, el vendedor, las condiciones del comprador, el nonce, la fecha límite, el ID de cadena y el contrato del marketplace.

Si se cancela un listado, el sistema debe invalidar la firma anterior.

Si un NFT se transfiere a otra wallet, las aprobaciones o firmas antiguas pueden seguir creando riesgos, según el diseño del marketplace.

Los usuarios deben revocar las aprobaciones antiguas y evitar firmar mensajes NFT que no entiendan.

El riesgo de repetición de NFT es especialmente grave porque los usuarios suelen firmar mensajes de marketplaces sin comprender todos los detalles de la orden.

Una presentación clara en la wallet es fundamental para la seguridad de los NFT.

Protección contra ataques de repetición y aprobaciones de wallets

Las aprobaciones de tokens permiten que un contrato gaste tokens de una wallet.

No siempre son lo mismo que los mensajes firmados, pero generan preocupaciones similares sobre los riesgos para el usuario, ya que pueden seguir siendo válidas con el tiempo.

Una aplicación maliciosa puede engañar a un usuario para que apruebe el gasto ilimitado de tokens.

La protección contra ataques de repetición no puede corregir una aprobación ilimitada intencionada después de que se haya confirmado on-chain.

Sin embargo, las aprobaciones de tipo permit sí necesitan protección para impedir que el permiso firmado se utilice repetidamente.

Siempre que sea posible, los usuarios deberían optar por aprobaciones limitadas.

También deberían revisar y revocar periódicamente las aprobaciones antiguas.

Revisar las aprobaciones forma parte de una buena gestión del riesgo de repetición, ya que ambas prácticas limitan lo que una autorización anterior puede hacer más adelante.

Protección contra ataques de repetición y sistemas de pago

Los sistemas de pago cripto necesitan protección contra ataques de repetición para evitar completar dos veces una misma operación.

Un comerciante no debería enviar dos veces un producto porque se haya presentado dos veces la misma prueba de pago.

Un procesador de pagos debería registrar los hashes de las transacciones, los IDs de cadena, los ID de pago, los ID de factura, las cantidades, los activos y el estado de liquidación final.

Si los pagos se autorizan mediante firmas, estas deberían incluir un ID único de factura u orden.

También deberían incluir una fecha de caducidad y los detalles del pago.

La protección contra ataques de repetición en los pagos protege tanto al pagador como al comerciante.

Sin ella, las reclamaciones duplicadas, la entrega duplicada o las solicitudes repetidas de liquidación pueden generar pérdidas contables.

Un buen diseño de pagos trata cada autorización como específica para una única finalidad y verificable.

Protección contra ataques de repetición y experiencia de usuario

La protección contra ataques de repetición no debería ocultarse por completo a los usuarios.

No es necesario que lean campos criptográficos sin procesar, pero sí deben ver claramente qué están firmando.

Una wallet debería mostrar la red, el nombre de la aplicación, el contrato, la acción, el token, la cantidad, el autorizado a gastar, la fecha límite y las señales de alerta.

Si un mensaje no es legible, los usuarios deben tratarlo con precaución.

Una mala experiencia de usuario puede neutralizar una criptografía sólida, porque los usuarios podrían aprobar acciones peligrosas sin entenderlas.

Una buena protección combina salvaguardas técnicas con solicitudes de firma legibles en la wallet.

Los desarrolladores deben diseñar procesos de firma que los usuarios puedan verificar antes de aprobar.

Una firma es más segura cuando el usuario entiende su alcance.

Protección contra ataques de repetición y desarrolladores

Los desarrolladores deben tratar esta protección como un requisito básico de seguridad.

Todo mensaje firmado debería responder a varias preguntas.

¿En qué cadena es válido?

¿Qué contrato puede verificarlo?

¿Qué usuario lo ha firmado?

¿Qué acción autoriza?

¿Cuántas veces puede utilizarse?

¿Cuándo caduca?

Si las respuestas no están claras, es probable que la protección contra ataques de repetición esté incompleta.

Protección contra ataques de repetición y auditorías

Las auditorías de seguridad deberían incluir pruebas de ataques de repetición.

Los auditores deberían intentar reutilizar firmas en el mismo contrato.

También deberían probar a reutilizarlas en otro contrato.

Deberían probar a reutilizarlas en otra cadena.

Asimismo, deberían intentar reutilizar firmas antiguas después de una cancelación, actualización, caducidad o transferencia de titularidad.

Deberían probar el ID de cadena, el separador de dominio, la gestión de nonces y fechas límite, y la unicidad del hash del mensaje.

Los errores de repetición pueden ser sutiles porque el primer uso de una firma puede parecer correcto.

El peligro aparece cuando la misma autorización vuelve a funcionar.

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

La primera ventaja es que evita el gasto accidental entre cadenas después de un fork.

La segunda es que impide reutilizar firmas antiguas sin permiso.

La tercera es que protege los contratos inteligentes frente a autorizaciones duplicadas.

La cuarta es que hace más seguros los mensajes cross-chain.

La quinta es que mejora la confianza en wallets y aplicaciones.

La sexta es que ayuda a los sistemas de pago a evitar completar dos veces una operación.

La séptima es que reduce los daños causados por la copia de datos de transacciones.

La protección contra ataques de repetición hace que las firmas cripto sean más seguras al vincularlas a un contexto concreto.

Limitaciones de la protección contra ataques de repetición

La primera limitación es que no detiene todos los tipos de ataque.

No protege a los usuarios que firman una transacción maliciosa válida en la cadena prevista.

No corrige las aprobaciones ilimitadas de tokens que ya se han confirmado.

No protege una frase de recuperación frente al robo.

No garantiza que un contrato inteligente esté libre de otros errores.

No elimina el riesgo de phishing si los usuarios aprueban solicitudes engañosas en la wallet.

Tampoco elimina el riesgo de mercado, de liquidez o de plataforma.

La protección contra ataques de repetición es esencial, pero solo constituye una capa de la seguridad cripto.

Errores habituales en la protección contra ataques de repetición

Un error habitual es olvidar incluir el ID de cadena en los datos de transacciones o mensajes firmados.

Otro error es utilizar un nonce sin marcarlo como utilizado.

También lo es utilizar una fecha límite, pero no un nonce.

Otro error es utilizar el mismo separador de dominio en varios contratos o cadenas.

También es un error aceptar firmas después de actualizar un contrato sin controlar las versiones.

Otro es permitir que se sigan ejecutando órdenes canceladas.

También lo es registrar los mensajes procesados únicamente en sistemas off-chain, sin hacerlo on-chain cuando sea necesario.

Por último, es un error dar por sentado que la interfaz de una wallet resolverá los fallos de protección contra ataques de repetición a nivel de contrato.

Señales de alerta sobre la protección contra ataques de repetición

Es una señal de alerta que un fork no explique claramente si la protección es sólida, débil o inexistente.

También lo es que un contrato inteligente acepte firmas sin nonces.

Otra señal es una solicitud de firma que no muestre la cadena, el contrato, la cantidad, la fecha límite o los detalles de la acción.

También lo es que un bridge no registre los mensajes procesados.

Otra señal es un sistema de órdenes off-chain que no permita cancelarlas ni invalidar sus nonces.

También lo es que una wallet o biblioteca siga creando transacciones antiguas sin protección moderna contra ataques de repetición.

Otra señal de alerta es que una dApp pida a los usuarios firmar mensajes ilegibles para conceder permisos amplios.

También lo es asumir que una cadena clonada es segura solo porque los saldos aparecen con normalidad después de un fork.

Buenas prácticas para los usuarios

Utiliza wallets compatibles con formatos de transacción modernos y solicitudes de firma claras.

Comprueba la red antes de firmar cualquier transacción o mensaje.

No firmes mensajes de sitios web desconocidos.

Ten cuidado después de los forks y espera a recibir instrucciones oficiales de la wallet antes de mover fondos.

Evita las aprobaciones ilimitadas cuando haya aprobaciones limitadas disponibles.

Revisa y revoca las aprobaciones antiguas de tokens cuando ya no sean necesarias.

No confíes en herramientas para separar fondos de un fork salvo que procedan de fuentes fiables y verificadas.

Considera peligrosas las solicitudes de firma ilegibles o inusualmente amplias.

Buenas prácticas para los desarrolladores

Incluye el ID de cadena en los dominios de transacciones y mensajes firmados.

Incluye la dirección del contrato verificador en las firmas de datos tipados.

Utiliza nonces y márcalos como consumidos.

Utiliza fechas límite para las autorizaciones que dependan del tiempo.

Incluye detalles exactos de la acción, como el token, la cantidad, el autorizado a gastar, el destinatario, el ID de orden y la finalidad de la función.

Cuando sea necesario, registra on-chain los mensajes cross-chain procesados.

Utiliza bibliotecas de criptografía auditadas en lugar de crear tu propio código de verificación de firmas.

Antes del lanzamiento, prueba los intentos de repetición entre cadenas, contratos, actualizaciones y ejecuciones repetidas.

Por qué la protección contra ataques de repetición es importante para AEO y la intención de búsqueda

Los usuarios buscan información sobre la protección contra ataques de repetición porque quieren saber cómo impiden los sistemas cripto que se reutilicen transacciones copiadas.

La respuesta directa es que esta protección hace que una firma solo sea válida para la cadena, el contrato, el nonce, la fecha límite y la acción previstos.

También buscan información sobre esta protección para entender la seguridad de los hard forks.

En la práctica, una protección sólida impide que una transacción de una cadena bifurcada también transfiera activos en la otra.

Es posible que también busquen información porque les preocupan las firmas de wallets.

La respuesta útil es que las wallets y los contratos inteligentes deben utilizar IDs de cadena, separación de dominios, nonces, fechas límite y datos de firma claros para impedir que se reutilicen las firmas.

La lección fundamental para los usuarios de criptomonedas es sencilla.

La protección contra ataques de repetición impide que una aprobación firmada se convierta en una acción repetida o cross-chain no deseada.

Preguntas frecuentes

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

Es un método de seguridad que impide reutilizar una transacción o firma válida de criptomonedas en un contexto no previsto.

¿Qué es un ataque de repetición?

Se produce cuando alguien copia una transacción o un mensaje firmado válido y lo envía de nuevo en un contexto en el que no debería ser válido.

¿Por qué es importante esta protección después de un fork?

Es importante porque dos cadenas bifurcadas pueden compartir el mismo historial y las mismas reglas de firma, lo que puede hacer que una transacción sea válida en ambas si no existe protección.

¿Qué es EIP-155?

EIP-155 es una propuesta de mejora de Ethereum que añadió una protección sencilla contra ataques de repetición al incluir el ID de cadena en los datos de las transacciones firmadas.

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

Vincula una firma a una red blockchain para que no se pueda copiar a otra red con un ID de cadena diferente.

¿Qué es SIGHASH_FORKID?

SIGHASH_FORKID es un mecanismo de firma específico de un fork que utiliza Bitcoin Cash para diferenciar las transacciones posteriores al fork y reducir el riesgo de repetición.

¿Pueden sufrir ataques de repetición los contratos inteligentes?

Sí. Un contrato inteligente puede sufrirlos si acepta la misma firma más de una vez o acepta una firma en un contexto incorrecto.

¿Cómo impiden los nonces los ataques de repetición?

Los nonces hacen que cada autorización sea única y permiten que el contrato o la cadena rechace una acción firmada que ya se haya utilizado.

¿Cómo ayudan las fechas límite a proteger contra ataques de repetición?

Hacen que las firmas caduquen después de un periodo determinado y reducen el intervalo en el que pueden utilizarse indebidamente.

¿La protección contra ataques de repetición detiene el phishing?

No. No detiene el phishing si el usuario firma una acción maliciosa que es válida en el contexto previsto.

¿Puede sufrir ataques de repetición un bridge?

Sí. Los bridges pueden sufrirlos si los mensajes cross-chain se procesan más de una vez o se aceptan en la cadena equivocada.

¿Qué deben comprobar los usuarios antes de firmar?

Deben comprobar la red, la aplicación, el contrato, el token, la cantidad, el autorizado a gastar, la fecha límite y el significado del mensaje.

¿Cuál es el mayor error en la protección contra ataques de repetición?

Permitir que una firma sea válida sin un nonce único, un dominio específico de cadena o un límite claro de ejecución.

Conclusión

La protección contra ataques de repetición es un concepto fundamental de seguridad cripto que impide reutilizar transacciones y mensajes firmados en contextos a los que no pertenecen.

Es especialmente importante durante hard forks, divisiones de cadenas, transacciones cross-chain, firmas de contratos inteligentes, aprobaciones de wallets, uso de bridges, permisos, meta-transacciones y órdenes DeFi.

Una protección sólida utiliza herramientas como IDs de cadena, reglas de firma específicas para forks, nonces, fechas límite, separadores de dominio, direcciones de contratos verificadores y registros de mensajes procesados.

EIP-155 es un ejemplo destacado de protección basada en el ID de cadena en sistemas de tipo Ethereum.

SIGHASH_FORKID es un ejemplo destacado de protección específica para forks en el diseño de transacciones de tipo Bitcoin Cash.

La protección contra ataques de repetición no elimina todos los riesgos cripto, pero evita uno de los problemas de firma más peligrosos: que se copie y reutilice una aprobación válida sin que el usuario lo haya previsto.

Los usuarios deben utilizar wallets modernas, evitar firmas poco claras y tener cuidado después de los forks o al utilizar aplicaciones cross-chain.

La conclusión práctica es sencilla: la protección contra ataques de repetición hace que las firmas cripto sean más seguras al garantizar que una acción firmada solo funcione en el contexto exacto que el usuario pretendía.