Hintergrund
In diesem Dokument werden die erforderlichen Attribute für gemeinsame Kennungen behandelt, die bei der Integration zwischen Google und einem Anbieter (oder dem Aussteller des Kontos für den Nutzer) verwendet werden. Eine gemeinsame Kennung ist ein intransparenter Zeiger auf einen Edge zwischen einem Google-Konto und einem Ausstellerkonto.
Daher ist zu beachten, dass sich die gemeinsame Kennung weder auf das Google-Konto (bzw. den Nutzer oder eine andere Entität im Speicher von Google) noch auf das Anbieter-/Ausstellerkonto (oder eine andere Rechtspersönlichkeit) bezieht. Es bezieht sich auf die Verbindung zwischen diesen beiden.
Eigenschaften für gemeinsame Kennungen
Die Eigenschaften, die für gemeinsame Kennungen erforderlich sind, beruhen auf bisheriger Erfahrung und technischen Problemen, die aufgrund des Fehlens dieser Eigenschaften in freigegebenen Kennungen aufgetreten sind.
Für die Integration zwischen Google und einem externen Partner müssen die verwendeten gemeinsamen IDs die folgenden Eigenschaften haben:
- Global eindeutig sein:Diese gemeinsame Kennung muss auf genau eine Verknüpfung zwischen einem Google-Nutzer und einem Ausstellerkonto verweisen. Es darf keine andere gemeinsame Kennung für denselben Aussteller mit demselben Wert geben.
- Nicht erraten lassen:Diese freigegebenen IDs enthalten die Berechtigung, im Namen des Nutzers Maßnahmen zu ergreifen. Daher darf es für Dritte nicht möglich sein, den Wert der gemeinsamen ID zu erraten.
- Widerrufbar sein:Eine freigegebene ID kann vom Nutzer widerrufen werden. Durch diesen Widerruf sollte die zukünftige Verwendung des Werts der gemeinsamen ID verhindert werden.
Diese Property hat einige zusätzliche Properties, die:
- Basierend auf einer unveränderlichen Eigenschaft eines der Konten nicht:Wenn der gemeinsame ID-Wert auf einer unveränderlichen Eigenschaft des Kontos des Ausstellers oder des Google-Kontos basieren soll, würde die Wiederherstellung einer widerrufenen gemeinsamen Kennung zum gleichen Wert führen (wodurch der Widerruf rückgängig gemacht wird). Der Wert der gemeinsamen ID darf also keine Eigenschaft des Kontos sein (z. B. eine Telefonnummer).
- Nicht nur <Google-Konto, Partnerkonto>: Es muss ein anderer Wert (z.B. die Zeit) vorhanden sein, um den Widerruf zu ermöglichen.
- Mehrere Verknüpfungen für das Konto auf beiden Seiten zulassen:Es ist wichtig, dass ein einzelner Google-Nutzer durch die Erstellung von gemeinsamen IDs nicht unmöglich ist, eine Verknüpfung mit mehreren Bankkonten herzustellen, oder dass mehrere Google-Konten mit einem einzelnen Bankkonto verknüpft werden können (z.B. ein übergeordnetes und ein untergeordnetes Konto, die beide mit dem Bankkonto des übergeordneten Kontos verknüpft sind). Ähnlich wie die Widerrufsbarkeit gibt es einige Folgen:
- Wie gesagt, nicht auf Grundlage einer unveränderlichen Eigenschaft eines der Konten: Andernfalls hat die gemeinsame Kennung denselben Wert, wenn ein einzelner Google-Nutzer mehrere Bankkonten verknüpft hat (wenn der Wert der gemeinsamen Kennung auf dem Google-Konto basierte) oder wenn mehrere Google-Konten mit einem einzigen Bankkonto verknüpft sind (wenn der Wert der gemeinsamen Kennung auf einer Eigenschaft des Bankkontos basiert).
- Langlebig:Die gemeinsame ID ist nur in einem sicheren Kontext gültig (die Integration zwischen Google und dem Anbieter, bei der sowohl Schutzmaßnahmen auf Verbindungsebene als auch auf Anwendungsebene verwendet werden (z. B. PGP, gegenseitiges SSL usw.). Daher sind keine kurzen Lebenszyklen erforderlich, um sicher zu bleiben. Google empfiehlt, dass die freigegebenen IDs nie ablaufen. Wenn ein Anbieter jedoch eine Ablauffrist benötigt, muss dieser für einen langen Zeitraum festgelegt werden (z. B. > 1 Jahr).
Weitere empfohlene Eigenschaften gemeinsamer Kennungen:
- Base64: Dies vereinfacht die Übertragung und Kommunikation des Werts in der Integration über HTTPS.
- Mindestlänge:Es werden mindestens 27 Ziffern (vor der Base64-Codierung) empfohlen, damit genügend Adressbereich vorhanden ist, um Konflikte zu vermeiden.
Was kann schiefgehen?
Damit die Lesenden die erforderlichen Eigenschaften besser verstehen können, haben wir hier einige Fallstudien aufgeführt, die die Probleme veranschaulichen, die auftreten können, wenn diese Eigenschaften nicht eingehalten werden.
Fallstudien zu geteilten Kennungen
Fallstudie 1: Recycling von Telefonnummern
Ein Aussteller, der die Telefonnummer des Nutzers als gemeinsame Kennung verwendet hat. Als Nutzer A seinen Telefontarif änderte, gab er seine Telefonnummer auf und erhielt einen neuen. Einen Monat später gab die Telefonfirma die alte Telefonnummer wieder. Plötzlich wurde dem neuen Inhaber der Telefonnummer, Nutzer B, eine Rechnung gestellt, die nichts gekauft hatte.
Der Aussteller hatte gegen viele Attribute von freigegebenen Kennungen verstoßen, hauptsächlich Property 1. Dinge wie Telefonnummern können von Nutzer zu Nutzer migriert werden und sind daher nur in einem bestimmten Snapshot einmal eindeutig.
Fallstudie 2: Einfügen
Ein Google-/Partner-Mitarbeiter fügt versehentlich eine gemeinsame ID anstelle eines internen Tools in einen Chat ein. Zusätzliche Schutzebenen verhindern, dass die freigegebene ID böswillig verwendet wird. Google wollte die freigegebene ID jedoch aus Sicherheitsgründen aufheben und durch eine neue ersetzen. Wenn Google/Partner versucht, die gemeinsame ID zu widerrufen, stellt sie fest, dass die freigegebenen IDs nur die Konto-ID des Nutzers im System des Ausstellers sind. Diese wird verwendet, um direkt nach dem Konto des Nutzers zu suchen. Die freigegebene ID konnte daher nicht widerrufen werden, ohne das Konto des Nutzers zu löschen und eine neue für ihn zu erstellen.
Fallstudie 3: Der schlechte Mitarbeiter
Nach dem Einfügen des obigen Vorfalls stellt ein böswilliger Akteur innerhalb von Google/Partner fest, dass, da es sich bei der gemeinsamen Kennung nur um die Konto-ID des Nutzers handelt, er, wenn er es schaffen kann, die Konto-ID einer anderen Person in eine eigene gemeinsame ID einzutragen, Käufe über das Konto dieser anderen Person tätigen kann. Aufgrund eines Verstoßes gegen die Property 2 ist das versehentliche Einfügen nicht nur eine Sicherheitslücke für einen einzelnen Nutzer, sondern eine Sicherheitslücke für jeden Nutzer.
Fallstudie 4: Die Rotation
Nach dem obigen Vorfall zum Einfügen wechselt der Aussteller zu einem UUID als Format für die gemeinsame Kennung. Dieses Mal sendet ein Mitarbeiter des Ausstellers fälschlicherweise einige der freigegebenen IDs als Teil eines Debugging-E-Mail-Threads als Klartext. Laut Google werden wir einfach die freigegebenen Kennungen des Nutzers widerrufen und ersetzen.
Im Rahmen der Rotation teilt Google dem Aussteller mit, dass während der Datenbankbereinigung für jedes manipulierte Nutzerkonto für einen kurzen Zeitraum zwei gemeinsame Kennungen aktiv sind. Der Aussteller hat die Property 4 jedoch nicht zugelassen und teilt Google mit, dass für ein bestimmtes Nutzerkonto nur eine gemeinsame ID aktiv sein kann. Dies führt zu einer sehr unübersichtlichen Rotation mit Race-Bedingungen.