Konzept #1016
Replace incremented C3S IDs with UUIDs?
| Status: | Zurückgestellt | Start date: | ||
|---|---|---|---|---|
| Priority: | Niedrig | Due date: | ||
| Assignee: | Nico H | % Done: | 0% | |
| Category: | - | Estimated time: | 3.00 h | |
| Target version: | - |
Description
Ist es clever, bei Artist, Files, Creations, Releases, etc. eine fortlaufende Nummer zu verwenden?
Dies könnte später ein Information leakage sein, wie viele Datensätze in der Datenbank sind.
Oder falls eine Schwachstelle existiert, ließen sich so weitere IDs leicht raten.
History
#1 Updated by Thomas Mielke over 3 years ago
- Assignee set to Nico H
Die Objekt-Codes bei Künstlern (z.B. A000000123) oder Werken (z.B. C000000456) oder Releases wollen wir tatsächlich offiziellen nach draußen kommunizieren als C3S-IDs. Für weitere über öffentliche API zugreifbare Objekte benutzen wir uuids. Interne Datenbank-IDs sollen nicht geleakt werden.
#2 Updated by Thomas Mielke over 3 years ago
- Status changed from Neu to Feedback
kann geschlossen werden?
#3 Updated by Alexander Blum about 3 years ago
- Subject changed from Increment IDs to Replace incremented C3S IDs with UUIDs?
- Status changed from Feedback to Zurückgestellt
- Priority changed from Normal to Niedrig
- Estimated time set to 3.00
Wir brauchen auf jeden Fall auch für jedes Hauptobjekt eine (C3S) ID, die man Menschen zumuten kann, damit man sicher über das gleiche Objekt sprechen kann. Ob die auch öffentlich nach außen gelegt werden sollte, ist abwägungssache. Die Bedenken bezüglich Leak/Schwachstelle sind valid und hatte ich auch auf dem Schirm. Wie Thomas schon erwähnt hat, werden für alle Objekte über ein Mixin auch UUIDs generiert, das meiste läuft auch darüber. Die C3S ID könnte jederzeit relativ einfach dadurch ersetzt werden.
Man kann nun streiten, ob ein nur "intern" nach außen legen so viel anders ist, als es gleich öffentlich zu tun. Bezüglich Leak müsste ja nur jemand ein Werk anlegen, um den aktuellen Stand zu haben. Nachdem aber die C3S IDs nicht nur das eigene Repertoire umfasst, sondern auch alle Werke anderer Verwertungsgesellschaften, Duplikate, usw. sollte damit eigentlich nur wenig Information geleakt werden.
Auf der anderen Seite ist mit den C3S IDs die URL weitaus angenehmer für die Nutzer, lässt aber eben das hochzählen zu. Hierfür sollten in jeden Fall sowieso für alle Objekte Tests die (in)validen requests durchprobieren (ohne auth wird sowieso nichts ausgeliefert), was die Chance für einen erfolgreichen Angriff durch ausprobieren wieder verringert.
Unter dem Strich würde ich erst mal bei der C3S ID bleiben, aber sollte noch mal besprochen werden, sobald es in richtung production geht, daher stelle ich das Thema zurück.