En el mundo de la cadena de bloques, los usuarios a menudo necesitan otorgar permisos (autorizaciones) que permitan a los contratos inteligentes gastar tokens en su nombre. Por ejemplo, al usar un intercambio descentralizado (DEX) para intercambiar tokens, un usuario debe primero autorizar el contrato de intercambio para transferir una cantidad específica de tokens desde su billetera. Bajo el enfoque tradicional ERC-20según el estándar, este proceso requiere dos transacciones separadas en cadena: una para la aprobación y otra para la transferencia real del token. Este proceso de dos pasos no solo es engorroso, sino que también conlleva tarifas adicionales de gas. Para mejorar tanto la experiencia del usuario como la seguridad, la comunidad de Ethereum introdujo un mecanismo de autorización basado en firmas,Permiso(como EIP-2612), y posteriormente desarrolló una versión avanzada llamada Permit2. Estos nuevos mecanismos permiten a los usuarios otorgar aprobaciones de tokens a través de firmas fuera de la cadena, evitando la necesidad de transacciones adicionales en cadena.

En este artículo, comenzaremos con lo básico explicando cómo funcionan las aprobaciones tradicionales ERC-20 y sus limitaciones. Luego, nos sumergiremos en cómo funcionan Permit y Permit2, destacaremos sus beneficios y compensaciones, y discutiremos cómo mejoran tanto la eficiencia como la seguridad. También examinaremos posibles riesgos de seguridad, especialmente ataques de phishing que involucran firmas maliciosas, y ofrecer consejos para mantenerse seguro. Ya sea que seas nuevo en la cadena de bloques o recién estés comenzando tu viaje de inversión en criptomonedas, esta guía tiene como objetivo ayudarte a comprender estas importantes innovaciones técnicas.

Fundamentos del Modelo de Autorización ERC-20

Antes de sumergirnos en Permit, primero veamos cómo funciona el modelo de autorización tradicional de tokens ERC-20 y las limitaciones que presenta.

Cómo funcionan las aprobaciones tradicionales de ERC-20

ERC-20 es el estándar para tokens en Ethereum. Define funciones como approve y transferFrom, que juntas permiten la autorización de tokens. La autorización aquí significa que un titular de tokens (el propietario) permite a otra cuenta, típicamente un contrato inteligente (el gastador), transferir una cierta cantidad de tokens en su nombre. El proceso básico funciona así:

1. El titular del token llama a la función approve(spender, amount) del contrato de token. Esto registra la asignación en el mapeo interno del contrato, generalmente expresado como allowance[owner][spender] = amount. Por ejemplo, si el usuario A autoriza al contrato Uniswap a gastar hasta 100 tokens, el contrato almacenará allowance[A][Uniswap] = 100. Este paso requiere una transacción en cadena y tarifas de gas pagadas por A.
2. DeleGate.iod Transfer (transferFrom): Más tarde, cuando Uniswap (u otra dApp) necesite gastar tokens en nombre de A, llama a transferFrom(A, B, cantidad) en el contrato de token. El contrato verifica si la asignación[A][Uniswap] es suficiente. Si lo es, el contrato transfiere la cantidad especificada de A a B y deduce esa cantidad de la asignación.

Limitaciones y Desafíos del Modelo de Aprobación

El modelo de dos pasos anterior permite a los usuarios autorizar contratos para gestionar sus fondos, sin necesidad de compartir nunca sus claves privadas. Sin embargo, este enfoque tradicional también conlleva varios problemas prácticos:

Se requieren dos transacciones, mala experiencia del usuario
Cada vez que un usuario quiera usar un nuevo token en una dApp, primero debe enviar una transacción de aprobación separada antes de poder realizar la acción deseada (como intercambiar o apostar). Esto significa que su billetera les pedirá confirmación dos veces y cobrará tarifas adicionales de Gas. Para principiantes, este paso adicional puede ser confuso e inconveniente.

Gestión fragmentada de aprobaciones
Cuando los usuarios interactúan con múltiples dAppsusando el mismo token (por ejemplo, comerciando en Uniswap y luego depositando en un protocolo DeFi diferente), cada dApp requiere una aprobación separada, aunque sea el mismo token en la misma billetera. Esto conduce a aprobaciones repetitivas, desperdiciando tiempo y gas.

Además, dado que cada dApp gestiona sus propias asignaciones de forma independiente, los usuarios tienen poco control centralizado sobre sus aprobaciones. Algunas herramientas, como Revoke.cash yDeBank, permiten a los usuarios ver y gestionar las asignaciones de tokens, pero muchos usuarios no son conscientes de ellas. Y incluso si lo son, revocar los permisos aún requiere una transacción en cadena, lo que añade costes. Como resultado, muchas aprobaciones antiguas o no utilizadas simplemente se olvidan.

Los riesgos de aprobaciones ilimitadas
Para evitar transacciones de aprobación frecuentes, muchas dApps sugieren a los usuarios otorgar aprobación ilimitada, permitiendo que el contrato gaste el saldo completo de tokens del usuario, sin fecha de vencimiento. Aunque este enfoque ahorra esfuerzo más adelante, introduce riesgos de seguridad graves: si la dApp o el contrato se ven comprometidos, un atacante podría vaciar todos los tokens aprobados.

Estos desafíos han llevado a los desarrolladores a buscar mejores alternativas. Idealmente, los usuarios solo deberían tener que firmar una vez (preferiblemente fuera de la cadena y sin costos de gas) para completar tanto la aprobación como la acción. La aprobación también debería estar limitada en alcance y duración para minimizar los riesgos potenciales. Esta es la motivación detrás de la introducción de ERC-20 Permit.

Permiso: Autorización basada en firma ERC-20 (EIP-2612)

El concepto de Permiso fue introducido por primera vez por elDAIcontrato de stablecoin y más tarde estandarizado como EIP-2612. En resumen, Permit permite a los usuarios autorizar transferencias de tokens utilizando firmas fuera de la cadena, eliminando la necesidad de enviar una transacción de aprobación en cadena separada. Veamos más de cerca cómo funciona y sus características distintivas.

Cómo funciona el Permiso

El permiso es un mecanismo de autorización basado en firmas digitales. Bajo el estándar EIP-2612, los contratos de token ERC-20 que admiten Permit agregan una función llamada permit() que se ve así:

función permitir(
propietario de la dirección, usuario de la dirección,
valor uint256, fecha límite uint256,
uint8 v, bytes32 r, bytes32 s
) externo;

Aquí, propietario, gastador y valor especifican quién otorga permiso, quién recibe permiso y la cantidad permitida. El plazo indica cuándo expira la firma. Los parámetros v, r y s forman el ECDSAfirma digital. Usando Permit, los usuarios evitan la aprobación separada en cadena, simplemente firman el mensaje (sin pagar Gas) e incluyen esta firma con su transacción para completar la autorización en un solo paso.

Flujo de trabajo de permisos

En comparación con la aprobación tradicional, Permit elimina la necesidad de una transacción adicional en cadena, ahorrando tanto tiempo como tarifas de Gas. También permite un control detallado sobre las aprobaciones. Por ejemplo, un usuario podría firmar un Permit que permite gastar exactamente 50 USDC, válido solo por 5 minutos. Incluso si la firma se expone, se vuelve inutilizable después de la fecha límite, reduciendo el riesgo. Hoy en día, muchos protocolos DeFi, como intercambios descentralizados y plataformas de préstamos, ya admiten Permit. Ejemplos conocidos incluyenUniswap V2/V3tokens LP, DAI, yUSDC, que han implementado el estándar EIP-2612, permitiendo aprobaciones basadas en firmas de un solo paso.

Sin embargo, la mayor limitación de Permit es que debe implementarse directamente dentro del contrato del token. Si el desarrollador de un token no ha añadido el método permit()—lo que significa que no soporta EIP-2612—entonces simplemente no se puede utilizar Permit. Dado que EIP-2612 se introdujo solo en 2020, muchos tokens más antiguos no lo incluyen, e incluso los tokens más nuevos no siempre lo adoptan. Esto restringe la aplicabilidad de Permit: los tokens no compatibles todavía requieren el flujo de aprobación tradicional.

Otro problema es que el software de billetera debe manejar y mostrar adecuadamente las firmas de Permiso, que suelen estar formateadas utilizando EIP-712. La mayoría de las billeteras principales admiten esto ahora, pero algunas todavía muestran datos en bruto en lugar de mensajes legibles para los humanos, lo que dificulta que los usuarios comprendan lo que están firmando. Sin una interfaz clara para EIP-2612, las billeteras pueden obstaculizar la comprensión de las aprobaciones basadas en firmas por parte de los usuarios. Además, en casos de implementaciones paralelas (como contratos con direcciones idénticas en diferentes cadenas), las firmas podrían potencialmente reutilizarse en otros entornos. Por lo tanto, los usuarios deben verificar que el ID de cadena y la dirección del contrato en sus firmas coincidan con su entorno actual para evitar que los permisos otorgados para tokens en la Cadena A sean utilizados de manera incorrecta por direcciones de contrato idénticas en la Cadena B.

En esencia, Permit mejora significativamente la eficiencia y flexibilidad de las aprobaciones ERC-20, marcando un hito importante en los mecanismos de aprobación sin gas. Sin embargo, no es una solución perfecta: requiere soporte a nivel de token e introduce nuevos riesgos. A continuación, examinaremos cómo Permit2 de Uniswap se basa en y extiende la base establecida por Permit.

Permit2: Contrato de Gestión de Autorización Universal

A medida que el mecanismo de permisos ganaba popularidad, surgió un nuevo desafío: ¿cómo extender la conveniencia de la autorización basada en firmas a tokens que no admiten Permit? Para abordar este problema y optimizar las experiencias de autorización en diversos escenarios, el equipo de Uniswap introdujo Permit2 en 2022. A diferencia de una característica específica de token, Permit2 es un contrato inteligente de gestión de autorizaciones independiente. Actúa como intermediario para las autorizaciones de tokens, proporcionando funcionalidades de permisos unificadas y mejoradas. Analicemos los principios y características de Permit2.

Cómo funciona Permit2

Permit2 funciona como un servicio de retransmisión de autorización. Su concepto principal es simple: los usuarios otorgan una aprobación única al contrato de Permit2, que luego gestiona subautorizaciones posteriores a varias aplicaciones. Así es como funciona:

1. Autorización de Permiso2 de una sola vez: Los usuarios aprueban el Permiso2 para cada token utilizando el método tradicional approve(Permiso2, max_amount). Se recomienda una cantidad grande o ilimitada, ya que esta es la aprobación principal. Una vez completado, el contrato de Permiso2 obtiene la capacidad de llamar a transferFrom en nombre del usuario para ese token. Esto requiere una transacción en cadena, pero solo necesita hacerse una vez.
2. Firma fuera de la cadena para subautorización: Cuando los usuarios desean interactuar con una DApp (por ejemplo, utilizando Uniswap Universal Router para intercambios de tokens múltiples), firman un mensaje de autorización fuera de la cadena siguiendo las especificaciones de Permit2. Esta firma incluye detalles como el token permitido, la cantidad, el destinatario del gasto (como un contrato DApp específico) y el tiempo de vencimiento.
3. Solicitud de transferencia de DApp usando firma: Cuando una DApp recibe la firma del usuario y necesita usar tokens, en lugar de llamar directamente al contrato de tokens, llama a las funciones de Permit2 (como permitTransferFrom). Esta función verifica los datos de la firma del usuario y confirma que la operación se encuentra dentro de los permisos otorgados (token, cantidad, plazo). Después de la verificación, Permit2 utiliza su aprobación principal para llamar a transferFrom, moviendo tokens del usuario al destinatario especificado. Punto clave: el propio contrato de Permit2 actúa como el gastador, utilizando su propia autoridad para transferir tokens, con un paso adicional de verificación de firma.
4. Finalización de la operación: una vez que Permit2 ejecuta con éxito transferFrom, los fondos se mueven sin problemas del usuario a la DApp o dirección especificada. Desde la perspectiva del usuario, solo proporcionan una firma en la transacción, mientras que el contrato maneja todas las acciones posteriores.

El flujo de autorización de Permit2 es sencillo: los usuarios solo necesitan otorgar la aprobación máxima a Permit2 una vez por token. Después, al interactuar con aplicaciones (como Uniswap Universal Router u otros protocolos), simplemente incluyen una firma de Permit2 en su transacción para completar la autorización y la transferencia, sin necesidad de aprobaciones adicionales en cadena. El contrato de Permit2 verifica la firma y ejecuta la transferencia utilizando su aprobación principal. (Fuente:Presentación de Permit2 & Universal Router)

A través de este modelo, Permit2 extiende el concepto de autorización basada en firmas de EIP-2612 a todos los tokens ERC-20, independientemente de si implementan el método permit() ellos mismos. Siempre que los usuarios autoricen inicialmente el contrato Permit2, pueden usar firmas para operaciones posteriores. En particular, Uniswap diseñó Permit2 como un contrato sin propietario y no actualizable implementado con la misma dirección en la red principal de Ethereum y en múltiples redes de capa 2. Esto significa que todas las aplicaciones utilizan realmente la misma instancia de Permit2, logrando una verdadera funcionalidad de "aprobar una vez, usar en todas partes".

Características clave de Permit2

Como sistema de autorización de próxima generación, Permit2 no solo permite aprobaciones basadas en firmas para todos los tokens, sino que también ofrece funciones adicionales para mejorar la seguridad y la facilidad de uso. Estas son sus principales características:

Expiración automática
Todas las autorizaciones Permit2 pueden incluir una marca de tiempo de vencimiento. Los usuarios pueden especificar cuándo debería expirar su subautorización al firmar. Una vez que se haya pasado la fecha límite, Permit2 rechazará la firma, incluso si la aprobación principal todavía está activa. Esto aborda efectivamente el riesgo de aprobaciones indefinidas que permanecen sin usar.

Transferencias de firma de un solo uso
Permit2 ofrece un modo de transferencia de firma directa donde los usuarios pueden autorizar una transferencia de token específica a un destinatario usando solo una firma, sin necesidad de establecer una asignación primero. Esto es perfecto para escenarios de pago único: los usuarios pueden firmar un mensaje autorizando la transferencia de 100 tokens a la dirección de un amigo, y el amigo o intermediario puede ejecutar la transferencia utilizando esta firma. Una vez utilizada, la firma se vuelve inválida, sin dejar permisos residuales.

Aprobaciones y Transferencias por Lotes
Permit2 prioriza la eficiencia al permitir el procesamiento por lotes de múltiples aprobaciones o transferencias. Los usuarios pueden autorizar diferentes cantidades de múltiples tokens a un solo protocolo con una sola firma, o ejecutar transferencias de múltiples tokens en una sola transacción. Esto ahorra Gas y reduce los pasos para los usuarios avanzados.

Revocación en lote
Además de las aprobaciones por lotes, los usuarios pueden revocar permisos para múltiples tokens/aplicaciones en una sola transacción. Esto hace que limpiar las aprobaciones históricas sea mucho más conveniente.

Testigos de datos adicionales
Permit2 incluye interfaces como permitirTransferenciaTestigoDesdeque permiten incluir datos de verificación adicionales en las firmas. Esto es compatible con escenarios más complejos, como incluir detalles específicos de transacciones en las firmas de orden para evitar la reutilización de firmas en diferentes contextos.

A través de estas características, Permit2 no solo replica todos los beneficios de Permit, sino que también mejora la flexibilidad y los controles de seguridad. La caducidad automática y las transferencias de firma de un solo uso, en particular, hacen que la autorización mínima necesaria sea la norma, lo que reduce los riesgos a largo plazo.

En resumen, Permit2 funciona tanto como una extensión como una mejora del mecanismo de Permiso tradicional. Examinemos las diferencias clave entre estos dos enfoques:

Permit2 Adopción e Implementación del Ecosistema

Desde que Uniswap introdujo Permit2, numerosos proyectos han integrado este mecanismo, acelerando la estandarización de la industria. Según los últimos datos de Dune Analytics, a partir de abril de 2025, más de 3.1 millones de direcciones del mainnet de Ethereum han otorgado autorización al contrato Permit2, demostrando su amplia adopción.

Permit2 Ecosistema y Estado de Implementación. Fuente: Análisis de Dune

Por ejemplo, Uniswap ha integrado Permit2 en su enrutador universal, lo que permite intercambios de tokens múltiples y NFT en una sola transacción. A través del enrutador universal, los usuarios pueden encadenar múltiples operaciones en una transacción, como intercambiar tres tokens por dos tokens objetivo y comprar NFT, con todos los requisitos de autorización manejados por las firmas de Permit2. Esto simplifica significativamente el proceso y reduce los costos totales de Gas, mostrando el impacto directo de Permit2 en la mejora de la experiencia del usuario.

Además, con la implementación de código abierto de Permit2 en varias cadenas, un número creciente de carteras y herramientas DApp han comenzado a ofrecerle soporte. Herramientas de seguridad como Revoke.cash han actualizado sus servicios para permitir a los usuarios ver y revocar los registros de autorización de Permit2. Matcha también ha implementado el módulo de Transferencia de Firma de Permit2, lo que permite un mecanismo de "autorización de una sola vez".

A pesar de este progreso, la adopción generalizada de Permit2 enfrenta desafíos. Por un lado, los desarrolladores necesitan tiempo adicional para la integración: en comparación con el uso directo de la aprobación de ERC-20, la implementación de Permit2 requiere el manejo de la lógica de firma, lo que aumenta la sobrecarga de desarrollo. Esto podría disuadir a los equipos más pequeños. Por otro lado, la educación de los usuarios es crucial: muchas DApps que utilizan Permit2 necesitan enseñar a los usuarios sobre la importancia de las firmas. Actualmente, las ventajas unificadas de Permit2 parecen superar estos puntos de fricción, pero la penetración total en el mercado aún llevará tiempo.

Comparando Permit2 con Nuevas Soluciones: Claves de Sesión y ERC-4337

En los últimos 8 años, los mecanismos de autorización ERC-20 han evolucionado desde múltiples transacciones hasta firmas sin gas y ahora a cuentas inteligentes. Cada avance ha buscado optimizar el equilibrio entre la experiencia del usuario (reduciendo los requisitos de transacción y firma) y los costos de gas. Aquí tienes una comparación de estas tecnologías:

Además de Permit2, dos soluciones de autorización emergentes dignas de mención son Session Keys yCuenta de Abstracción ERC-4337, cada uno ofreciendo enfoques distintos para el problema.

Las claves de sesión son particularmente únicas, ya que no son un modelo de autorización estricto, sino más bien un mecanismo de clave temporal a nivel de billetera o cuenta. En lugar de modificar contratos de tokens, permiten a las billeteras generar claves privadas temporales limitadas por tiempo y cantidad para operaciones específicas. Esto las hace ideales para compras de artículos de juegos y micropagos únicos. Su enfoque se centra en reducir los riesgos de autorización única, diseñado específicamente para interacciones temporales de usuario, a diferencia del enfoque de modificación de contrato de Permit/Permit2.

ERC-4337 toma un enfoque diferente al incrustar lógica de autorización directamente en cuentas inteligentes, lo que permite a los usuarios personalizar condiciones de autorización y posiblemente omitir pasos de aprobación tradicionales. A través de mecanismos flexibles de UserOperation y Paymaster, logra una seguridad y experiencia de usuario mejoradas.

Si nos fijamos en las tendencias futuras, es probable que estas diferentes soluciones coexistan. A corto plazo, Permit2 seguirá siendo el estándar para las DApps emergentes, mejorando la experiencia del usuario a través de autorizaciones únicas, al tiempo que promueve la educación en seguridad y el soporte de herramientas para reducir los riesgos de phishing. A mediano plazo, a medida que ERC-4337 y la abstracción de cuentas se generalicen en las redes principales y de capa 2, los usuarios podrán liberarse de las limitaciones tradicionales de aprobación de ERC-20, administrando las autorizaciones de manera más precisa e inteligente, lo que podría reducir la necesidad de Permit2.

La visión a largo plazo es crear una experiencia de autorización tan fluida e intuitiva como la Web2, en la que los usuarios puedan simplemente hacer clic en un botón y todas las aprobaciones necesarias se produzcan automáticamente en segundo plano, con indicaciones claras que aparezcan sólo en situaciones de alto riesgo. Lograr esta visión requerirá una colaboración e innovación continuas en todos los protocolos, billeteras y dApps subyacentes. Permit2 representa un paso importante en este viaje de transición, pero aún queda un largo camino por recorrer antes de alcanzar el estado ideal. A lo largo del camino, tanto la comunidad como los desarrolladores deben mantener un enfoque pragmático, comprender completamente las fortalezas y limitaciones de cada solución y trabajar juntos para crear un entorno de autorización más seguro y fácil de usar.

En general, Permit2 ofrece una solución práctica que se puede implementar de inmediato, mientras que tecnologías como Session Keys y ERC-4337 apuntan hacia mejoras más fundamentales y a largo plazo en la forma en que se maneja la autorización.

Riesgos de seguridad de la autorización basada en firmas

Como con cualquier nueva tecnología, Permit y Permit2 introducen no solo nuevas eficiencias, sino también nuevos riesgos, especialmente en torno a los ataques de autorización basados en firmas.

En esquemas basados en firmas como Permit2 y EIP-2612 Permit, los diseños de contratos principales incluyen múltiples capas de protección para protegerse contra el mal uso y los ataques de repetición:

1. Protección contra repeticiones basada en nonce

Permit2 mantiene un contador nonce independiente para cada tupla (propietario, token, gastador). Cada vez que un usuario firma una nueva autorización, se incrementa el nonce correspondiente. Si un atacante intenta reutilizar una firma antigua, se producirá un error porque el contrato comprueba si el nonce ya se ha utilizado.

2. Aplicación del plazo

Cada firma debe incluir un campo de fecha límite. Cuando el contrato verifica la firma, se asegura de que el tiempo del bloque actual sea menor o igual a la fecha límite. Si la firma ha caducado, incluso si es válida de otra manera, será rechazada. Esto evita que las autorizaciones de larga duración sean explotadas más tarde.

3. Control de autorización detallado

Las firmas Permit2 pueden especificar una asignación máxima. Antes de que ocurra cualquier transferencia de tokens, el contrato verifica que la cantidad solicitada esté dentro de este límite. El contrato no gasta automáticamente la cantidad aprobada completa, lo que permite a los usuarios utilizar su asignación en partes y reduce el riesgo de una explotación total.

4. Modos de uso único y por lotes

Además de las aprobaciones basadas en el permiso en curso, Permit2 también admite firmas de un solo uso a través de SignatureTransfer. Estas firmas son válidas solo para una transacción y se vuelven inválidas inmediatamente después de la ejecución. Esto es ideal para pagos únicos y evita que la firma se vuelva a utilizar o explotar más tarde.

Estas protecciones en capas ayudan a los esquemas de autorización de estilo de Permiso a mejorar la experiencia del usuario y ahorrar gas, al mismo tiempo que minimizan riesgos clásicos como "ataques de repetición", "sobre-autorización" y "validez de firma indefinida".

Sin embargo, incluso con protecciones seguras a nivel de contrato, la ingeniería social (especialmente el phishing) sigue siendo la amenaza más difícil de defender. En la siguiente sección, analizaremos tácticas comunes de phishing y cómo los atacantes engañan a los usuarios para que firmen aprobaciones maliciosas que abusan de Permit2 sin darse cuenta. También ofreceremos consejos sobre cómo mantenerse seguro.

¿Cómo suceden los ataques de phishing de firma?

El phishing de firma ocurre cuando los atacantes engañan a las víctimas para que firmen mensajes específicos con el fin de obtener el control de sus activos. Mientras que los ataques tradicionales podrían implicar la ejecución de contratos o transacciones maliciosas, en la era de los permisos, una sola autorización de firma maliciosa es suficiente para vaciar los fondos. Así es como suelen desarrollarse estos ataques:

1. El usuario hace clic en una versión falsa de un sitio web de DEX bien conocido (sitio de phishing). Cuando el usuario intenta interactuar, el sitio solicita una firma de billetera, alegando que es para la "confirmación de inicio de sesión" u otros propósitos aparentemente legítimos. Sin embargo, esta solicitud es en realidad una firma de autorización de Permit2, otorgando al contrato del atacante permiso ilimitado para retirar los USDC de la víctima con un período de validez extendido.
2. La víctima, careciendo de vigilancia, firma la solicitud directamente. En este punto, no se gasta gas y no se produce ninguna actividad en cadena, dejando así ninguna traza sospechosa.
3. Una vez que el atacante obtiene la firma, llama inmediatamente a la función permit() del contrato Permit2 para enviarla. Una vez que el contrato de Permit2 valida la firma, registra la autorización para el contrato del atacante bajo la dirección de la víctima (equivalente a que la víctima ejecute una aprobación, pero completada por el atacante). Esta operación aún puede pasar desapercibida para la víctima, ya que su billetera no muestra ningún gasto, solo su mapeo de asignación de tokens se actualiza en la cadena de bloques.
4. Posteriormente, el atacante inicia de inmediato una transacción transferFrom(víctima, dirección_del_atacante, cantidad) desde su dirección, logrando transferir con éxito el USDC de la víctima utilizando la reciente autorización Permit2. La víctima solo se da cuenta del robo cuando ya es demasiado tarde.

En estos ataques, los usuarios nunca ejecutan ninguna transacción de “transferencia” o “autorización” obvia, pero sus activos desaparecen misteriosamente. La clave radica en que la firma misma se convierte en la autorización. Los atacantes disfrazan cuidadosamente las solicitudes de firma para que parezcan operaciones normales, disminuyendo la guardia de los usuarios. Sin embargo, una vez firmado, es como entregar las llaves de sus activos.

Peor aún, algunos atacantes emplean métodos técnicos para aumentar el sigilo. Por ejemplo, utilizan el mecanismo de CREATE2 de Ethereum para generar direcciones de contrato maliciosas únicas para cada víctima. Esto hace que las listas negras tradicionales sean ineficaces, ya que cada ataque utiliza una dirección diferente.

La mayoría de los incidentes recientes de phishing en criptomonedas involucran autorización de firma. Por ejemplo, Scam Sniffer’sestadísticasa principios de 2024 se muestran más de $55 millones en activos robados a través de phishing de firma en solo un mes. Desde la activación de Permit2, los atacantes se han vuelto más agresivos al inducir a los usuarios a firmar autorizaciones de Permit/Permit2, lo que ha llevado a numerosas víctimas en un corto período. Claramente, cuando la autorización de firma es abusada, puede ser devastadora y difícil de detectar.

¿Por qué son más altos los riesgos de phishing basado en firmas que los métodos tradicionales?

Las autorizaciones maliciosas tradicionales requieren que los usuarios ejecuten una transacción en cadena, donde las billeteras suelen mostrar advertencias claras como “Estás autorizando a XXX a usar tus tokens” y requieren tarifas de gas. Los usuarios experimentados tienden a ser más cautelosos al respecto. Sin embargo, las solicitudes de firma en las interfaces de billeteras a menudo se describen simplemente como “solicitudes de firma de datos” en lugar de acciones financieras, lo que hace que los usuarios bajen la guardia. Además, dado que las firmas no cuestan gas, los atacantes pueden lanzar intentos de phishing a gran escala sin preocuparse por los gastos; incluso obtienen beneficios con solo unos pocos intentos exitosos.

Además, diferentes billeteras muestran mensajes EIP-712 de varias maneras. Algunas billeteras modernas (como la última MetaMaskparse y mostrar campos claramente, mostrando mensajes como “autorizar contrato para gastar X cantidad de sus tokens.” Sin embargo, muchas carteras solo muestran datos hexadecimales o descripciones simples, lo que dificulta que los usuarios promedio verifiquen la autenticidad. Los atacantes explotan esto al incrustar descripciones engañosas en los mensajes (como pretender ser firmas de acuñación de NFT) para engañar a los usuarios a firmar.

Porque las autorizaciones de firma no impactan inmediatamente en los activos, las víctimas pueden no detectar la amenaza de inmediato. Los atacantes pueden cronometrar estratégicamente sus ataques. En lugar de ejecutar de inmediato, podrían esperar hasta que la billetera de la víctima contenga más activos o hasta un momento específico, lo cual complica los esfuerzos de rastreo. Con firmas que tienen períodos de validez extendidos, los atacantes también pueden aprovechar los movimientos de precios para maximizar sus ganancias, dándoles efectivamente una opción de trading gratuita. Este riesgo explica por qué las firmas de Permiten típicamente imponen plazos cortos.

La capacidad de Permit2 para autorizar múltiples tokens con una sola firma hace que sea particularmente difícil para los usuarios comprender completamente las implicaciones. Por ejemplo, un sitio web de phishing puede solicitar una firma Permit2 mientras resalta los permisos de solo uno o dos tokens, pero incrustar en secreto autorizaciones extensas para tokens adicionales dentro de la misma firma. Los usuarios pueden pasar por alto fácilmente estos permisos ocultos si sus billeteras no muestran todos los detalles con claridad. Además, los atacantes a menudo usan nombres de contratos engañosos como "WalletGuard" en sus firmas, enmascarando contratos maliciosos diseñados para robar permisos de tokens.

¿Cómo pueden los usuarios protegerse de los ataques de firma?

Recuerda que firmar es equivalente a dar consentimiento, nunca dejes que la ausencia de tarifas de gas te haga descuidado. Cuando tu billetera solicita una firma, lee detenidamente los detalles del mensaje. Asegúrate de que el sitio web o DApp que solicita la firma sea legítimo y que el contenido del mensaje se alinee con tus acciones previstas. Por ejemplo, si simplemente estás iniciando sesión en un sitio web, la firma debe contener texto legible de inicio de sesión (como la mayoría de las DApps utilizan), no una cadena de direcciones y números de tokens.

Asegúrese de que su software de billetera admita la visualización de datos EIP-712. Billeteras importantes como MetaMask, TrustWallet (en inglés), yLedger Live están mejorando su experiencia de visualización de contenido característico. Por ejemplo, MetaMask ahora puede analizar los mensajes de permiso comunes en un lenguaje sencillo. Si su billetera solo muestra datos hexadecimales largos al firmar, considere cambiar o actualizar. Los usuarios de billeteras de hardware también deben mantener su firmware actualizado para admitir nuevos formatos, o es posible que no vean la información correctamente en la pantalla.

Ya sea que utilice firmas de Permiso o Permit2, generalmente puede ajustar los parámetros de autorización. No firme cantidades ilimitadas (valor = 2^256-1) a menos que sea absolutamente necesario, en su lugar, autorice solo la cantidad que necesita más un pequeño margen. Además, no establezca plazos demasiado lejanos en el futuro. De esta manera, incluso si su firma cae en manos equivocadas, las pérdidas potenciales están limitadas y la firma eventualmente caducará.

Desarrolla el hábito de verificar regularmente el estado de autorización de tu dirección utilizando herramientas como Revoke.cash, Etherscan Token Approval, o las funciones incorporadas en tu monedero. Esto incluye tanto las autorizaciones tradicionales como las permitidas por Permit2. Si identificas alguna autorización sospechosa o innecesaria, revócala inmediatamente. Para Permit2, ten en cuenta dos niveles de revocación: primero, la autorización principal (tu aprobación al contrato de Permit2 en sí mismo, que podrías querer establecer en 0 cuando no esté en uso); segundo, las sub-autorizaciones (las autorizaciones de Permit2 a varias DApps, que suelen caducar automáticamente pero pueden ser terminadas antes si tienen períodos de validez largos). Si sospechas que has firmado un Permiso sospechoso, la acción más segura es ajustar inmediatamente el nonce: firma un nuevo permiso al mismo gastador (incluso con una asignación de 0) para invalidar la antigua firma en posesión del atacante.

Siempre tenga cuidado al visitar sitios web desconocidos o al descargar aplicaciones. No haga clic en enlaces desconocidos, especialmente en "ofertas promocionales" o "eventos de creación" compartidos a través de anuncios en redes sociales o mensajes privados. Muchos intentos de phishing ocurren a través de cuentas oficiales falsas que publican enlaces de actividades fraudulentas, lo que lleva a solicitudes de firma. Haga el hábito de escribir directamente las URL oficiales de DApp o utilizar marcadores para evitar caer en sitios web falsos.

En conclusión, es crucial encontrar un equilibrio entre conveniencia y seguridad. Si bien las tecnologías Permit son convenientes, los usuarios deben permanecer vigilantes sobre la prevención de riesgos. A medida que el ecosistema madura, los productos de billetera y los complementos del navegador están desarrollando protección contra el phishing de firmas, como advertencias para firmas que involucran grandes cantidades. Nuestro objetivo es mitigar tales ataques en Gate.io a través de mejoras técnicas y educativas en el futuro.

Conclusión

Desde las limitaciones de los modelos tradicionales de autorización ERC-20 hasta el nacimiento de Permit, y luego a la innovadora Permit2 de Uniswap, hemos sido testigos de los esfuerzos del ecosistema Ethereum por mejorar la experiencia del usuario y la seguridad. Permit2 simplifica significativamente el proceso de autorización de tokens a través de firmas fuera de la cadena, reduciendo los riesgos de aprobaciones repetidas y permisos ilimitados, al mismo tiempo que introduce características útiles como mecanismos de vencimiento y operaciones por lotes. Sin embargo, estos nuevos mecanismos conllevan nuevas responsabilidades: los usuarios deben mejorar su conciencia de seguridad, mientras que las carteras y las aplicaciones descentralizadas deben trabajar juntas para proteger a los usuarios de los ataques de firmas. Mirando hacia el futuro, con nuevos desarrollos tecnológicos, como la abstracción de cuentas, se espera que la gestión de autorización de tokens se vuelva más fluida y segura.