this post was submitted on 12 Jun 2025
82 points (100.0% liked)
DACH - Deutschsprachige Community für Deutschland, Österreich, Schweiz
3968 readers
490 users here now
Das Sammelbecken auf feddit.org für alle Deutschsprechenden aus Deutschland, Österreich, Schweiz, Liechtenstein, Luxemburg und die zwei Belgier. Außerdem natürlich alle anderen deutschprechenden Länderteile der Welt.
Für länderspezifische Themen könnt ihr euch in folgenden Communities austauschen:
___
Aus gegebenem Anlass werden Posts zum Thema Palästina / Israel hier auf Dach gelöscht. Dasselbe gilt zurzeit für Wahlumfragen al´a Sonntagsumfrage.
___
Einsteigertipps für Neue gibt es hier.
___
Eine ausführliche Sidebar mit den Serverregeln usw. findet ihr auf der Startseite von feddit.org
___
founded 11 months ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Was ist denn das Problem mit einer fortlaufenden ID?
Sofern nicht andweitig geschützt, kannst du einfach immer die ID um eins erhöhen/verringern um auf Daten anderer Nutzer zuzugreifen. Bei zufälligen IDs ist das nicht möglich, bzw. sehr unwahrscheinlich.
Genau. Sofern nicht anderweitig geschützt. Das ist das Problem, nicht die fortlaufende ID. Persönliche Daten hinter einer zufälligen ID zu verstecken statt hinter einem Zugriffsschutz ist "security by obscurity". Man kann immer noch mit Brute-Force die Daten bekommen. Der Zugriff ist immer noch möglich, nur dauert er eventuell länger.
Richtig wäre es gewesen jedem Link eine eindeutige Kennung zuzuordnen, die nur Zugriff auf die relevanten IDs hat.
Dieser Spinn "oh, ein Fehler, die IDs waren fortlaufend, passiert schon mal" verdeckt die beiden tatsächlichen Probleme:
Wenn du UUID verwendest und es 10 mio gültige Einträge gibt, und du 1 mio Versuche pro Sekunde schaffst, dann brauchst du rund 78 Millionen mal so lange wie das Universum existiert um irgendeine dieser UUIDs zu erraten.
Das ist keine Secutity by Obscurity, sondern die UUID ist die Authentifizierung.
Security by Obscurity ist dann wenn ein Wissen über den verwendeten Mechanismus ohne Wissen des Geheimnisses (Schlüssel, UUID, Passwort, ...) dazu führt, dass die Sicherheit weg ist.
Sonst wäre Password Authentication oder Signaturen ja auch Security by Obscurity, weil wenn man das Passwort/den Schlüssel weiß, dann kommt man ja auch rein.
Anderweitig geschützt ist aber auch irgendwann nur obscurity. Bei einer normalen 16-stelligen Hexadezimalen zufalls-Id hast du 1.84x10^19 mögliche Kombinationen. Die Chance da jemals eine einzige gültige ID zu finden ist bei 500.000 Kunden nahe 0. Wenn du fortlaufende IDs hast und zB einen 6-stelligen TAN als zusätzlichen schutz ist die chance deutlich höher, dass du etwas findest. Die TAN wirkt sicherer, die Zufalls-ID ist aber sicherer.
Die TAN sichert dich 1:1.000.000 ab
Die Zufallsgenerierte ID sichert dich mit dem Faktor 1:37.000.000.000.000 ab.
Die zufallsgenerierte ID ist also 37 Millionen mal sicherer, als eine 6-stellige TAN, die schon als sehr sicher gilt.
Security by Obscurity ist dann, wenn ein Wissen über den Prozess (nicht den Schlüssel) die Security bricht.
Btw, eine UUID gibt dir 1: 3 400 000 000 000 000 000 000 000 000 000 000 000 000.
Wenn es 10 Mio gültige Einträge gibt und man 1 Mio Einträge pro Sekunde checken kann, dann braucht man im Schnitt 78 000 000 mal so lange wie das Universum existiert um einen Eintrag zu finden.
Im Prinzip richtig, nur hat halt niemand eine TAN erwogen ausser Dir gerade. Und den Grund hast Du ja auch gerade geliefert: bringt nicht so viel
Es wäre sinnvoller einem authentifizierten User ausschliesslich Zugriff auf seine Daten zu geben.
Wie wird der User authentifiziert?
Ich vermute mit einem Authentifizierungscode, der z.B. als Cookie gespeichert ist. Den kann man genauso Brute-Forcen, wenn auf dem Server eine entsprechende Session offen ist, oder wenn jemand einen "Remember me" Cookie hat.
Du endest also schnell wieder bei der "security by obscurity" die du kritisierst. Deswegen haben z.B. Banken einen log-out timer von wenigen Minuten.
Security by Obscurity ist dann, wenn ein Wissen über den Prozess (nicht über den Schlüssel) reicht um die Sicherheitsmaßnahme zu umgehen.
Was Authentifizierungscodes u.Ä. angeht, da vergessen Leute oft wie extrem schnell exponentielles Wachstum geht. Ein 32-bit Schlüssel hat ~4 000 000 000 Varianten. Das ist realistisch knackbar.
Ein 64-bit Schlüssel ist mit 18 000 000 000 000 000 000 Varianten schon deutlich schwieriger.
Bei 128-Bit (wie es z.B. bei UUID verwendet wird), sind es 340 000 000 000 000 000 000 000 000 000 000 000 000 Varianten.
Bei einer Million Versuche pro Sekunden braucht man 780 Billionen mal so lange wie das Universum existiert um eine UUID zu erraten.
Das ist keine Security by Obscurity, sondern einfach Security.
Ja, theoretisch kann man sowas erraten, aber dafür muss man zumindest Gott sein.
Cookies sind heutzutage mindestens signiert, ggfls sogar verschlüsselt. Da irgendwas zu brute-forcen ist praktisch unmöglich.
(Dass deine Geheimnisse geheim sind, das sehe ich mal als gegeben an)
Damit sind es auch nur sehr große Zeichenkettem, die man kaum zufällig erraten kann. Das ändert vom Prinzip des "dümmsten" Angriffs nichts ggü. einer sehr langen zufälligen Zeichenkette als Schlüssel zum Aufrufen eines bestimmten Seiteninhalts.
So lange die Identifikation über die Ferne erfolgt wird es immer darauf hinauslaufen, dass man ein oder mehrere Zeichenketten liefern muss, die zu erraten von der Wahrscheinlichkeit praktisch ausgeschlossen sind.
Wie ich bereits schrieb: praktisch unmöglich.
Bitte genau lesen :)
(Der Smiley zum entschärfen. Ich meine das nicht böse oder überheblich, sondern es ist eine aufrichtige Bitte)
Ich habe TANs explizit genommen weil das bei so etwas wie Hotelbuchungen um die es hier geht der absolute Standard ist. Du rufst eine URL mit einer ID auf und bekommst daraufhin eine SMS mit einem 6-Stelligen Code. Einen "authenfizierten User" will niemand um seine Hotelbuchung zu verwalten, das wäre nur wieder ein Account der irgendwo rumschwirrt.
Der Code ist zwar nur 15 Minuten gültig, aber 15 Minuten reichen problemlos aus, um 1.000.000 Versuche zu machen. Außer natürlich es gibt Bruteforce Detection, aber die hilft bei der 16-stelligen ID genau so.
Ich will auch gar nicht sagen, dass andere Methoden nicht zum gleichen Ziel führen. Ich möchte nur unterstreichen wie extrem sicher zufalls-IDs bereits sind
Nein, das ist nicht "security by obscurity".
Das Problem ist, dass es dadurch trivial ist massiv Daten abzugreifen.
Wenn ich weiß, dass die IDs fortlaufend sind sage ich meinem Programm einfach "wiederhole mit ID+1". Wären es zufällige Werte müsste ich diese vorher kennen oder ich brauche sehr lange bis ich einen Zufallstreffer lande.
Das is vielleicht einfacher, sollte aber beides grundsätzlich nicht möglich sein.
Wenn z.B. UUIDs verwendet werden, dann ist es de facto unmöglich eine andere gültige ID zu erraten.
Es gibt 3.4 * 10^38 UUIDs.
Wenn es 10 mio gültige Einträge gibt, dann braucht man im Schnitt pro richtig erratenem Eintrag 3.4 * 10^31 Versuche.
Selbst wenn man 1mio Versuche pro Sekunde schaffen würde (was per Internet bei weitem nicht möglich ist), dann bräuchte man immer noch rund 10^18 Jahre, was rund 78 Millionen mal so lange ist wie das Universum existiert.
Also ja, theoretisch ist es möglich, so eine UUID zu erraten, aber dafür müsste man zumindest Gott sein.
Im Vergleich zum Aufwand den es braucht um eine fortlaufende ID zu erraten: 1 einziger Versuch.
In der Tat, nur gibt es nicht "die eine" Sicherheitsvorkehrung, die alle anderen überflüssig macht.
Ein weitverbreiteter Fehlschluss ist, dass es ausreicht sich nur darüber Gedanken zu machen, wie man böswilligen Personen den Zugang versperrt. Die Frage ist nicht ob, sondern wann dieser Schutz versagt. Und wenn das passiert ist es wichtig, dass sich überlegt wurde, wie der Schaden, den eine Person im System anrichtet, minimiert werden kann. Und das die IDs für Benutzerdaten nicht einfach erraten werden können, ist eine sehr einfach umsetzbare Möglichkeit einer angreifenden Person Steine in den Weg zu legen.
Wenn man darueber daten oeffentlich zugaenglich macht, kann man durch ausprobieren die daten andere leute finden. Normalerweise sollte man dazu uuids benutzen die eine zufaellige reihenfolge von buchstaben und zahlen nutzen die sich nicht erraten lassen, wie z.b. bei youtube: watch?v=f1kWREjS_rU Kann man zwar theoretisch auch durchprobieren, dauert aber extrem lang bis man damit den naechsten treffer findet.