Seguridad
Seguridad que se siente como hospitalidad.
Un proveedor de identidad vale lo que valen los muros entre sus inquilinos y el cuidado con que trata los secretos. Así está construido Usher Identity. Describimos lo que hace el software; no afirmamos tener ninguna certificación.
Arquitectura
Dominios separados, redes separadas.
Las páginas de Usher Identity y el emisor de cada cliente están en dominios registrables distintos. Las bases de datos están en una red que no puede llegar a internet, y la única salida es un proxy que comprueba adónde va cada conexión.
- Caddy termina TLS para cada host y elimina los encabezados que solo pueden establecer los servicios del propio Usher Identity.
- El nivel de autenticación responde por todos los entornos, que se distinguen por el host; nada se guarda en caché para un host y se sirve a otro.
- Cada servicio se conecta a Valkey con su propio usuario, limitado a sus propias claves. No hay usuario predeterminado.
- Las sentencias que llevan tokens y códigos nunca se escriben con sus valores en el registro de la base de datos.
Internet
Las personas, tus apps, tus servidores
El perímetro
Caddy: TLS, HSTS, elimina los encabezados internos
usheridentity.com
Sitio y Console
usheridentity.com, console.usheridentity.com
API
api.usheridentity.com
*.usherid.com
Nivel de autenticación
El emisor y el Lobby de cada entorno
Red de datos · sin ruta de salida
Postgres
Un esquema por entorno
Valkey
Cada servicio, limitado a sus propias claves
La única salida
Proxy de salida
Para cada URL que proporciona un cliente
Descubrimiento, JWKS, cierre de sesión
Solo direcciones públicas
Aislamiento
Nada importante en común.
Cada entorno de un proyecto tiene su propio esquema de Postgres, sus propias claves de firma y sus propios secretos, sellados con su propia clave de datos. Su emisor es un host en el dominio de inquilinos, y sus cookies son solo del host, así que un navegador nunca envía la cookie de un entorno a otro.
usheridentity.com
El sitio, Usher Identity Console y las cuentas de Usher Identity
*.usherid.com
Un emisor por entorno, en un dominio aparte
Los usuarios, las sesiones y los tokens están en un esquema creado para este entorno. Las consultas se ejecutan en ese esquema, nunca en una tabla compartida con una columna de inquilino.
Copia el secreto de cliente de Google sellado del entorno de producción de Acme al entorno de producción de Northwind.
Cifrado en reposo
Cifrado de sobre, vinculado a su lugar.
Los secretos que le das a Usher Identity se sellan con AES-256-GCM con una clave de datos que pertenece a un solo entorno. A su vez, las claves de datos se cifran con una clave maestra con versiones, guardada fuera de la base de datos.
- Claves de datos por entorno
- Comprometer la clave de datos de un entorno no revela nada sobre la de otro.
- Vinculación con AAD
- El entorno y el propósito quedan vinculados a cada texto cifrado, así que un valor no se puede mover entre filas ni entre inquilinos.
- Claves con versiones
- Cada valor sellado registra la versión de la clave con la que se creó, para poder rotar las claves y volver a cifrar los valores antiguos.
- Autenticado
- Gracias a la etiqueta de GCM, un valor alterado no se puede abrir, en lugar de descifrarse como otra cosa.
Clave maestra
Guardada fuera de la base de datos, con versiones
Clave de datos, una por entorno
Cifrada con la clave maestra
El secreto
Sellado con AES-256-GCM con la clave de datos
u1.<key version>.<iv>.<ciphertext + tag>
aad = u1 | version | environment | purpose
Prácticas
Los detalles, con cuidado.
Contraseñas, si las usas
Se guardan como hash con Argon2id, con el costo que recomienda OWASP (19 MiB, dos pasadas) y un límite de cuántos hashes se calculan a la vez, para que una avalancha de inicios de sesión no pueda tumbar el servicio. Las contraseñas nuevas se comparan con filtraciones conocidas mediante la API de rangos de Have I Been Pwned, que solo ve un prefijo corto del hash de la contraseña. La longitud mínima predeterminada es de 12 caracteres.
Nada guardado que se pueda volver a usar
Los secretos de cliente, los tokens, los tokens de enlaces mágicos y los códigos por correo se guardan como hash. Los códigos de respaldo se cifran. Un código de autorización dura cinco minutos; un código por correo permite tres intentos.
Límites de frecuencia en cada puerta
El inicio de sesión, el registro, los códigos por correo, los enlaces mágicos, los restablecimientos de contraseña y las comprobaciones del segundo factor tienen cada uno su propio límite: por ejemplo, diez inicios de sesión con contraseña por minuto y cinco códigos por correo cada diez minutos.
Una Content-Security-Policy estricta
Cada página del Lobby recibe un nonce nuevo y una política construida a su alrededor: solo se ejecutan los scripts de este origen que llevan el nonce, los formularios solo se envían al mismo origen y otros sitios no pueden mostrar la página en un marco.
Un registro de auditoría confiable
Los cambios en espacios de trabajo, proyectos y entornos se escriben en un registro al que solo se pueden agregar entradas, cada una encadenada por hash a la anterior, así que una entrada editada o faltante salta a la vista.
Un proxy de salida para las URL de los clientes
Cada solicitud que Usher Identity hace a una dirección que le dio un cliente (descubrimiento de OIDC, JWKS, cierre de sesión por canal secundario) sale a través de un único proxy. Este resuelve el nombre una sola vez, rechaza las direcciones privadas, de loopback, de enlace local y de metadatos de la nube, y se conecta a la dirección que comprobó, así que el DNS rebinding no puede convertir la URL de un cliente en una interna.
Identificadores que nunca se asignan dos veces
El identificador de un entorno de producción es la primera etiqueta de su emisor. A Console solo se accede por invitación, un Lobby reportado por phishing se suspende, y un identificador que ya se usó nunca se vuelve a asignar, porque las apps antiguas aún podrían confiar en sus tokens.
Sesiones que terminan cuando tú lo decides
Usher Identity comprueba sus propias sesiones en cada solicitud en lugar de confiar en una copia en caché, así que una sesión que cierras termina en el acto. Los tokens de acceso duran poco (diez minutos de forma predeterminada), y tu API puede verificarlos por introspección.
Divulgación responsable
¿Encontraste algo? Avísanos primero.
Si crees que encontraste un problema de seguridad en Usher Identity, nos gustaría saberlo, y trabajaremos contigo para solucionarlo.
- Qué encontraste, dónde y cómo reproducirlo.
- Lo que alguien podría hacer con él, según lo que entiendes.
- Cómo podemos comunicarnos contigo y si quieres que te demos crédito.
Te pedimos que hagas pruebas solo en entornos que sean tuyos, que no accedas a datos de otras personas y que nos des un tiempo razonable para solucionar el problema antes de compartirlo. Para reportar una página que se hace pasar por un inicio de sesión de Usher Identity, consulta Reportar abusos.