Beveiliging
Beveiliging die voelt als gastvrijheid.
Een identiteitsprovider is zo goed als de muren tussen zijn tenants en de zorg waarmee hij met geheimen omgaat. Zo is Usher Identity gebouwd. We beschrijven wat de software doet; we claimen geen certificering.
Architectuur
Aparte domeinen, aparte netwerken.
De eigen pagina’s van Usher Identity en de issuer van elke klant staan op verschillende registreerbare domeinen. De databases zitten op een netwerk dat het internet niet kan bereiken, en de enige weg naar buiten is een proxy die controleert waar het verkeer heen gaat.
- Caddy verzorgt de TLS-terminatie voor elke host en verwijdert headers die alleen de eigen diensten van Usher Identity mogen zetten.
- De auth-laag beantwoordt verzoeken voor elke omgeving en onderscheidt ze op host; niets wat voor de ene host in de cache staat, wordt aan een andere geleverd.
- Elke dienst praat met Valkey als een eigen gebruiker, beperkt tot de eigen sleutels. Er is geen standaardgebruiker.
- SQL-statements met tokens en codes worden nooit met hun waarden in het databaselog geschreven.
Het internet
Mensen, je apps, je servers
De edge
Caddy: TLS, HSTS, verwijdert interne headers
usheridentity.com
Site en Console
usheridentity.com, console.usheridentity.com
API
api.usheridentity.com
*.usherid.com
Auth-laag
De issuer en Lobby van elke omgeving
Datanetwerk · geen route naar buiten
Postgres
Een schema per omgeving
Valkey
Elke dienst beperkt tot de eigen sleutels
De enige weg naar buiten
Egress-proxy
Voor elke URL die een klant opgeeft
Discovery, JWKS, logout
Alleen openbare adressen
Isolatie
Niets gedeeld wat ertoe doet.
Elke projectomgeving krijgt een eigen Postgres-schema, eigen ondertekeningssleutels en eigen geheimen, verzegeld met een eigen gegevenssleutel. De issuer is een host op het tenantdomein en de cookies zijn host-only, dus een browser stuurt de cookie van de ene omgeving nooit naar een andere.
usheridentity.com
De site, Usher Identity Console, Usher Identity-accounts
*.usherid.com
Eén issuer per omgeving, op een apart domein
Gebruikers, sessies en tokens staan in een schema dat voor deze omgeving is gemaakt. Query’s draaien tegen dat schema, nooit tegen een gedeelde tabel met een tenantkolom.
Kopieer het verzegelde Google-clientgeheim van Acme productie naar Northwind productie.
Versleuteling bij opslag
Envelopversleuteling, gebonden aan haar plek.
Geheimen die je aan Usher Identity geeft, worden verzegeld met AES-256-GCM onder een gegevenssleutel die bij één omgeving hoort. Gegevenssleutels zijn zelf weer versleuteld met een hoofdsleutel met versies, die buiten de database wordt bewaard.
- Gegevenssleutels per omgeving
- Wie de gegevenssleutel van de ene omgeving in handen krijgt, komt niets te weten over die van een andere.
- AAD-binding
- De omgeving en het doel zijn in elke ciphertext verankerd, dus een waarde kan niet tussen rijen of tenants worden verplaatst.
- Sleutels met versies
- Elke verzegelde waarde legt vast met welke sleutelversie ze is gemaakt, zodat sleutels kunnen worden geroteerd en oude waarden opnieuw kunnen worden versleuteld.
- Geauthenticeerd
- Door de tag van GCM gaat een gemanipuleerde waarde niet open, in plaats van te ontsleutelen tot iets anders.
Hoofdsleutel
Buiten de database bewaard, met versies
Gegevenssleutel, één per omgeving
Versleuteld met de hoofdsleutel
Het geheim
Verzegeld met AES-256-GCM onder de gegevenssleutel
u1.<key version>.<iv>.<ciphertext + tag>
aad = u1 | version | environment | purpose
Werkwijze
Aandacht voor de details.
Wachtwoorden, als je die gebruikt
Gehasht met Argon2id op de door OWASP aanbevolen kosten (19 MiB, twee passes), met een limiet op hoeveel er tegelijk draaien, zodat een vloed aan inlogpogingen de dienst niet plat kan leggen. Nieuwe wachtwoorden worden gecontroleerd op bekende datalekken via de range-API van Have I Been Pwned, die alleen een kort voorvoegsel van de hash van het wachtwoord te zien krijgt. De minimale lengte is standaard 12.
Niets bewaard wat opnieuw kan worden afgespeeld
Clientgeheimen, tokens, magic-linktokens en codes per e-mail worden gehasht opgeslagen. Back-upcodes worden versleuteld. Een autorisatiecode is vijf minuten geldig; een code per e-mail mag drie keer worden geprobeerd.
Rate limits op elke deur
Inloggen, registreren, codes per e-mail, magic links, wachtwoordherstel en controles van de tweede factor hebben elk een eigen limiet: bijvoorbeeld tien inlogpogingen met een wachtwoord per minuut, en vijf codes per e-mail per tien minuten.
Een strikte Content-Security-Policy
Elke Lobby-pagina krijgt een nieuwe nonce en een beleid dat daaromheen is gebouwd: alleen scripts van deze origin die de nonce dragen, worden uitgevoerd, formulieren posten alleen naar dezelfde origin, en andere sites kunnen de pagina niet in een frame laden.
Een auditlog waarop je kunt vertrouwen
Wijzigingen in werkruimten, projecten en omgevingen worden geschreven naar een log waaraan alleen iets kan worden toegevoegd, en elk item is met een hash aan het vorige gekoppeld, zodat een bewerkt of ontbrekend item opvalt.
Een egress-proxy voor URL’s van klanten
Elk verzoek dat Usher Identity doet naar een adres dat een klant heeft opgegeven (OIDC-discovery, JWKS, back-channel logout), gaat via één proxy naar buiten. Die zoekt de naam één keer op, weigert private, loopback-, link-local- en cloudmetadata-adressen, en maakt verbinding met precies het adres dat is gecontroleerd, zodat DNS-rebinding van een URL van een klant geen interne URL kan maken.
Handles die nooit twee keer worden uitgegeven
De handle van een productieomgeving is het eerste label van haar issuer. Console is alleen toegankelijk op uitnodiging, een Lobby die is gemeld voor phishing wordt opgeschort, en een handle die eenmaal is gebruikt, wordt nooit opnieuw uitgegeven, omdat oude apps de tokens ervan misschien nog vertrouwen.
Sessies die eindigen wanneer jij dat zegt
Usher Identity controleert bij elk verzoek de eigen sessies in plaats van een kopie uit de cache te vertrouwen, dus een sessie die je beëindigt, is meteen voorbij. Toegangstokens zijn kort geldig (standaard tien minuten), en je API kan ze introspecteren.
Responsible disclosure
Iets gevonden? Laat het ons eerst weten.
Denk je dat je een beveiligingsprobleem in Usher Identity hebt gevonden? Dan horen we het graag, en werken we met je samen om het op te lossen.
- Wat je hebt gevonden, waar, en hoe het te reproduceren is.
- Wat iemand ermee zou kunnen doen, voor zover jij dat kunt overzien.
- Hoe we je kunnen bereiken, en of je vermeld wilt worden.
Test alleen op omgevingen die van jou zijn, open geen gegevens van anderen, en geef ons redelijk de tijd om het probleem op te lossen voordat je het deelt. Wil je een pagina melden die zich voordoet als inlogpagina van Usher Identity? Zie dan Misbruik melden.