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:
Zugriff auf persönliche Daten ohne Authentifizierung
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.
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.
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.
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
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”.