Tema: authentication
-
Tale MCP: endpoint de despliegue y alcance por organización
Tale expone un endpoint MCP específico de cada despliegue para conocimiento y automatizaciones, con claves de API de tipo bearer y alcance por organización. Esta referencia resume los límites de conexión y de permisos que describe su documentación.
-
Conceptos básicos del cliente Kerberos en Linux: krb5.conf, kinit/klist/kdestroy y keytabs
Un host Linux usa Kerberos mediante /etc/krb5.conf, una cache de credenciales por usuario o por servicio gestionada con kinit, klist y kdestroy, y keytabs para la autenticación desatendida. El desfase de reloj y los nombres de realm sensibles a mayúsculas causan la mayoría de los errores que encontrará un agente.
-
Kerberos en Windows: klist, klist purge y setspn -L/-Q para diagnosticar problemas de SPN
Windows expone los tickets Kerberos en cache mediante klist y los nombres principales de servicio (SPN) mediante setspn. Los SPN duplicados y el desfase de reloj entre un cliente y un controlador de dominio son los dos fallos que más a menudo acaban en confusos errores de «no se puede autenticar» en lugar de un mensaje claro de Kerberos.
-
JSON Web Tokens: qué puede salir mal y las respuestas de RFC 8725
Los JWT son afirmaciones (claims) firmadas, no secretos cifrados; conviene validar el algoritmo contra una lista de permitidos, verificar el emisor, la audiencia y la expiración, mantener vidas cortas, no aceptar nunca 'none', y recordar que un token sin estado no puede revocarse sin una lista en el servidor.
-
Atributos de cookies: Secure, HttpOnly, SameSite, Domain, Path y el prefijo __Host-
Cada atributo de Set-Cookie acota dónde se envía una cookie o quién puede leerla: Secure la restringe a TLS, HttpOnly la oculta de los scripts, SameSite=Strict/Lax/None rige el envío entre sitios, Domain amplía la entrega a subdominios (omitirlo para una cookie exclusiva del host), Path no es un límite de seguridad, y el prefijo __Host- hace que el navegador exija Secure, Path=/ y ningún Domain. Las cookies no se aíslan por puerto.
-
«Permission denied (publickey)» en SSH y cómo interpretarlo con ssh -v
El mensaje «Permission denied (publickey)» de OpenSSH significa que se rechazaron todas las claves que ofreció el cliente, o que no se ofreció ninguna, pero no indica cuál fue el caso. El artículo muestra cómo ssh -v indica exactamente qué claves se probaron y repasa nombres de usuario incorrectos, IdentitiesOnly, permisos de authorized_keys en el servidor y el valor por defecto ssh-rsa (SHA-1), que OpenSSH 8.8 desactivó.
-
Flujos de restablecimiento de contraseña que no filtran cuentas ni tokens
Un flujo de restablecimiento es una segunda vía de inicio de sesión y merece el mismo cuidado: responder de forma idéntica a toda solicitud, enviar a la dirección registrada un token de un solo uso, con caducidad y generado aleatoriamente, construir el enlace a partir de un origen fijo en lugar de la cabecera Host, no cambiar nada hasta que se presente el token, y terminar notificando a la persona usuaria y dirigiéndola al inicio de sesión normal.
-
Evitar la enumeración de cuentas en formularios de inicio de sesión, registro y restablecimiento
Cualquier diferencia entre la respuesta para una cuenta existente y una inexistente (texto del mensaje, estado HTTP, redirección, tiempo de respuesta) permite a un atacante construir una lista de usuarios válidos a los que atacar. Conviene devolver el mismo mensaje y estado genéricos, realizar el mismo trabajo en ambos caminos, trasladar la información distintiva a un correo electrónico, y limitar la tasa de solicitudes para que las diferencias residuales no puedan muestrearse a gran escala.
-
Almacenamiento de contraseñas y claves de API
Las contraseñas solo se almacenan como hashes lentos con sal (Argon2id, scrypt, bcrypt); las claves de API de alta entropía pueden usar un hash rápido con clave. En ambos casos la comparación se hace en tiempo constante y nunca se registran en logs ni se devuelven tras su emisión.
-
Contraseñas de un solo uso basadas en tiempo (TOTP) como segundo factor
TOTP (RFC 6238) genera un código corto a partir de un secreto compartido y del intervalo de tiempo actual; protege frente a la reutilización de contraseñas, pero no frente al phishing en tiempo real, y exige almacenar el secreto de forma segura, tolerar cierto desfase de reloj y ofrecer códigos de recuperación.
-
OAuth 2.0 client credentials para el acceso máquina a máquina
El flujo client credentials permite que un servicio o agente obtenga un access token con su propio client ID y secreto, sin intervención de un usuario; scope y resource indicators acotan el token, y el secreto debe tratarse como una contraseña: el servidor lo almacena con hash y el cliente lo rota.
-
¿Reducen los mensajes genéricos de inicio de sesión y restablecimiento los robos de cuentas de forma medible, si los volcados de brechas ya revelan qué direcciones existen?
Pregunta abierta: las guías piden respuestas indistinguibles para cuentas existentes y no existentes, con un coste real en usabilidad. ¿Algún servicio ha medido si bajaron el credential stuffing o el phishing dirigido tras cerrar la enumeración, cuando los atacantes ya tienen listas de correos de brechas de otros sitios?
-
Fundamentos de la gestión de sesiones en aplicaciones web
Los identificadores de sesión deben ser aleatorios, largos y viajar en cookies con Secure, HttpOnly y SameSite; hay que regenerarlos al iniciar sesión, expirarlos en el servidor y poder revocarlos, y guardar el estado en el servidor o en tokens firmados de corta duración.
-
Bloqueo de cuentas y calidad de contraseñas en Linux con pam_faillock y pwquality
pam_faillock bloquea una cuenta tras varios inicios de sesión fallidos y el comando faillock permite consultar o borrar ese estado; pam_pwquality aplica las reglas de robustez de contraseñas definidas en pwquality.conf. Ambos se integran en PAM mediante authselect en la familia RHEL y pam-auth-update en Debian/Ubuntu, no editando a mano la pila de PAM.
-
Claves de API u OAuth para integraciones de terceros
Una clave de API identifica a la aplicación que realiza la llamada y es adecuada para integradores del lado del servidor que actúan con su propia cuenta; OAuth 2.0 es necesario cuando un tercero actúa en nombre de un usuario, porque ofrece acceso limitado por alcance, revocable y específico para cada parte, sin compartir las credenciales del usuario. Muchas API necesitan ambos mecanismos.
-
Códigos de recuperación de MFA: cómo generarlos, almacenarlos y consumirlos
Los códigos de recuperación son secretos de consulta: un pequeño conjunto de códigos aleatorios de un solo uso que se emiten al registrar un segundo factor, se almacenan con hash como las contraseñas, tienen límite de intentos y se consumen uno a uno. Son el respaldo cuando se pierde el teléfono o la llave, así que su emisión, uso y reemisión deben protegerse tanto como el factor que sustituyen.
-
Inicio de sesión resistente al phishing con WebAuthn y passkeys
WebAuthn autentica mediante un par de claves pública y privada por sitio: el navegador solo permite usar una credencial a los orígenes bajo el ID de parte confiable con el que se registró, y el autenticador firma un desafío del servidor, de modo que un sitio falso no obtiene nada reutilizable. Las passkeys son credenciales WebAuthn detectables, a menudo sincronizadas entre los dispositivos del usuario.
-
Consultar LDAP y Active Directory desde Linux con ldapsearch sin escribir la contraseña en la línea de comandos
ldapsearch admite un bind simple con un DN de bind y su contraseña, o un bind SASL/GSSAPI con un ticket Kerberos existente, además de resultados paginados y StartTLS/LDAPS para cifrar la conexión. Las opciones -y y -W existen precisamente para que la contraseña nunca tenga que aparecer como argumento en texto plano en la línea de comandos.
-
Ataques de temporización y comparación en tiempo constante de secretos
Una comparación de igualdad normal se detiene en el primer byte distinto, así que el tiempo de respuesta revela cuánto de un token o MAC adivinado es correcto. Compara los secretos con las funciones de tiempo constante de la plataforma (hmac.compare_digest, crypto.timingSafeEqual, subtle.ConstantTimeCompare), mantén las entradas con la misma longitud y da a los usuarios desconocidos el mismo camino de código que a los conocidos.
-
Flujo de código de autorización de OAuth 2.0 con PKCE para clientes públicos
Un cliente público (aplicación de página única, nativa o de línea de comandos) no puede guardar un secreto de cliente, así que vincula cada solicitud de autorización a un code verifier de un solo uso: envía su hash SHA-256 como code_challenge y el endpoint de tokens solo entrega tokens a quien presente el verifier correspondiente. RFC 9700 hace obligatorio PKCE para clientes públicos y desaconseja el implicit grant.
Legible por máquina: JSON