Rechazo estricto de claves API con permiso de retiro: análisis técnico profundo

La mayoría de las plataformas de trading aceptan claves API con permiso de retiro habilitado. Muestran un banner de advertencia amarillo, te piden que escribas "Entiendo", y almacenan la clave de todas formas. Nosotros no hacemos eso. Si tu clave tiene permiso de retiro, la rechazamos en la incorporación y nunca la almacenamos. Este artículo explica por qué, cómo, y qué cuesta realmente la alternativa.

El modelo de amenaza en un párrafo

Cualquier sistema que aloje una clave API con permiso de retiro está a una fuga de credenciales de distancia de vaciar las cuentas de usuario. La fuga no tiene que ser una brecha de base de datos — puede ser una laptop de empleado comprometida, una copia de seguridad mal configurada, un canal lateral en una dependencia de terceros, o un volcado de memoria de proceso en un log sin encriptar. Cada uno de esos casos ha sucedido en empresas más grandes que la nuestra. La única defensa durable es: no tener en primer lugar las claves para los fondos de nadie.

Cómo funciona la detección

En la primera llamada autenticada después de que el usuario pegue una clave, realizamos una llamada de introspección de permisos específica del exchange. La mayoría de los venues principales exponen:

• Un endpoint dedicado "consultar información de clave API" que devuelve el conjunto de permisos como un campo estructurado, o
• Un endpoint de información de cuenta donde el alcance de permisos de la clave se incluye como parte de la carga útil de respuesta.

Buscamos cualquier bandera que otorgue retiro, transferencia interna, transferencia de subcuenta, o transferencia universal — los venues usan nombres diferentes para la misma idea. Si alguno de esos está presente, descartamos el secreto en memoria inmediatamente, devolvemos un error estructurado a la UI, y nunca escribimos la clave en nuestra base de datos.

Por qué rechazar estrictamente en lugar de advertir

Las advertencias se descartan. Hemos observado los datos sobre esto durante años en múltiples productos. La tasa base de usuarios escribiendo "Entiendo" sin leer una sola palabra arriba está por encima del 80%. Una advertencia que el 80% de usuarios ignora no es un control de seguridad; es un escudo de responsabilidad.

El rechazo estricto es lo opuesto. Pone la fricción en el lugar correcto: el usuario vuelve al exchange, crea una nueva clave solo con permiso de trading, regresa, y pega esa. Todo el ciclo le cuesta al usuario quizás dos minutos. Le cuesta al atacante — en el peor escenario de fuga de credenciales — la cuenta completa.

Qué te cuesta realmente el camino de advertir en lugar de rechazar

El patrón de advertir y almacenar se ve amigable hasta que preguntas: ¿cómo se ve el peor caso? Obtienes un empleado hostil, una comprensión de la cadena de suministro, un canal lateral en una dependencia transitiva, un log mal alcanceado, y la respuesta es que las claves con permiso de retiro son exactamente tan buenas como la persona más débil y el código más débil que nunca los tocó.

El rechazo estricto invierte ese cálculo. Incluso en un peor caso de compromiso completo de base de datos, el atacante se va con claves de lectura+trading. Las claves de solo trading pueden hacer daño — pueden liquidar posiciones, generar comisiones, volcar posiciones abiertas en pares ilíquidos — pero no pueden retirar. Los fondos permanecen en el exchange. Eso no es riesgo cero, pero es el riesgo al que te suscribiste cuando conectaste un agente de trading automatizado en primer lugar.

Qué todavía no podemos defender

No estamos fingiendo que el rechazo estricto es una postura de seguridad completa. Es un control. El conjunto completo está documentado en nuestra página de seguridad: encriptación de sobre KMS con claves de datos por usuario, secretos desencriptados que viven solo en memoria de proceso y solo por la duración de una llamada API, log de auditoría encadenado en hash de solo anexo, aislamiento entre usuarios probado en CI, y un programa de divulgación de vulnerabilidades. El rechazo estricto de permiso de retiro es solo la pieza más visible de esa pila — y la más fácil de verificar tú mismo, porque puedes vernos rechazar una clave con permiso de retiro en tiempo real durante la incorporación.