Redacta los secretos antes de pegar
Redactar un secreto es sustituir una credencial dentro de un texto —una clave API, un token, una contraseña o una clave privada— por un marcador antes de compartir el texto, de modo que la información viaje sin el acceso. Importa porque la forma más común de filtrar secretos no es un ataque, sino un pegado: un registro en un ticket de soporte, un archivo de configuración en un chat, un comando de depuración en un foro. Este artículo explica por qué esos pegados son tan difíciles de deshacer, qué puede y no puede detectar un escáner como el redactor de secretos, y el flujo —redactar localmente, compartir la copia redactada, rotar todo lo que ya escapó— que evita que un pegado servicial se convierta en un incidente.
Por qué los secretos acaban en tickets, chats y registros
Nadie pega un secreto a propósito. Pega lo que rodea al secreto: el registro de error que casualmente incluye las cabeceras de la petición, el archivo de configuración que casualmente guarda la contraseña de la base de datos tres secciones más abajo, el comando curl copiado de un terminal donde el token está sentado en una cabecera Authorization. La resolución de problemas corre sobre contexto, y las credenciales viven dentro del contexto: por eso las mesas de soporte, los canales de chat y los rastreadores de incidencias acumulan en silencio claves activas, tokens de sesión y claves privadas, escritas por gente cuidadosa con prisa que miraba el mensaje de error y no la cabecera de encima.
El sistema receptor hace entonces permanente el pegado de maneras que el remitente nunca ve. Los tickets se indexan para buscar, se reenvían a proveedores, se exportan a informes y se guardan durante años; los mensajes de chat se empujan a los teléfonos como notificaciones, se citan en hilos y los resumen bots; los registros se envían a agregadores con su propia retención y sus propias listas de acceso. Un secreto en uno de estos sistemas no está en un sitio: está en cada copia, copia de seguridad, vista previa y notificación que el sistema generó, la mayoría de las cuales el remitente no puede ni enumerar, y mucho menos borrar. Esa asimetría —un segundo para pegar, ninguna forma fiable de recuperar— es toda la razón por la que la redacción debe ocurrir antes del pegado, en la máquina del remitente, y no como limpieza posterior.
Lo que un escáner puede detectar: formas, sumas y estructura
La buena noticia es que las credenciales reales son muy pautadas, y el escaneo de patrones es determinista: el mismo texto produce siempre los mismos hallazgos, sin ningún modelo adivinando en medio. Las claves de los proveedores llevan formas publicadas —prefijos, longitudes fijas, alfabetos restringidos—, así que una clave de acceso de AWS, un token de GitHub, una clave de Stripe o un token de Slack pueden reconocerse a simple vista, como quien reconoce un número de teléfono en un párrafo. Las claves privadas se anuncian con sus líneas de armadura BEGIN y END, y los JSON Web Tokens tienen una estructura rígida de tres segmentos cuyos dos primeros segmentos siempre empiezan igual, porque siempre codifican el mismo tipo de JSON.
Dos comprobaciones mantienen honesta la capa de patrones. Los números de tarjeta solo se marcan cuando pasan la suma de verificación de Luhn, una prueba aritmética incorporada en todo número de tarjeta auténtico, que separa las tarjetas reales de la población mucho mayor de números largos —pedidos, facturas, marcas de tiempo— que solo se les parecen. Y cuando las formas se solapan, los patrones específicos ganan a los genéricos, de modo que una clave de proveedor conocida asignada a una variable se informa una sola vez, con su tipo real y las instrucciones de rotación correctas adjuntas. El propio escaneo de secretos de GitHub, la primera fuente de abajo, funciona con el mismo principio a escala de plataforma: los socios publican los formatos de sus tokens y la plataforma los casa con exactitud. Un escáner local es la misma idea, ejecutada en el último momento en que aún puede ayudar: tu navegador, antes de pulsar enviar.
Lo que un escáner no puede detectar: entropía y contexto
Más allá de las formas de proveedor, la detección se vuelve probabilística. Una regla genérica puede buscar asignaciones —un nombre como password o api_key junto a un valor— y exigir que el valor parezca aleatorio, medido por la entropía de Shannon. Eso atrapa una clave generada asignada a una variable e ignora la palabra password dentro de una frase, pero el límite es un juicio disfrazado de número: una contraseña humana fuerte y una clave de máquina débil viven en la misma escala, un secreto real deletreado como frase puntúa bajo, y un hash de compilación de aspecto aleatorio sin palabras de marcador puntúa alto. La entropía te dice que una cadena es sorprendente; no puede decirte que la cadena es una credencial.
El contexto es el punto ciego mayor, porque casi todo lo que hace peligroso un valor está fuera del valor. Una cookie de sesión no es más que letras y dígitos hasta que sabes qué servicio desbloquea. Una contraseña de base de datos parece inofensiva dentro de una cadena de conexión repartida entre tres variables de entorno, y un código de un solo uso solo es sensible durante diez minutos. Los escáneres tampoco ven a través de la estructura: un secreto envuelto en dos líneas de registro, codificado en base64 dentro de un blob o capturado en una imagen es invisible para los patrones de texto, por buenos que sean. El resumen honesto es que un escáner atrapa con fiabilidad la mayoría documentada y bien formada —y que la vista previa que te muestra, con los hallazgos resaltados en su sitio, aún merece tu propia ojeada de diez segundos, porque tus ojos conocen el contexto que los patrones no pueden conocer.
Hay una clase más a la que el escáner es deliberadamente ciego, y está al lado de una trampa: los marcadores de posición. Los valores de documentación —que contienen palabras como example, test, dummy o your-— se excluyen para que los manuales y tutoriales no enciendan la tabla de hallazgos. Pero cada exclusión es una puerta: una clave real que casualmente contiene una de esas palabras, o una contraseña real perezosa puesta a un valor con aspecto de marcador, pasa en silencio. Trata la lista de exclusión como un control de ruido, nunca como una garantía, y nunca marques una credencial real con palabras de marcador para que un escáner se calle.
El problema del ejemplo falso canónico
Todo proveedor publica credenciales de ejemplo, y la más famosa —la pareja de documentación de AWS construida alrededor de AKIAIOSFODNN7EXAMPLE— tiene exactamente la forma de una clave real, porque un ejemplo que no pareciera real no enseñaría nada. Los escáneres se enfrentan entonces a una bifurcación sin buen valor por defecto. Marcar los ejemplos canónicos, y cada tutorial, libro de texto y registro de formación se convierte en una falsa alarma, enseñando a los lectores a descartar los hallazgos por reflejo: la fatiga de alarmas es una vulnerabilidad en sí misma. Ponerlos en una lista blanca, y has publicado una lista de cadenas que ningún escáner informará jamás, una invitación para quien quiera un escondite: una clave real no puede ser igual al ejemplo, pero una nota, un nombre de archivo o un envoltorio alrededor de una clave real puede tomar prestado el camuflaje del ejemplo.
La respuesta práctica es la que toma el redactor de secretos: marcar la forma y dejar que la tabla de hallazgos inicie la conversación. El ejemplo canónico contiene la palabra example dentro de la propia clave, y aun así se marca como clave de AWS, porque una cadena con forma de proveedor merece una mirada humana cada vez: la mirada es barata, y la alternativa es un pase silencioso para todo lo que tenga la misma forma. Cuando escribas documentación, ayuda también a los escáneres de tus lectores y al tuyo: usa valores obviamente sintéticos, márcalos con palabras de marcador en la asignación circundante, y nunca pegues una clave real en un documento y edites unos pocos caracteres: una clave real parcialmente editada sigue siendo una filtración de credencial con pasos extra, y los escáneres tampoco pueden distinguirla del artículo genuino.
Rotar, no solo borrar — y compartir con seguridad
Si un secreto real ya se pegó sin redactar, el orden de las operaciones importa y borrar va al final, si es que va. Supón que el valor ha sido copiado —por un índice, una notificación, una captura, la cita de un colega— y trátalo como público: ve primero al proveedor y rota la credencial, revocando la antigua, para que la cadena filtrada deje de funcionar sobreviva donde sobreviva. Solo entonces borra o edita el mensaje original, como higiene y no como arreglo. La guía de gestión de secretos de OWASP y el proyecto gitleaks, ambos listados abajo, existen para las dos mitades de esta lección: gestionar secretos para que sean de vida corta y alcance limitado, y escanear repositorios e historiales suponiendo que los pegados ya han ocurrido. El problema compañero para las capturas del navegador se recorre en antes de enviar ese archivo HAR.
El flujo seguro para compartir es lo bastante corto para convertirse en hábito. Primero, redacta localmente, en una herramienta que nunca suba el original: el análisis pertenece a tu dispositivo, porque enviar texto sin procesar a un redactor remoto repetiría la filtración en el acto de evitarla. Segundo, comparte la copia redactada en el ticket o el chat, donde lleva todo lo que un solucionador necesita —extremos, tiempos, formas de error— excepto el acceso. Tercero, cuando la otra parte necesite de verdad la credencial misma, envíala a través de un gestor de secretos o un enlace de uso compartido caducable y de una sola vista, por un canal separado de la discusión, y dilo en el ticket para que nadie la vuelva a pegar. Los equipos que adoptan esos tres pasos dejan de depender de la vigilancia, que es el único control que siempre falla al final, y empiezan a depender de una rutina —y las rutinas son lo que mantiene los secretos fuera de los tickets en el pegado cansado del viernes tan fiablemente como en el cuidadoso del lunes.