Biztonság
Biztonság, amely vendégszeretetnek érződik.
Egy identitásszolgáltató csak annyit ér, amennyire erősek a falak a bérlői között, és amennyire gondosan bánik a titkokkal. Így épül fel az Usher Identity. Azt írjuk le, amit a szoftver csinál; semmilyen tanúsítványra nem hivatkozunk.
Architektúra
Külön domainek, külön hálózatok.
Az Usher Identity saját oldalai és minden ügyfél kibocsátója különböző regisztrálható domaineken élnek. Az adatbázisok olyan hálózaton vannak, amely nem éri el az internetet, és az egyetlen kijárat egy proxy, amely ellenőrzi, hová tart a forgalom.
- A Caddy minden hoszt TLS-kapcsolatát lezárja, és eltávolítja azokat a fejléceket, amelyeket csak az Usher Identity saját szolgáltatásai állíthatnak be.
- Az auth réteg minden környezetnek válaszol, és hoszt alapján különbözteti meg őket; semmi sem kerül gyorsítótárba egy hoszt számára úgy, hogy aztán egy másiknak szolgálnák ki.
- Minden szolgáltatás saját felhasználóként kapcsolódik a Valkey adatbázishoz, és csak a saját kulcsaihoz fér hozzá. Alapértelmezett felhasználó nincs.
- A tokeneket és kódokat tartalmazó utasítások soha nem kerülnek be az értékeikkel együtt az adatbázis naplójába.
Az internet
Emberek, az appjaid, a szervereid
A perem
Caddy: TLS, HSTS, a belső fejlécek eltávolítása
usheridentity.com
Webhely és Console
usheridentity.com, console.usheridentity.com
API
api.usheridentity.com
*.usherid.com
Auth réteg
Minden környezet kibocsátója és Lobbyja
Adathálózat · nem vezet ki belőle út
Postgres
Környezetenként egy séma
Valkey
Minden szolgáltatás csak a saját kulcsaihoz fér hozzá
Az egyetlen kijárat
Kimenő proxy
Minden ügyfél által megadott URL-hez
Felderítés, JWKS, kijelentkezés
Csak nyilvános címek
Elkülönítés
Semmi lényeges nincs közösben.
Minden projektkörnyezet saját Postgres-sémát, saját aláírókulcsokat és saját titkokat kap, amelyeket a saját adatkulcsa pecsétel le. A kibocsátója egy hoszt a bérlői domainen, a cookie-jai pedig csak erre a hosztra érvényesek, így a böngésző soha nem küldi el az egyik környezet cookie-ját egy másiknak.
usheridentity.com
A webhely, az Usher Identity Console és az Usher Identity-fiókok
*.usherid.com
Környezetenként egy kibocsátó, külön domainen
A felhasználók, a munkamenetek és a tokenek egy ehhez a környezethez létrehozott sémában élnek. A lekérdezések ezen a sémán futnak, soha nem egy közös táblán, bérlőoszloppal.
Másold át a lepecsételt Google titkos ügyfélkulcsot: Acme (éles) → Northwind (éles).
Tárolt adatok titkosítása
Borítéktitkosítás, a helyéhez kötve.
Az Usher Identitynek átadott titkokat AES-256-GCM titkosítás pecsételi le egy olyan adatkulccsal, amely egyetlen környezethez tartozik. Az adatkulcsokat egy verziózott mesterkulcs burkolja, amelyet az adatbázison kívül tárolunk.
- Környezetenkénti adatkulcsok
- Ha egy környezet adatkulcsa illetéktelen kezekbe kerül, az semmit nem árul el egy másik környezetéről.
- AAD-kötés
- A környezet és a cél minden titkosított szövegbe bele van kötve, így egy érték nem vihető át sorok vagy bérlők között.
- Verziózott kulcsok
- Minden lepecsételt érték rögzíti, melyik kulcsverzióval készült, így a kulcsok lecserélhetők, a régi értékek pedig újraburkolhatók.
- Hitelesített
- A GCM hitelesítő címkéje miatt egy manipulált érték egyszerűen nem nyílik ki, ahelyett hogy valami mássá fejtődne vissza.
Mesterkulcs
Az adatbázison kívül tárolva, verziózva
Adatkulcs, környezetenként egy
A mesterkulcs burkolja
A titok
AES-256-GCM titkosítással lepecsételve, az adatkulcs alatt
u1.<key version>.<iv>.<ciphertext + tag>
aad = u1 | version | environment | purpose
Gyakorlatok
A részletek, gondosan.
Jelszavak, ha használod őket
Argon2id algoritmussal hashelve, az OWASP által javasolt költséggel (19 MiB, két menet), és korlátozva, hány fut egyszerre, hogy a bejelentkezések áradata ne tudja leállítani a szolgáltatást. Az új jelszavakat a Have I Been Pwned range API-ján keresztül vetjük össze az ismert adatszivárgásokkal; ez az API csak a jelszó hash-ének egy rövid előtagját látja. A minimális hossz alapértelmezés szerint 12.
Semmi visszajátszható nincs tárolva
A titkos ügyfélkulcsokat, a tokeneket, a bejelentkezési linkek tokenjeit és az e-mailben küldött kódokat hashelve tároljuk. A tartalékkódok titkosítva vannak. Egy engedélyezési kód öt percig érvényes; egy e-mailben küldött kóddal háromszor lehet próbálkozni.
Gyakoriságkorlát minden ajtón
A bejelentkezésnek, a regisztrációnak, az e-mailben küldött kódoknak, a bejelentkezési linkeknek, a jelszó-visszaállításnak és a második tényező ellenőrzésének mind saját korlátja van: például percenként tíz jelszavas bejelentkezés, és tíz percenként öt e-mailben küldött kód.
Szigorú Content-Security-Policy
Minden Lobby-oldal friss nonce-t kap, és köré épített házirendet: csak ennek az originnek a nonce-t hordozó szkriptjei futnak, az űrlapok csak ugyanarra az originre küldenek adatot, és más webhelyek nem ágyazhatják be az oldalt keretbe.
Auditnapló, amelyben megbízhatsz
A munkaterületek, projektek és környezetek változásai egy csak hozzáfűzhető naplóba kerülnek, ahol minden bejegyzés hash-lánccal kapcsolódik az előzőhöz, így egy módosított vagy hiányzó bejegyzés azonnal kiderül.
Kimenő proxy az ügyfél-URL-ekhez
Minden kérés, amelyet az Usher Identity egy ügyfél által megadott címre küld (OIDC-felderítés, JWKS, háttércsatornás kijelentkezés), egyetlen proxyn keresztül távozik. A proxy egyszer oldja fel a nevet, elutasítja a privát, loopback, link-local és felhőmetaadat-címeket, és ahhoz a címhez kapcsolódik, amelyet ellenőrzött, így DNS rebindinggel sem lehet egy ügyfél-URL-ből belső címet csinálni.
Rövid nevek, amelyeket soha nem adunk ki kétszer
Egy éles környezet rövid neve a kibocsátója címének első tagja. A Console csak meghívással érhető el, az adathalászat miatt bejelentett Lobbyt felfüggesztjük, és egy egyszer már használt rövid nevet soha nem adunk ki újra, mert régi appok még megbízhatnak a tokenjeiben.
Munkamenetek, amelyek akkor érnek véget, amikor mondod
Az Usher Identity minden kérésnél a saját munkameneteit ellenőrzi ahelyett, hogy egy gyorsítótárazott másolatban bízna, így egy lezárt munkamenet azonnal véget ér. A hozzáférési tokenek rövid ideig érvényesek (alapértelmezés szerint tíz percig), és az API-d introspekcióval ellenőrizheti őket.
Felelős közzététel
Találtál valamit? Először nekünk szólj.
Ha úgy gondolod, biztonsági hibát találtál az Usher Identityben, szeretnénk hallani róla, és veled együtt dolgozunk a javításán.
- Mit találtál, hol, és hogyan reprodukálható.
- Mit tehetne vele valaki, ahogy te látod.
- Hogyan érhetünk el, és szeretnéd-e, hogy név szerint megemlítsünk.
Kérjük, csak a saját környezeteiden tesztelj, ne férj hozzá mások adataihoz, és adj ésszerű időt a hiba javítására, mielőtt nyilvánosságra hozod. Ha Usher Identity-bejelentkezésnek álcázott oldalt szeretnél jelenteni, lásd: Visszaélés bejelentése.