Los nombres de usuario de la autenticación Basic son metadatos sensibles

Los nombres de usuario de la autenticación Basic son metadatos sensibles.

La afirmación puede sonar exagerada hasta que tienes que limpiar las consecuencias de una ejecución de automatización que copió billing-export@north-division en una transcripción de shell, un registro de CI, un prompt de agente y un ticket de incidente. Puede que la contraseña no aparezca en ninguno de esos cuatro lugares. Aun así, un atacante descubre que existe un tenant de la división norte, que tiene una integración para exportar facturas y que la cuenta probablemente llega a una API heredada concreta.

Los equipos suelen clasificar los datos entre secretos y todo lo demás. Esa división resulta demasiado básica para trabajar con API controladas por agentes. Un nombre de usuario, un ID de tenant, un hostname, una ruta de API y un código de respuesta pueden parecer inofensivos por separado. Juntos describen una estructura de cuentas que merece ser atacada. Trata esas combinaciones como metadatos sensibles, sobre todo cuando un agente puede copiar el contexto mucho más lejos y más rápido que una persona que escribe una sola solicitud.

Un nombre de usuario puede revelar cómo está construido el sistema de cuentas

Un nombre de usuario de Basic suele tener más significado del que su nombre de campo sugiere. Los sistemas heredados lo usan como nombre de inicio de sesión, código de cliente, etiqueta de división, rol de servicio, indicador de entorno o identificador compuesto creado antes de que existiera un modelo de identidad mejor.

Considera estos valores:

acme-east:password
svc-payroll-prod:password
tenant-48291-export:password
[email protected]:password

El primer valor indica un cliente y una división regional. El segundo nombra una capacidad interna y un entorno. El tercero revela un identificador de tenant y una función. El cuarto expone a una persona y su relación con un cliente. Rotar la contraseña corrige la mitad correspondiente a la contraseña. No hace desaparecer el mapa de cuentas copiado.

Esto importa porque los atacantes no empiezan todos los ataques con una credencial. Empiezan con una lista de objetivos. Un nombre de usuario reconocible les ayuda a redactar una solicitud de restablecimiento creíble, adivinar cuentas relacionadas, buscar en filtraciones de datos, probar una ruta específica de un cliente o presionar al equipo de soporte con detalles que parecen internos.

No descartes esto por teórico solo porque el nombre de usuario sea válido únicamente con una contraseña. Saber que existe svc-orders-import-prod no equivale a controlarlo, pero es mucho más útil que no saber nada. El trabajo de seguridad se encarece cuando los equipos esperan a que un campo sea una credencial completa antes de protegerlo.

La clasificación correcta depende del contexto. Un nombre de usuario público y genérico que usan todas las cuentas de sandbox puede necesitar poca protección. Una identidad de servicio vinculada a un tenant y combinada con un endpoint interno merece un manejo mucho más estricto. Documenta esa diferencia para cada integración en lugar de aplicar una etiqueta general después de una filtración.

La autenticación Basic mantiene el nombre de la cuenta unido a cada llamada

La autenticación Basic envía un valor user-id:password codificado en Base64 dentro del encabezado HTTP Authorization. Base64 cambia la representación. No oculta los bytes originales a quien pueda leer el encabezado.

Una solicitud típica tiene este aspecto:

GET /v1/exports/monthly HTTP/1.1
Host: api.legacy.example
Authorization: Basic c3ZjLWJpbGxpbmctZXhwb3J0LXByb2Q6cmVkYWN0ZWQ=
Accept: application/json

El texto codificado contiene ambas partes cada vez que el cliente llama a la API. Esa repetición es la propiedad incómoda que los equipos olvidan. Un bearer token también puede exponer el contexto de una cuenta, por supuesto, pero muchas integraciones Basic usan nombres de usuario legibles que lo dejan claro después de decodificarlos.

RFC 7617 define el esquema y señala dos detalles relevantes aquí. Los dos puntos separan el user-id de la contraseña, por lo que no se pueden usar dos puntos en el nombre de usuario. Los caracteres de control también están prohibidos. Esto significa que un proveedor heredado puede aceptar una convención de cuenta visualmente cómoda que en realidad no puede sobrevivir en un encabezado Basic conforme al estándar. No inventes una regla de escape esperando que todas las bibliotecas coincidan.

El segundo detalle es el tratamiento de los caracteres. RFC 7617 permite que un desafío del servidor anuncie UTF-8, pero esa señal es orientativa y muchos sistemas antiguos no gestionan de forma coherente las identidades no ASCII. Si el nombre de una cuenta incluye caracteres acentuados, reglas de mayúsculas o transformaciones Unicode, prueba el par exacto de cliente y servidor antes de llevarlo a producción. Un desacuerdo puede convertirse en un fallo de autenticación que alguien intente «solucionar» volcando toda la credencial en la salida de depuración.

La autenticación Basic también necesita HTTPS. OWASP describe las credenciales Basic como codificadas, no cifradas, y recomienda TLS siempre que se use Basic. TLS protege la conexión en tránsito. No protege un encabezado después de que una biblioteca cliente, un proxy inverso, un agente de trazas, un gestor de errores o una herramienta de depuración lo haya registrado.

Los IDs de tenant y los endpoints se vuelven peligrosos juntos

Un ID de tenant por sí solo puede ser un número opaco. Un endpoint por sí solo puede ser una ruta genérica. Juntos pueden identificar la función empresarial de un cliente y el sistema que la ejecuta.

Supón que un agente recibe esta instrucción:

For tenant 48291, call https://ledger.internal.example/v2/reconciliation/import
with username tenant-48291-ledger-import.

Aunque otro componente inyecte la contraseña, la instrucción proporciona al agente un tenant, un host, una operación y una identidad de servicio. El agente puede citar esa instrucción en sus notas de trabajo. Un envoltorio de herramienta puede registrarla. Una transcripción del modelo puede conservarla. Un desarrollador puede copiar el error en un canal de chat. La contraseña no se ve, pero la estructura de la cuenta sí.

La exposición aumenta cuando los nombres siguen una gramática predecible. Si un nombre de usuario es tenant-48291-ledger-import, es razonable suponer que también pueden existir tenant-48291-ledger-export, tenant-48291-reporting o los mismos roles para otros tenants. La previsibilidad resulta cómoda para los operadores y útil para enumerar cuentas. No tienes que abandonar todas las convenciones de nombres, pero debes reconocer cuándo una convención convierte un nombre filtrado en una consulta de directorio.

Los pares de endpoints también transmiten información. /admin/users, /payroll/export, /claims/submit y /archive/retention revelan tipos distintos de trabajo incluso con un hostname neutro. Un host, una ruta y un tenant suelen revelar lo suficiente para hacer creíble un mensaje de phishing o un intento de hacerse pasar por soporte.

Clasifica la tupla, no solo sus campos:

• identidad de servicio más ID de tenant
• identidad de servicio más hostname
• ID de tenant más ruta del endpoint
• ruta del endpoint más cuerpo de respuesta o texto de error
• marca de tiempo más registro de una acción exitosa

Esta regla es más precisa que «redacta las contraseñas». Explica a los revisores por qué una línea de registro sin ningún secreto literal puede seguir siendo peligrosa si se envía a un sistema de observabilidad con acceso amplio.

Los agentes copian contexto donde los clientes tradicionales no lo hacen

Un cliente de API normal suele recibir una URL, un nombre de cuenta y una contraseña a través de una ruta de configuración limitada. Un agente de IA procesa las instrucciones como texto. Puede inspeccionar un repositorio, leer un ticket, ejecutar un comando, interpretar un error y redactar un resumen. Cada transferencia puede conservar identificadores que un cliente tradicional nunca tendría que mostrar.

El riesgo no es que los agentes sean especialmente descuidados. El riesgo es que los flujos de trabajo con agentes hacen que el contexto sea transportable por diseño. La misma función que permite a un agente razonar sobre una nota de despliegue y una respuesta de API le permite llevar nombres de tenants y patrones de endpoints a entradas de herramientas, transcripciones o parches generados.

Un fallo habitual tiene este aspecto:

1. Un desarrollador pone un nombre de usuario Basic y un código de tenant en un archivo .env local porque la contraseña procede de un almacén de secretos.
2. El agente lee el archivo para entender una integración que falla.
3. La API devuelve una respuesta 401 con un error detallado que repite el nombre de usuario y el tenant.
4. El agente redacta un informe de diagnóstico que contiene el fragmento de configuración y el error.
5. El desarrollador copia ese informe en un issue visible para un grupo más amplio.

Nadie pretendía publicar credenciales. Aun así, el issue registra ahora un patrón de nombres válido, un tenant, un host, una ruta, un rol de servicio y una ventana temporal en la que la integración estuvo activa. Ese contexto basta para crear riesgos posteriores.

No intentes resolverlo prohibiendo que los agentes vean cualquier cadena que no sea un secreto. Eso bloquea trabajo útil y normalmente fracasa en la práctica. Decide qué acción necesita cada dato. Un agente que debe solicitar una exportación mensual puede necesitar un nombre de acción abstracto y un mes. No necesita el nombre de usuario Basic, la contraseña, la regla de enrutamiento del tenant ni la URL de destino sin procesar.

Esto cambia la pregunta de diseño de «¿Puede autenticarse el agente?» a «¿Cuál es la descripción mínima de la acción que necesita el agente para producir la solicitud prevista?». Esa es la pregunta que mantiene la estructura de la cuenta fuera de la ventana de contexto del agente.

Mantén el material de identidad fuera de los prompts y repositorios

Un prompt es un mal almacén de configuración. Lo mismo ocurre con los archivos fuente, los ejemplos de curl, las plantillas de issues, los alias de shell y los fixtures de prueba. Todos viajan más lejos de lo que espera su autor.

Empieza por separar tres cosas que los equipos suelen mezclar:

1. El material de credenciales son el nombre de usuario y la contraseña usados para autenticarse.
2. Los metadatos de enrutamiento indican adónde va una solicitud, como un host, una partición de tenant o una familia de endpoints.
3. La intención de la acción es la operación empresarial, como «descargar el archivo de conciliación de marzo».

Una persona o un agente a menudo puede expresar la intención de la acción sin ver las otras dos categorías. Ese es el límite preferido. Si una API heredada obliga a enrutar mediante un host específico del tenant o un nombre de usuario específico del tenant, conserva la correspondencia en el componente que ejecuta la solicitud, no en el prompt que la solicita.

Evita ejemplos de .env sin procesar como este en un repositorio:

LEGACY_API_URL=https://tenant-48291.api.legacy.example/v2/payroll/export
LEGACY_API_USER=tenant-48291-payroll-export
LEGACY_API_PASSWORD=replace-me

El marcador replace-me no hace seguro el ejemplo. La URL y el nombre de usuario siguen documentando un patrón de integración específico de un cliente. Un ejemplo copiado también puede convertirse más tarde en configuración de producción, normalmente bajo presión de tiempo.

Usa en su lugar un contrato local abstracto:

actions:
  export_monthly_payroll:
    account_ref: payroll-export-production
    target_ref: payroll-export-api
    inputs:
      - tenant_alias
      - month

Las etiquetas account_ref y target_ref deben ser suficientemente opacas para que un lector del repositorio no pueda deducir el cliente, el hostname ni el rol de servicio. El ejecutor las resuelve localmente. El agente recibe tenant_alias solo si la acción realmente lo necesita, y ese alias no debería ser un identificador de tenant de producción cuando una asignación local puede hacer el trabajo.

Este enfoque también evita un error habitual en las migraciones: mover la contraseña a un gestor de secretos y dejar el nombre de usuario, la URL de destino y el código de cliente codificados en la aplicación. Es una mejora frente a confirmar una contraseña en el repositorio, pero deja la estructura expuesta a todos los desarrolladores, registros de compilación y exportaciones de herramientas de análisis de código.

Usa alias que no conviertan una filtración en una consulta de directorio

Los nombres opacos no son mágicos, pero reducen la información que proporciona una divulgación accidental. El nombre de la cuenta debe describir su propósito al pequeño grupo que la administra, no anunciar una relación con un cliente a todos los sistemas que lo ven.

Compara estos alias de servicio:

bad:  acme-east-payroll-export-prod
better: svc-47f2-export-p1

El segundo todavía tiene un prefijo de servicio legible y un indicador de entorno. Eso suele ser práctico. Sus detalles útiles terminan ahí. Un registro protegido independiente puede asignar svc-47f2-export-p1 al cliente, propietario, endpoint, permisos y registro de rotación.

No trates los alias con aspecto aleatorio como sustituto de la autorización. Un atacante que tenga una contraseña aún puede autenticarse, y un empleado con acceso al registro aún puede ver la asignación. Los alias reducen la divulgación innecesaria. El mínimo privilegio y las revisiones de acceso controlan lo que puede hacer la cuenta.

Hay casos en los que un proveedor impone el formato del nombre de usuario. Algunas API antiguas exigen un número de cliente, una dirección de correo o un valor compuesto que incluya una región. Cuando sea así, acepta que el campo es sensible y cambia el manejo que lo rodea. No finjas que el valor es público porque no puedes cambiarle el nombre.

Mantén los identificadores exigidos por el proveedor dentro del límite de credenciales y haz que las salidas posteriores sean poco interesantes. Un ejecutor de solicitudes puede devolver export accepted con un identificador de tarea. No necesita repetir el nombre de usuario enviado, la URL de destino completa ni el valor de enrutamiento del tenant al agente que llama.

Los registros necesitan una pista de auditoría sin convertirse en un directorio de cuentas

Los registros de seguridad necesitan suficientes detalles para responder quién inició una acción, qué ocurrió, cuándo ocurrió y si tuvo éxito. No necesitan conservar cada byte enviado por el cliente. Las recomendaciones de registro de OWASP advierten expresamente contra el registro de información sensible, como contraseñas, identificadores de sesión y detalles innecesarios del sistema, y también piden registrar los eventos de autenticación y control de acceso.

La tensión es real. Si eliminas todo, los operadores no pueden investigar un incidente. Si conservas encabezados sin procesar y URL completas para siempre, tus registros se convierten en un directorio de cuentas consultable.

Usa una estructura de registro que separe la correlación operativa de los metadatos sensibles:

{
  "event": "legacy_api_call",
  "action": "export_monthly_payroll",
  "request_id": "req_01J...",
  "actor_run": "run_01J...",
  "credential_ref": "cred_4c91",
  "target_ref": "target_a77e",
  "result": "denied",
  "http_status": 401,
  "reason": "authentication_failed",
  "occurred_at": "2026-07-22T14:03:21Z"
}

Las referencias permiten a los operadores autorizados relacionar los eventos con un inventario protegido. No ponen el nombre de usuario, el ID de tenant, el endpoint sin procesar ni el encabezado Authorization en cada evento. El acceso al inventario debe ser más restringido que el acceso normal a los registros.

No registres un hash del nombre de usuario pensando que el problema está resuelto. Un hash determinista de un espacio pequeño y predecible de nombres de usuario suele poder adivinarse, y un hash estable aún permite seguir una cuenta entre registros. Si necesitas correlación, usa una referencia de credencial aleatoria asignada por tu propio sistema. Rota o retira la referencia cuando rotes la credencial.

Ten cuidado con los diagnósticos de errores. Esta es una mala respuesta para transmitir:

401 for tenant-48291-payroll-export at /v2/payroll/export: user exists but password rejected

Confirma una cuenta, un tenant, una ruta y el resultado de la validación. Un manejo interno mejor conserva el diagnóstico exacto del proveedor en un registro de soporte restringido si realmente lo necesitas, mientras que el historial general de actividad registra authentication_failed. El agente debe recibir un fallo breve que le indique detenerse y pedir ayuda, no otra pista para probar variaciones.

La redacción y la minimización resuelven problemas distintos

La redacción elimina un valor peligroso conocido después de que alguien ya lo haya manejado. La minimización impide que el valor entre en un lugar al que no pertenece. Necesitas ambas y confundirlas produce diseños deficientes.

Un limpiador de encabezados puede sustituir esto:

Authorization: Basic c3ZjLWJpbGxpbmctZXhwb3J0LXByb2Q6cmVkYWN0ZWQ=

por esto:

Authorization: [REDACTED]

Es necesario. Pero no hace nada con la ruta, el hostname, el parámetro de tenant de la consulta, el cuerpo detallado del 401, la etiqueta de la solicitud ni los atributos de traza registrados junto al encabezado. Un sistema que presume de redactar contraseñas mientras conserva tenant-48291.api.legacy.example/payroll/export ha reducido un riesgo y ha dejado un mapa de cuentas útil.

La minimización plantea preguntas más difíciles antes de ejecutar la solicitud:

• ¿El agente necesita el host de destino real o solo un nombre de acción?
• ¿El registro de actividad necesita el identificador del tenant o solo una referencia protegida?
• ¿El equipo de soporte necesita la respuesta sin procesar del proveedor en el flujo normal de registros?
• ¿La solicitud necesita el tenant en la URL cuando el ejecutor puede resolverlo localmente?
• ¿Una persona que revisa una aprobación necesita la identidad completa o una etiqueta comprensible que no revele información?

Aquí es donde muchos equipos hacen una recomendación popular pero equivocada: «Registra toda la solicitud una vez y mejora los filtros después». Lo dicen porque depurar API heredadas es muy difícil y las capturas completas responden rápido a las preguntas. Después, los datos capturados se convierten en evidencia permanente en copias de seguridad, almacenes analíticos, entornos de prueba y notas de incidentes copiadas. Crea en su lugar una ruta de diagnóstico restringida para una investigación breve. No conviertas la captura amplia sin procesar en el modo normal de operación.

Las API heredadas necesitan un límite de contención, no confianza ciega

Puede que este trimestre no puedas sustituir la autenticación Basic. Un proveedor quizá solo admita un estilo de integración. Un dispositivo de almacén puede tener una API congelada desde hace años. La respuesta práctica es la contención, no declarar sin más que la API heredada es aceptable.

Coloca la credencial Basic y la asignación de identificadores detrás de un componente que realice la solicitud HTTP. El agente debe pedir una acción con nombre y entradas estructuradas. El componente de solicitudes selecciona el destino, obtiene la credencial, la inyecta en el encabezado, comprueba el alcance previsto y devuelve un resultado limitado.

Para una acción de agente, un contrato de solicitud útil tiene este aspecto:

{
  "action": "export_monthly_payroll",
  "tenant_alias": "tenant_ref_91ab",
  "month": "2026-06"
}

El ejecutor de acciones puede validar el mes, resolver tenant_ref_91ab en una asignación local protegida y realizar la llamada al proveedor. Debe rechazar campos adicionales como url, authorization, username y headers. Si los llamadores pueden sobrescribir esos campos, pueden dirigir una credencial de confianza a un host arbitrario o convertir una acción limitada de nuevo en un cliente HTTP sin restricciones.

Esta restricción también importa para errores del tipo SSRF y para la exposición de credenciales. Una URL proporcionada por el usuario no es una comodidad inocua cuando el ejecutor posee credenciales. El destino debe proceder de una definición controlada y los redireccionamientos necesitan el mismo cuidado. No sigas una redirección a un nuevo origen conservando el encabezado Authorization.

Este límite también debe gestionar los reintentos. Un agente mal diseñado puede reintentar un 401 con datos modificados o invocar repetidamente una operación después de un tiempo de espera. El ejecutor debe distinguir entre un reintento de transporte seguro, un fallo de autenticación y un resultado de escritura desconocido. Para un endpoint heredado no idempotente, devuelve un estado que obligue a una revisión humana en lugar de enviar la misma solicitud otra vez porque el agente la pidió con seguridad.

Sallyport encaja en este patrón cuando un agente compatible con MCP necesita llamar a una API HTTP sin recibir la credencial Basic. Su canal HTTP inyecta las credenciales Basic dentro de la aplicación, y sus controles por sesión y por llamada permiten a una persona decidir cuándo una ejecución del agente puede usar esa cuenta. El agente recibe el resultado de la acción, no un nombre de usuario o una contraseña en texto plano que pueda reutilizar en otro lugar.

La aprobación debe mostrar suficiente contexto para detectar la acción equivocada

Un cuadro de aprobación que solo dice «¿Permitir llamada a la API?» no ayuda. Un cuadro que imprime el nombre de usuario Basic completo, el tenant, la URL completa y el cuerpo de la solicitud sin procesar comparte demasiado. El revisor necesita una descripción breve que haga evidente una acción incorrecta sin exponer toda la estructura de la cuenta.

Muestra el nombre de la acción, una etiqueta protegida del destino, una etiqueta del tenant elegida para el revisor, el tipo de operación y la consecuencia general. Por ejemplo:

Allow export_monthly_payroll?
Target: Payroll export service
Tenant: Finance tenant 7
Operation: Create June 2026 export
Agent run: signed local coding process

Esto proporciona al revisor información suficiente para detectar un mes, una función o un destino inesperados. No revela un hostname del proveedor, un número de tenant ni un nombre de usuario de servicio en el registro de aprobación.

La etiqueta visible necesita gobernanza. Si «Finance tenant 7» aparece en un equipo que solo tiene un cliente financiero, aún puede identificarlo. Usa etiquetas adecuadas para el grupo que las ve. La seguridad no se consigue sustituyendo cada nombre útil por un código opaco que los revisores no puedan entender.

Para las cuentas Basic sensibles, exige aprobación en cada uso cuando la acción pueda mover dinero, exportar registros regulados, cambiar accesos o contactar con una parte externa. La aprobación por sesión resulta más práctica para una ejecución breve que realiza muchas lecturas de bajo riesgo. La decisión debe seguir la autoridad de la cuenta y la consecuencia de la acción, no el hecho de que la autenticación Basic sea antigua.

Conserva un registro auditable de la decisión de aprobación y de la llamada resultante. Un registro resistente a manipulaciones solo sirve si describe al actor, la acción, el resultado y el estado de aprobación sin convertirse en otra copia del mapa de credenciales. Los diarios separados de sesiones y actividad de Sallyport están diseñados según esa división, con ambas vistas proyectadas desde su registro de auditoría cifrado y encadenado mediante hashes.

Haz que la estructura de la cuenta sea difícil de recopilar desde el principio

La solución no es un documento de políticas enorme que diga «maneja los metadatos con cuidado». Haz que la ruta más segura sea la que desarrolladores y agentes usen de forma natural.

Haz un inventario de cada integración Basic y responde estas preguntas para cada una: ¿Qué revela el nombre de usuario? ¿Contiene una persona, un cliente, un entorno, un producto o un rol? ¿Qué combinación de host y endpoint hace que ese valor revele más información? ¿Dónde aparecen hoy esos valores? ¿Qué llamador necesita verlos realmente?

Después elimina las copias fáciles. Sustituye los fragmentos de curl sin procesar por ejemplos de acciones. Sustituye los nombres de fixtures específicos de tenants por alias de prueba neutros. Bloquea los encabezados Authorization y la información de usuario de las URL en los registros de aplicación. Mantén los diagnósticos completos del proveedor fuera de las salidas visibles para los agentes. Rechaza los destinos de solicitud proporcionados por el usuario en el límite de credenciales. Proporciona al equipo de soporte una forma controlada de recuperar los detalles cuando un incidente lo justifique.

RFC 9110 indica que los emisores no deben generar referencias URI HTTP o HTTPS con información de usuario user:password@host, y advierte que las implementaciones pueden exponer un identificador de usuario o una contraseña cuando usan esa forma en la configuración o en opciones de comandos. Es una advertencia útil también más allá de las URL: los detalles de identidad colocados en campos de texto cómodos tienden a copiarse en lugares donde nunca deberían estar.

La autenticación Basic puede seguir existiendo porque un proveedor no ha avanzado. Tu propio manejo no tiene por qué quedarse atrás. Cuando tratas los nombres de usuario, los IDs de tenant y los pares de endpoints como metadatos sensibles, dejas de entregar al agente el directorio de cuentas junto con la tarea.