Seguretat
Seguretat que se sent com hospitalitat.
Un proveïdor d’identitat només és tan bo com els murs que separen els seus inquilins i la cura amb què tracta els secrets. Així és com està fet Usher Identity. Descrivim el que fa el programari; no afirmem tenir cap certificació.
Arquitectura
Dominis separats, xarxes separades.
Les pàgines d’Usher Identity i l’emissor de cada client són en dominis registrables diferents. Les bases de dades són en una xarxa que no pot arribar a internet, i l’única sortida és un proxy que comprova on va.
- Caddy gestiona el TLS de tots els hosts i elimina les capçaleres que només poden definir els serveis del mateix Usher Identity.
- La capa d’autenticació respon per a tots els entorns, que distingeix pel host; no es desa res a la memòria cau per a un host per servir-ho a un altre.
- Cada servei es connecta a Valkey amb el seu propi usuari, limitat a les seves pròpies claus. No hi ha cap usuari per defecte.
- Les sentències que porten tokens i codis no s’escriuen mai al registre de la base de dades amb els seus valors.
Internet
Les persones, les teves apps, els teus servidors
La capa perimetral
Caddy: TLS, HSTS, elimina les capçaleres internes
usheridentity.com
Lloc web i Console
usheridentity.com, console.usheridentity.com
API
api.usheridentity.com
*.usherid.com
Capa d’autenticació
L’emissor i el Lobby de cada entorn
Xarxa de dades · sense sortida
Postgres
Un esquema per entorn
Valkey
Cada servei limitat a les seves pròpies claus
L’única sortida
Proxy de sortida
Per a cada URL que proporciona un client
Descobriment, JWKS, tancament de sessió
Només adreces públiques
Aïllament
No es comparteix res que importi.
Cada entorn d’un projecte té el seu propi esquema de Postgres, les seves pròpies claus de signatura i els seus propis secrets, segellats amb la seva pròpia clau de dades. El seu emissor és un host al domini dels inquilins, i les seves galetes són només per al host, de manera que un navegador mai no envia la galeta d’un entorn a un altre.
usheridentity.com
El lloc web, Usher Identity Console, els comptes d’Usher Identity
*.usherid.com
Un emissor per entorn, en un domini separat
Els usuaris, les sessions i els tokens viuen en un esquema fet per a aquest entorn. Les consultes s’executen en aquest esquema, mai en una taula compartida amb una columna d’inquilí.
Copia el secret de client de Google segellat de Acme (producció) a Northwind (producció).
Xifratge en repòs
Xifratge en sobre, lligat al seu lloc.
Els secrets que dones a Usher Identity se segellen amb AES-256-GCM sota una clau de dades que pertany a un sol entorn. Les claus de dades, al seu torn, estan protegides per una clau mestra amb versions guardada fora de la base de dades.
- Claus de dades per entorn
- Comprometre la clau de dades d’un entorn no revela res sobre la d’un altre.
- Vinculació amb AAD
- L’entorn i la finalitat queden vinculats a cada text xifrat, de manera que un valor no es pot moure entre files ni entre inquilins.
- Claus amb versions
- Cada valor segellat registra la versió de la clau amb què es va crear, de manera que les claus es poden fer rotar i els valors antics es poden tornar a protegir.
- Autenticat
- L’etiqueta de GCM fa que un valor manipulat no es pugui obrir, en lloc de desxifrar-se en una altra cosa.
Clau mestra
Guardada fora de la base de dades, amb versions
Clau de dades, una per entorn
Protegida per la clau mestra
El secret
Segellat amb AES-256-GCM sota la clau de dades
u1.<key version>.<iv>.<ciphertext + tag>
aad = u1 | version | environment | purpose
Pràctiques
Els detalls, fets amb cura.
Contrasenyes, si les fas servir
Es fa el hash amb Argon2id amb el cost que recomana OWASP (19 MiB, dues passades), amb un límit de quants se n’executen alhora perquè una allau d’inicis de sessió no pugui fer caure el servei. Les contrasenyes noves es comproven amb filtracions conegudes a través de l’API de rangs de Have I Been Pwned, que només veu un prefix curt del hash de la contrasenya. La longitud mínima és de 12 per defecte.
No es desa res que es pugui reutilitzar
Els secrets de client, els tokens, els tokens dels enllaços màgics i els codis per correu electrònic es desen amb hash. Els codis de reserva es desen xifrats. Un codi d’autorització dura cinc minuts; un codi per correu electrònic admet tres intents.
Límits de freqüència a totes les portes
L’inici de sessió, el registre, els codis per correu electrònic, els enllaços màgics, els restabliments de contrasenya i les comprovacions del segon factor tenen cadascun el seu propi límit: per exemple, deu inicis de sessió amb contrasenya per minut, i cinc codis per correu electrònic cada deu minuts.
Una Content-Security-Policy estricta
Cada pàgina del Lobby rep un nonce nou i una política construïda al seu voltant: només s’executen els scripts d’aquest origen que porten el nonce, els formularis només s’envien al mateix origen, i altres llocs web no poden incrustar la pàgina en un marc.
Un registre d’auditoria fiable
Els canvis als espais de treball, els projectes i els entorns s’escriuen en un registre on només es pot afegir, amb cada entrada encadenada amb hash a l’anterior, de manera que si se n’edita o se’n treu una, es nota.
Un proxy de sortida per als URL dels clients
Cada sol·licitud que Usher Identity fa a una adreça que li ha donat un client (descobriment d’OIDC, JWKS, tancament de sessió per canal secundari) surt per un sol proxy. Resol el nom una vegada, rebutja les adreces privades, de bucle local, d’enllaç local i de metadades del núvol, i es connecta a l’adreça que ha comprovat, de manera que el DNS rebinding no pot convertir l’URL d’un client en una d’interna.
Identificadors que no es donen mai dues vegades
L’identificador d’un entorn de producció és la primera etiqueta del seu emissor. A Console s’hi accedeix per invitació, un Lobby denunciat per phishing se suspèn, i un identificador que ja s’ha fet servir no es torna a donar mai, perquè és possible que apps antigues encara confiïn en els seus tokens.
Sessions que s’acaben quan tu dius
Usher Identity comprova les seves pròpies sessions a cada sol·licitud en lloc de confiar en una còpia a la memòria cau, de manera que una sessió que tanques s’acaba a l’instant. Els tokens d’accés duren poc (deu minuts per defecte), i la teva API els pot inspeccionar.
Divulgació responsable
Has trobat alguna cosa? Explica-ho primer a nosaltres.
Si creus que has trobat un problema de seguretat a Usher Identity, ens agradaria saber-ho, i treballarem amb tu per solucionar-lo.
- Què has trobat, on, i com reproduir-ho.
- Què se’n podria fer, tal com tu ho entens.
- Com et podem contactar, i si vols que t’hi esmentem.
Fes proves només en entorns que siguin teus, no accedeixis a dades d’altres persones i dona’ns un temps raonable per solucionar el problema abans de fer-lo públic. Per denunciar una pàgina que es fa passar per un inici de sessió d’Usher Identity, consulta Denuncia un abús.