Die URLs von Bildern bei StudiVZ
Gerade hat sich StudiVZ zu diesem Bericht geäussert:
Die URL besteht aus:
2006-11/20 = Datum
Ev4M21= Code des Albums
Z3uP7KA-5819 = Code des FotosMal angenommen, ich hätte ein Programm, das 1.000 URLs pro Sekunde nach einem Bild durchsucht. Dann würde die Suche nach einem beliebigen Code, wie beispielsweise Ev4M21/Z3uP7KA-5819, der Zahlen und Buchstaben enthält, viele Millionen Jahre benötigen. Die Kombination des von uns verwendeten Codes ist bedeutend komplexer als die Kombination aus PIN und TAN beim Online Banking. Wir finden, dass unsere Bilder deshalb ziemlich sicher sind.
Auf den Umstand, dass dennoch auf die Bilder ohne Zugangsberechtigung zugegriffen werden kann, geht man nicht weiter ein. naja. Dann schaun wir mal, wie beliebig der Code der Bilder von StudiVZ ist. Alle Galerien wurden heute angelegt, alle sind nach Möglichkeit durch die Userin gesichert, und die Bilder wurden dann im Beisein der das Profil besitzenden Juristin (ich kenne eigentlich zu viele von denen, aber manchmal bin ich darüber echt froh) im Fünferpaket hochgeladen – das sieht dann so aus:
http://217.188.35.147/albums/2006-11/20/5V39z0/BxkkLBT-5231.jpg
http://217.188.35.147/albums/2006-11/20/5V39z0/8VSkLBT-6550.jpg
http://217.188.35.147/albums/2006-11/20/5V39z0/gf4kLBT-1864.jpg
http://217.188.35.147/albums/2006-11/20/5V39z0/615kLBT-1028.jpg
http://217.188.35.147/albums/2006-11/20/5V39z0/1x6kLBT-7533.jpg
kurz darauf dann diese Galerie
http://217.188.35.147/albums/2006-11/20/kVSkz0/kXjz0BT-5042.jpg
http://217.188.35.147/albums/2006-11/20/kVSkz0/w6jz0BT-5068.jpg
http://217.188.35.147/albums/2006-11/20/kVSkz0/xXDz0BT-8892.jpg
http://217.188.35.147/albums/2006-11/20/kVSkz0/81pz0BT-5250.jpg
http://217.188.35.147/albums/2006-11/20/kVSkz0/j9fz0BT-3561.jpg
und dann noch eine etwas ältere Galerie (mit den gleichen Bildern wie zuvor und Bildernamen wie im Screenshot):
http://217.188.35.147/albums/2006-11/20/zT2zz0/M1j6gBT-4500.jpg
http://217.188.35.147/albums/2006-11/20/zT2zz0/hYD6gBT-6063.jpg
http://217.188.35.147/albums/2006-11/20/zT2zz0/kxD6gBT-5591.jpg
http://217.188.35.147/albums/2006-11/20/zT2zz0/1xj6gBT-1901.jpg
http://217.188.35.147/albums/2006-11/20/zT2zz0/20D6gBT-8700.jpg
Ich bin kein Profi, aber ich denke, dass Sparstrümpfe, Eisenkasetten und Tresore doch einiges dem Online-Banking nach StudiVZ-Vorstellungen voraus haben.
Sorry, the comment form is closed at this time.
Ich verstehe nicht ganz worauf du hinaus willst…
Das Thema ist durch. Wenn jeder Besitzer einer URL die Möglichkeit hat ohne Berechtigung ein Bild abzurufen, kann von Sicherheit keine Rede mehr sein.
Liebe Naivlinge,
jetzt Augen zu, Hirn ausschalten, den wirklichen Namen und möglichst alle BBilder hochladen.
also ist BT jetzt userbezogen ja? kann man denn auch einen Zusammenhang zwischen den Zahlen hinten und dem anderen Kram vorne ausmachen? Wobei…pro Album fällt da ja schon mal ein Buchstabe weg, der bleibt ja gleich…
ok nicht nur ein Buchstabe, gleich ne zweierkombi…
@1: Der Herr Alfons will mich darauf hin weisen, dass mein lieber Manni die nächsten Tage verdammt viel Stress haben wird. Dabei ist heute doch erst Montag!
Na, es ist doch so; Die bombensichere Kombination wäre eine solche, wenn alle Zahlen bei jedem Bild anders wären. Das sind sie weder im Album (zo) noch im ersten Teil der Bildnummer (6gBT). Da ist also ein System. Und wie Kulturhistoriker wissen, ist jedes System knackbar. In meinem Fach zum Beispiel gibt es Analysen frühmittelalterlicher Gräberfelder, die mit solchen Übereinstimmungen ganz prima zurande kommen. Für mich sehen solche Dinger aus wie riesige Nekropolen, aber ich bin mir sicher, dass da jemand sowohl eine Chronologie als auch Christleinstufen hineinbringen würde.
Alle Bilder neu kodieren? Schwierig. Komplex. Macht sicher keinen Spass.
Der Vergleich mit dem PIN/TAN Verfahren ist eh Bullshit.
Nach dreimaliger falscher PIN erfolgt beim Online-Banking jedes deutschen Kreditinstitutes eine systemseitige Sperrung. Das PIN/TAN-Verfahren hat sicher seine Schwächen in Bezug auf die Anfälligkeit gegen Phishing, Ausspähen, etc. und krankt daran, ein “ideelles” Sicherheitsmedium (im Vergleich zu einem Hardware-Medium wie einer HBCI-Chipkarte) zu verwenden. Eine Brute-Force Attacke ist bei PIN/TAN jedoch völlig sinnlos.
(Und dabei haben wir noch nicht darüber gesprochen, das viele Institute inzwischen einen bis zu 15-stelligen, frei vom Kunden wählbaren Anmeldenamen einsetzten, der aus einer beliebigen Buchstaben- (groß & klein), Zahlen- und Sonderzeichen-Kombination bestehen kann)
Don kannst du bitte mal die Kommentare von den Kindern hier löschen? (MannisPapa/Mama etc..)
Danke!
Ach bitte, was ich heute schon habe stehen lassen von beiden Seiten, da kommt es auf das auch nicht mehr drauf zam. Wie auch immer:
MÄSSIGT EUCH MAL ETWAS IM TON, ALLE MITANAND!
Okay.
@Hendrik,
aber Du bist Manni, oder? Gib’s ruhig zu. Ist doch nicht schlimm.
Also zahlen hin, lustige Codes her. Dass das NICHTS NULL NADA NIET mit Sicherheit zu tun hat ist jedem klar, der sich mehr als bis mit php auseinandergesetzt hat.
Das ist einfach nur bullshit und wenn das jemand für Geld programmiert hat würde ich mein Geld zurückverlangen.
Alternativ könnte es einfach schon am Konzept scheitern, machts auch nicht besser.
Mal sehen wie lange das sinnlose gestammel noch weiter geht. Evtl. reagiert man ja irgendwann mal GLEICH angemessen auf aufgedeckte Fehler und versucht zu korrigieren anstatt zu beschwichtigen.
Nachtrag – mein “hallo welt”-Codebeispiel wurde rausgefiltert, daher wirkt der erste Satz noch chaotischer als die nachfolgenden – mea culpa.
mir fällt auf, das ich in dem Albumverzeichnis und im ersten Teil des Dateinamens nie ein ‘a’, ein ‘A’ oder ein ‘b’ finde, es fehlen noch weitere Zeichen. in der vierstelligen Nummer hinten scheint nie eine Zahl kleiner 1000 zu erscheinen.
wenn man das berücksichtigt verringert sich die Anzahl der Möglichkeiten schon wieder etwas.
Es gibt beim letzten Nummernblock auch nie eine Null an erster Stelle, richtig.
Im StudiVZ-Blog mach ein Mattematic0r auch ein paar interessante Zahlenspiele (hab ich auch gespeichert, falls es zensiert wird).
Ausserdem gibt es ja die Vermutung, dass ein Teil der IDs von der Uhrzeit abhängt. Wenn man ungefähr weiß, wann die Bilder hochgeladen wurden, kann man damit die Anzahl der Möglichkeiten u.U. weiter einschränken.
Don, falls Du nicht nur Juristen, sondern auch Statistiker kennst…
@11: Ich bin Hendrik.
@14: Ja du verringerst die Zahl der nötigen Versuche um ein paar Stellen hinter dem Komma, falls du recht hast. Vielleicht bist du bei der Jahrelangen Suche nach einem Bild dadurch ein paar Stunden schneller…
http://www.blogbar.de/archiv/2006/11/20/719/#comment-83983
@16: Tolles Zahlenbeispiel ja….
4 Millionen Jahre war sogar großzügig geschätzt vom Manfred, aber wir nehmen diese Zahl mal einfach, um wirklich alle Bilder zu finden.
Sagen wir im VZ liegen 2 Millionen Bilder. Du findest also im Schnitt alle 2 Jahre ein Bild. Hmm du hast recht, das ist gefährlich und lohnt unheimlich. Und ja, welch großer Denkfehler vom Autor.
Herr schmeiß Hirn…
OK, Hendrik, es ist so: Ich bin kein Techniker. Aber da drüben behauptet StudiVZ, dass alle Nummern irgendwie durcheinandergemischt werden. Alle? Wie wir sehen: Nein, nicht alle. Es gibt gewisse gleichlautende Abfolgen. Also stimmt das da drüben formal nicht. Das ist das eine.
Die andere Frage ist, wie lange es dann dauert, um sowas rauszukriegen. Da höre ich mir gern Meinungen an und brauche mir, falls sie auf mich gemünzt sind, nicht solche “Herr schmeiss Hirn vom Himmel”-Bemerkungen anhören. Kann sein, dass Du recht hast. Kann man drüber reden. Kann sein, dass die falsche Behauptung drüben also folgenlos ist.
Aber ich habe dennoch allerschwerste Bedenken gegen einen Laden, der lauthals eine Sicherheit über Kombinationen verkündet, die dann so wie behauptet doch nicht gegeben ist. Keine Ahnung haben ist für mich ok, aber wissentlich die Unwahrheit sagen geht mir zu weit.
@16: Hoppala der Autor sagte gar nicht 4 Millionen wie vom Mattematic0r behauptet. Er sagte viele Millionen, und es wird weit in den zwei stelligen Bereich gehen. Sagen wir also mal du findest alle 10 Jahre ein Bild wenn du willkürlich Zeichketten generierst. Abzüglich geschätzter Zeit, Datum, sonstiger Fakten die den Zufall einschränken schaffst du es vielleicht auf ein Bild pro Jahr. Da läuft jedem Hacker und Stalker das Wasser im Mund zusammen.
So nun ist aber gut, wir sind alle der Meinung, dass das verwendete system schlicht unzureichend und absolut nicht sicher ist. Aber bitte bitte bitte lasst es sein zu versuchen Bild-URL’s erraten zu können. ES GEHT NICHT!
“Herr schmeiß Hirn…”
[Hier stand ein Tipp, den ich hier eigentlich tunlichst nicht lesen möchte. Don auf Empfehlung von Juliane, die jetzt Hunger hat]
Inkriminierende und belastende sind meist nicht irgendwelche Gegenstände drauf, sondern werden zu 80% die sein, wo beteiligte Personen drauf sind.
Abgleichen mit User-IDs, um damit Schindluder zu treiben:
Die Gesichter abgelichteter Personen dann mit real existierenden Personen abzugleichen, ist relativ leicht. Entweder ins real life gehen oder Namen, wahlweise bekannte Nicknames eingeben und die Google Bildersuche und flickr anschmeißen.
Zahlreich sind die weiteren Möglichkeiten, die ich gar nicht wissen will.
@DON, du hast recht, das StudiVZ übertreibt mit der Sicherheit der Zahlenkombo. Sie ist nicht rein-zufällig. Fakt ist jedoch sie ist auf jedenfall zufällig genug. Du kannst ihnen also vorwerfen die Zufallszahl schöner zu reden als sie ist, aber du kannst ihnen nicht vorwerfen das sie nicht sicher genug ist.
Gemach, Hendrik, gemach.
Es hat sich diese Codes noch niemand ernsthaft angesehen. Ich hab schon Sicherheitsanalysen gesehen, da sah es am Anfang so aus, als würde man 2^128 Versuche für den Code brauchen und am Ende waren es fünf.
@Vroni [Hier stand ein Tipp, den ich hier eigentlich tunlichst nicht lesen möchte. Don auf Empfehlung von Juliane, die jetzt Hunger hat]
Wie stellst du dir das vor? Du überlastest den Server und der zeigt dir hoppla hopp einfach so alle Bilder an vor lauter Frust? Oder alle Links? Oder was? Klar kann man den Server konventionell hacken und direkt an die Daten aber davon redet hier überhaupt niemand.
@23: Natürlich hat sich niemand hier den Code genau angeschaut. Solange jedoch niemand hier eine Systematik hinter der URL erkennt, die die Bruteforce Attacke auf ein Niveau von weniger als 10^10 Versuchen reduziert muss man wohl oder übel davon ausgehen das es sicher genug ist.
Schau, Hendrik, es ist so. Ich habe 5 Jahre mit Jungs zu tun gehabt, die mir immer ganz tolle Sachen versprochen haben. Die hatten Charts und Berechnungen und Zahlen und Prozente und Streams und Verfügbarkeiten und Redundanzen und vieles mehr mit Zahlen.
In dieser Zeit habe ich gelernt, niemandem zu glauben, der mit geschönten Zahlen kommt. Es ist wie mit Folter: Es gibt kein bischen Folter. Sobald Leute anfangen, ihre Zahlen schöner zu reden, als sie sind, um von einem guten Wert zu einem perfekten Wert zu gelangen, ziehe ich die Übertreibung gewohnheitsmässig nach unten ab. Nenn mich einen Zyniker, aber Leute, die gut sind, brauchen keine Übertreibung. Solche Projekte sterben mit überzogenen Erwartungen und leben von realistischen Einschätzungen.
Ich habe mir vorhin mal den Quellcode der Bilderseiten etwas genauer angeschaut. Da hat ein Student im 5. Semester etwas daran verbessert und seinen Namen drin vergessen: !– END CHANGED BY MATTHIAS WEIDLICH —
Das ist die Realität hinter den schönen Worten. Da will ich keine Garantien mehr, da will ich eigentlich nur wissen, wie schlimm es wirklich ist.
“Klar kann man den Server konventionell hacken und direkt an die Daten aber davon redet hier überhaupt niemand.”
Das ist der Punkt :-)
Sollte man aber.
[Hier stand ein Tipp, den ich hier eigentlich tunlichst nicht lesen möchte. Don auf Empfehlung von Juliane, die jetzt Hunger hat]
Second life et.al wurden schon gehackt:
http://blog.datenschutzkontor.de/?p=131
_____________________________
Der absolute Hauptpunkt ist aber, soweit ich Don’s Argumentation verstanden habe, dass man fälschlich generell Datensicherheit verspricht, die es nicht gibt.
Ob diese Art “Datensicherheit” “nur” Hackprofis hintergehen können oder “auch” Normalos und Halb-DAUs (nach Don’s Theorie) ist für mich ABSOLUT zweitrangig: Jeder Normalo oder DAU kann, wenn er Bock hat plus wenig Zeit und jemandem schaden will, für ein geringes Entgelt eine Hacker-Crew aus RU oder der Ukraine anheuern.
Don das nennt man nicht vergessen, das nennt man kommentieren. ;-)
Das ein Student im 5. Semester im Template rumschreiben darf finde ich außerdem nicht allzu besorgnis erregend.
Und das du Zyniker und Schwarzmaler bist errät man schnell wenn man deinen Blog liest. ;-) Aber das ist gar nicht schlimm. Allzu häufig decken gerade Leute wie du wichtige Sachen auf. Ich lege ja nur wert darauf, dass die vorwürfe sachlich korrekt und unvoreingenommen bleiben.
Hier liest man ja Horrorvisionen das könnte man glatt an Hollywoord verkaufen. So einfach ist das alles nicht. ;-)
So gute nacht, ich geh pennen. Solltet ihr auch machen.
Freunde, bitte, man kann hier über vieles reden, sogar über meine Person – aber bitte nicht über Strategien, die manche Leute nur auf blöde Gedanken bringen.
Sorry dafür,
aber ich hielt das für bekannt.
Asche über…
Also ich glaube das ganze ist für StudiVZ nicht so einfach zu beheben.
Das eingesetzte Verfahren ist nämlich sehr effektiv, zwar nicht extrem sicher, aber so abgelegt müssen nur statische Inhalte ausgeliefert werden. Wenn jetzt noch eine Prüfung einer Session ID hinzukommt, bringt das ja so direkt mal nichts, man muss ja auch noch prüfen ob der Benutzer der an der Session hängt die Berechtigung für das Bild hat.
Alternativ kann man auch beim erzeugen der Seite für jedes Bild einen Zufallswert erzeugen und sich diesen in einer DB oder in einem geteiltem Speicher merken, wenn dieser Abläuft ist das auch ok.
Aber egal wie man es macht, es wird Aufwendiger und damit braucht man nach Tim Allen MEHR POWER und genau die fehlt dort ja schon, wenn man sich in deren Blog die Beiträge zu deren ISP ansieht, der im übrigen sowas liefern kann, sieht man ja bei anderen, wesentlich größeren Seiten, die er bedient.
MfG AbRaXeS
Die Albennummern sind irgendwie ziemlich frei vergeben. Wenn man beispielsweise folgende drei URLs aufruft, landet man immer auf der gleichen Seite (zufällig ausgewählt):
http://www.studivz.net/showalbum.php?id=TR111
http://www.studivz.net/showalbum.php?id=11111
http://www.studivz.net/showalbum.php?id=XX111
Es gibt noch unzählige weitere Kombinationen, die genauso funktionieren. Auf diesem Weg gelangt man allerdings nur zu Alben, für die man den Zugriff hat:
http://www.studivz.net/showalbum.php?id=g1Bz30
Wenn man das weiter treibt, ist es sehr wahrscheinlich, das man das System dahinter entschlüsseln kann.
Markus
Abraxes, so einfach ist das vielleicht für Tekkies, aber nicht für einen Verantwortlichen. Was StudiVZ macht, ist vergleichbar mit einem Autobauer, der einen Wagen mit guten Bremsen ausliefert, die prima wirken, solange der Fahrer den richtigen Druck auf dem Fuss hat und nicht in der Kurve bremsen muss. Wenn Du in der Wirtschaft etwas versprichst, muss das Teil 20% mehr aushalten, damit es wirklich sicher ist. 20% weniger hat sich im Internet dank Microsoft, Apple und anderer Firmen leider eingschlichen, dass Beta heute als Qualitätsmerkmal gilt – aber in keinem anderen Wirtschaftssektor wäre das vorstellbar.
Es gibt eine einfache Lösung: Entweder man sagt, was Sache ist und weist auf die Probleme hin und riskiert weniger Traffic. Oder man nimmt Geld in die Hand und macht es sicher. Alles andere ist die Wiederaufnahme des Dramas “Warten auf Don Alphonso”.
Markus, aber wenn man den Namen des Albums hat, ist das schon mal ein guter Teil der Miete, weil hinten “nur” 9000 Zahlen sind und vorne ein Block steht, bei dem vier Zeichen immer gleich sind. Uh-oh.
Moment, jetzt wird es spannend, das obige Album kommt auch unter
1V39z0 2V39z0 3V39z0 … 8V39z0 9V39z0
Das heisst doch im Prinzip, dass man lediglich durchprobieren muss, welche Alben nicht aufgehen, und dann…
Ups. Eieieiei. Aber hallo. Da werden aus Jahren aber ganz schnell wenige Tage. Wenn überhaupt.
Don: mit diesem Trick wird die Anzahl der möglichen Alben jedenfalls deutlich eingeschränkt. Beispiel: Wenn ich
http://www.studivz.net/showalbum.php?id=11111
aufrufe, sehe ich die korrekte Album-ID (TR1111) wenn ich mit der Maus über eines der Bilder gehe. Die korrekte ID ist für den direkten Zugriff auf den Bildserver nötig, nicht jedoch bei showalbum.php. Über diesen Weg kommt man aber die Direktlinks der Alben+IDs heran, die man auch wirklich Zugriff auf das Album hat.
Umgekehrt bedeutet das aber auch, das ich sehe, wo sich private Bilder befinden:
http://www.studivz.net/showalbum.php?id=5V39z0
Zeigt bei mir “Du bist leider nicht berechtigt das Fotoalbum zu sehen.”. Damit ist das Album spannend :-)
Markus
Nacht. Der Manni ist jetzt auch im Bett.
Kinners,
es ist mittlerweile klar, dass StudiVZ nur “gebrauchte” PHP-Skripte an Board hat. Das editalbum.php ist 1:1 bei facebook, myvideos und anderen kommerziellen Sites im Einsatz. Dieses Skript generiert diese “mysteriösen” File-ID’s auf Dateiebene. Es ist bezeichnend, dass die beteiligten Coder nicht md5 als wirklich eindeutige Identifizierung einsetzen. Das kann man einstellen oder auch lassen, wenn man keine Ahnung oder Angst hat.
Wenn man dann noch einen Account bei StudiVZ generiert, seine eigenen Alben klassifiziert und dann über den Rest der URL einen Passwort-Scanner laufen lässt, erscheint einem die bunte Bilderwelt des StudiVZ wie ein Telefon-Buch. Ich jedenfalls hatte keinen Schweiss beim Raten der Album-ID völlig unbekannter Studis und der Rest ist handwerklicher Kleinkram.
Noch wesentlich schlimmer ist die Tatsache, dass der DB-Server, der die Bilder nach draussen schickt, auch von aussen manipulierbar ist. Wenn ich dieser Anbieter wäre, würde ich zwischen Auswandern oder Kugel-geben wählen.
Ich find die Urls ohne IP viel schöner, das sieht dann auch irgendwie noch unkryptischer aus …
http://imgsrv.studivz.net/albums/2006-11/20/kVSkz0/kXjz0BT-5042.jpg
http://imgsrv.studivz.net/albums/2006-11/20/kVSkz0/w6jz0BT-5068.jpg
http://imgsrv.studivz.net/albums/2006-11/20/kVSkz0/xXDz0BT-8892.jpg
Und man kann leicht danach in Google suchen [Edit: Satz bearbeitet, Google-Link entfernt -dogfood]
@ 20 (Hendrik)
Die 4 Millionen könnten ein Tippfehler sein, na und? Worum es tatsächlich bei dem Post von Mathematic0r geht ist, dass es gerade mal 5,4 Tage dauert um allein ausgehend von einem Bild (z.B. vom Vorschaubild eines Albums) alle Bilder dieses Albums zu finden.
Findet man also ein Bild, so kann man mit weitaus weniger Aufwand andere Bilder aus diesem Album finden (laut Mathematic0r-Rechnung ca. 5,4 Tage), was im Umkehrschluß wiederum bedeutet, dass sich die Gesamtsuche von vielen Millionen Jahren auf nicht mehr annähernd so viele Millionen Jahre (vielleicht sogar nicht mal Million Jahre) reduziert.
Natürlich ist das immernoch viel, aber wenn sich jemand hinsetzt und noch mehr “Lücken” in diesem Zufallschlüssel findet, reduziert sich das weiter und weiter…
Ich verstehe auch die Kritik, dass man Bilder nicht hochladen soll die man nicht öffentlich haben will, aber zum einen (a) hat nicht jeder dieses Verständnis und u.U. haben solche Leute nicht nur Bilder von sich in ihren Fotoalben und (b) machen die Leute von SVZ genug haltlose Sicherheitsversprechen, die einem weniger versierten Nutzer Sicherheit vorgaukeln (siehe allein den vorherigen SVZ-Blogeintrag “So stellen wir den Schutz eurer Daten sicher” oder die vielen tollen Anonymisierungsfunktionen)…
Last but not least wurde hier schon mehrfach angeführt, dass es genügend einfache Implementierungen gibt die sicherer wären. Wenn sie wegen der weitaus(?) schlechteren Perfomance keine Datenbank benutzen, warum sperren sie dann nicht wenigstens den Zugriff von außen?
Man kann es problemlos auch anders machen und das ist es auch was mich aufregt, stattdessen wird wieder einmal nur heiße Luft verbreitet und gegen die bösen Blogger geflucht, die alles madig machen und eh nur neidisch sind…
Die Aussage der StudiVZ mit dem Vergleich Pin/Tan ist ein Witz (wobei auch das Pin/Tan-Verfahren schon ein Witz ist).
Die Verwendung einer oder mehrere UUIDs in Kombination ist nun wirklich keine Zauberei und würde zumindest das “erraten” nahezu unmöglich machen.
Trotzdem wäre eine richtige Sicherung der Daten der richtige Weg.
Grüße
Mo
Ich dachte eigentlich, es geht hier um die Tatsache, dass eben auch als komplett “privat” eingestufte Bilder von außen erreichbar sind, dass deren URL relativ leicht zu raten ist und dass die URL solcher Bilder sogar bekannt ist, falls sie mal für kurze Zeit öffentlich waren. Mein Xing-Profilfoto ist dagegen nun gerade nicht privat, und das ist auch jedem bekannt, der eines hochlädt.
Zu der Anmerkung, dass man seine privaten Bilder sowieso nirgendwo im Internet hochladen sollte: Selbst wenn ich mich an diese Regel halte, was ist mit (ehemaligen) Kommilitonen, die nicht so datenschutzsensibel sind? Und auf deren Partybildern ich (rein hypothetisch) vielleicht mal in nicht so vorteilhafter Situation zu sehen bin? Lieber nicht drüber nachdenken.
Das Netz ist eine komplett öffentliche Veranstaltung. Wenn das doch endlich einmal in die Köpfe hineinginge!
Meiner Meinung nach ist das vom Don beschriebene
1. eine Lücke von der man erfahren sollte.
2. etwas von dem ich dachte, dass sowas nur Programier-Nullen wie ich machen, weil sie sich nicht anders zu helfen wissen.
Ich bin wirklich nicht immer mit Don Alphono einverstanden, aber die Vehemenz wie aktuell ein Sicherheitsmangel zum Industriestandard erklärt wird, lässt mich vermuten, dass einige Don-Gegner ihre Beißreflexe nicht unter Kontrolle haben. Oder unter der Kontrolle anderer stehen. ;-)
Ein kleiner Test zeigt: wenn ich Bilder in mein Album hochlade und danach den Account kündige, sind diese nicht mehr auf direkten oder indirektem Weg erreichbar. Das ist schon mal positiv. Aber Spuren hinterlasse ich trotzdem:
Testgruppe Öffentlich
http://www.studivz.net/group.php?ids=B2TgRT
Testgruppe Privat
http://www.studivz.net/group.php?ids=8STgRT
Diese beiden Gruppen wurden von dem nicht mehr existieren Account angelegt und sind weiterhin vorhanden. Löschen kann diese keiner mehr.
Markus
Natürlich ist das eine Lücke. Und zusammen mit anderen Schwächen kommt man sehr leicht an die geheimen Bilder. Ein mölicher Angriffsvektor wäre bspw.:
http://crypto.stanford.edu/sameorigin/
(ja, das funktioniert auch mit dem IE)
Szenario wäre bspw. folgendes: Man lockt das Opfer auf seine eigene Webseite – wenn man einander flüchtig kennt, sollte das wohl kein Problem sein ihm einen ink zu schicken. Auf der Zielseite kann man dann umgehend hunderte oder tausende Links auf einen Schlag testen, ob sie von der Zielperson vorher schon einmal besucht worden sind (kann man auch so machen, dass die Person davon nichts mitbekommt, bspw. Links in einen Container setzen der außerhalb des sichtbaren Bereichs ist., dann per Javascript die Linkfarbe der Links checken).
Wir geben die richtigen Antworten auf wichtige Fragen:
1. Der Sinn des Lebens: 42.
2. Die persönliche Integrität eines Geschäftsführers: 00.
3. Die Sicherheit Deiner Daten bei StudiVZ: 3.81520424 × 10^29.
Xing oder openBC (oder wie immer diese Webpage gerade zufällig heisst) als Industriestandard zu nehmen, halte ich für ziemlichen Nonsens. Dieser Abenteurspielplatz für Anfänger im Personalvermittlungsgeschäft wird aus meiner sowieso deutlich überschätzt.
Fakt ist, dass StudiVZ offen die Sicherheitsrisiken ansprechen sollte.
Und IT-Sicherheit sollte nicht unter der Prämisse diskutiert werden, dass es “Sicherheit nicht gibt”. Natürlich könnte StudiVZ ein paar sehr konkrete Redesigns vornehmen und dann wäre die Sicherheit für die Anwender höher.
Zumindest würde ich von solchen Social Networks erwarten, dass die Anwender zumindest die Möglichkeit haben, sich hinreichend über eventuelle Risiken zu informieren, anstatt sich die Info von Diskussionen auf der blogbar besorgen zu lassen.
@ Amelia: Bei mir im Haus wohnte eine Elitestudentin. Die ist auf etlichen offenen Partybildern verlinkt, vom Kaliber sie und 20 leere Flaschen Bier. Den Account hat sie seit Monaten nicht mehr aufgemacht, sonst würde sie vermutlich Amok laufen, aber das steht da einfach so. Nur mal so als Beispiel.
“blogbar-watchblog”-Spammer, das Spiel läuft hier so: Wenn Du Dich erst mal so aufgeführt hast, das Du rausfliegst, fliegst Du immer raus. Es gibt hier keinen Weg zurück, Du kannst gerne bei anderen heulende Kommentare hinterlassen, aber hier bekomst Du keinen Fuss mehr auf den Boden.
Also, ich muß mich (als Techniksachverständiger) ebenfalls größtenteils den technischen Kommentaren anschließen:
1. Die URL-Generierung über zufällige URLs ist nichts schlimmes und kann genauso gemacht werden. Die Frage ist halt nur, wie zufällig die URLs tatsächlich sind. Wenn man das (vertretbare) Risiko eines zufälligen Zufallstreffers in Größenordnungen von 1:500 Mio eingehen kann und will, dann ist die Methode okay. Da wird eine Gefährdung eher hypothetisch.
2. Die Berechnungen bzgl. der Zeit stimmen. Eine solche Hash-Methode gibt ausreichende Sicherheit, wenn der Hash wirklich zufällig und entsprechend lang genug ist. Außerdem kommen da noch Netzwerklatenzen oben drauf.
ABER: Lausig ist …
1. Natürlich müßte man den Zugriff zu den Bildern auch mit dem tatsächlichen Zugriffsschutz überprüfen. Daß das nicht gemacht wurde, ist halt der eigentliche Kern des Zugriffsschutzproblems. Der Haken dabei ist halt nur: das ist für JEDES (!) Bild ein Datenbankzugriff mehr und damit eine substantielle Last auf den DB-Servern. Ansonsten ists halt einfach nur ein statisches File. Ich nehme an, daß man hier (ohne Wertung) simpel und einfach Kosten/Nutzen abgewogen und sich gegen Kosten entschieden hat. Und wahrscheinlich haben die Jungs nicht ganz die technischen Ressourcen von Flickr. Zum Vergleich: Flickr hat über 4 Milliarden Datenbank-Queries am Tag, in Peaks ca. 25.000 Transaktionen pro Sekunde. Friendster fährt ca. 50 Datenbankserver.
2. Man hätte mal tatsächliche Zufallszahlen oder längere Hashes verwenden können und nicht so Kindergartenpermutationen. Da war anscheinend ein Trottel am Werk, nichts hätte gegen einen Bild-URL a la e927e0ae90e97cd6d9a71bb05adf30c2.jpg gesprochen. Tip: MD5 gibt einem wunderbare, garantiert zufällige Zufallszahlen.
Und noch eine Anmerkung dazu: Komisch ist, daß alle bei Brute-Force davon ausgehen, daß man per Saug-Script einfach alle beliebigen URLs ausprobieren könnte. Wenn der Image-Server mit so einem Pseudo-Denial-Of-Service-Attack in die Knie geht, das merkt auch der blödeste Admin. Alleine einen Tag lang permutierte Image-URLs downzuloaden, das fällt auf und ist wahrscheinlich sogar strafrechtlich bedenklich. Ich werfe nur mal StGB §202a und §303a in den Raum. Und jetzt könnt ihr euch juristisch die Köpfe einschlagen, ob die Bilder bei StudiVZ «gegen unberechtigten Zugang besonders gesichert sind». :-)
Achja, und übrigens glaube ich, daß die Chance deutlich höher ist, an Daten zu kommen, wenn mal mal ein paar Attacken gegen PHP-Scripte fährt. So lausig, wie normalerweise mit PHP umgegangen wird, da ist bestimmt was drin. Von simpler SQL-Injection bis zur gezielten Ausnutzung von Bugs.
@50: Dem ist an Sach- und Fachkenntnis aber auch gar nichts mehr hinzu zu fügen! Plus die Aussage, dass es an Naivität/Blödheit kaum zu überbieten ist, privateste Bilder auf einem (wie auch immer, wo auch immer) Webserver abzulegen.
Nein: DIESER Kinderkram ist nicht der Kern des StudiVZ-Skandals; noch nicht mal ein wirklicher Datenschutzskandal, geschweige denn ein DatenschutzGAU. Und sich mit hoher Industriosität ausgerechnet in diesem Sandkasten abzuarbeiten, schadet der gerechten Sache nur.
Also diese mathematischen Ãœberlegungen sind ja sehr interessant. Aber die Conclusio hat Porschekiller[38] gezogen:
“Ich jedenfalls hatte keinen Schweiss beim Raten der Album-ID völlig unbekannter Studis und der Rest ist handwerklicher Kleinkram.”
Die Empirie hat quasi alle mathematisch fundierten Befürchtungen, die hier und anderswo geäußtert wurden bestätigt. Punkt um. Die These des sogenannten “Datenschutzbeauftragten” von StudiVZ
“Sicherheitsbedenken sind unbegründet”
kann somit theoretisch als auch empirisch als widerlegt gelten. Seine Strategie, die Sicherheitsbedenken gegen StudiVZ auf diesen einen Punkt zu konzentrieren, kann außerdem nur als PR-Masche betrachtet werden. Ich frage mal politisch:
Was ist eigentlich die Aufgabe von Datenschutzbeauftragten in Unternehmen? Datenschutz oder PR? Aber das nur ganz nebenbei.
Ich würde im weiteren folgende Strategie vorschlagen, auch um StudiVZ zu zwingen, sich wirklich mal substanziell festzulegen. Ich würde dabei von einer Systematik möglicher Attacken ausgehen und dann StudieVZ daraufhin prüfen (Test-Cases). Hier mein Vorschlag:
1) Wie sicher ist StudiVZ gegen böswillige Attacken, wie sie hier diskutiert wurden. Testfall: Jemand will alle Bilder in einer bestimmten Gruppe, auch wenn die privat deklariert sind. StudiVZ sollte mindestens offen auf die Risiken hinweisen und zwar nicht nur im Kleingedruckten.
2) Wie geschlossen ist die Community? Testfall: Ein Personaler will sich über einen Fake-Account Zugriff auf StudiVZ verschaffen. Vielleicht will StudiVZ das ja gar nicht verhindern. Kann ja sein. Dann wäre StudiVZ aber eher sowas wie eine Mischung aus MySpace und OpenBC-System. (Facebook positioniert sich übrigens schon in Richtung Konkurrenz zu LinkedIn) StudiVZ muss klar Stellung beziehen, ob es überhaupt ein Studentenportal sein will und dann klar kommunizieren, wie es verhindert, dass Personaler eventuell über Auftragsfirmen sich Fake-Accounts beschaffen oder Informanten versichern, die Dossiers über potentielle zukünftige Bewerber erstellen. Es muss also die Community schützen.
3) Welche Gefahren entstehen durch Whistleblower? Testfall: Irgend so ein Don Alphonso aktiviert seine Prätorianer-Garde die mittels anonymer Insider und sonstiger Methoden gezielt innerhalb StudiVZ stöbern und unangenehme Details über Community-Mitglieder herausfinden (z.B. über einen gewissen D.) und dann öffentlich machen (z.B. auch Bild-Urls). StudiVZ könnte z.B. hier juristisch agieren. Z.B. mit Androhung schwerwiegender Strafen gegen Whistleblower. Wäre ja möglich. Müsste aber klar kommuniziert werden.
Fallen jemanden noch weitere Testfälle ein?
Vielleicht sollte man StudiVZ die Chance geben, zwei Wochen in sich zu gehen (Don mach mal Pause!), um dann solche Punkte offen zu kommunizieren.
Brainbomb, die sollen den Bildserver vom Netz nehmen, der steht offen. Dann sollen sie eine technische Lösung entwickeln, mit der nur noch Leute Bilder sehen können, die eingeloggt sind. Sollten sie zumindest.
Ich wette aber mein KPM-Porzellan gegen einen Ikeabecher, dass sie das nicht tun werden. Weil es teuer und aufwändig wäre und bedeuten würde, dass sie zugeben müssen, bislang powered by Holtzbrinck die Daten ihrer Nutzer verschludert zu haben. “Zugeben” ist ein Core Asset, das ihnen fehlt. Wenn Du glaubst, dass sich in zwei Wochen Atempause was ändern würde, dann bist Du sehr optimistisch. Die wollen um jeden Preis wachsen, das ist alles. Deshalb gibt es keinerlei Durchgriffe, noch nicht mal gegen die hier aufgeführten Pornodienstleister bei StudiVZ. Die sind alle noch da.
Don. Dass sich was ändert glaube ich sowieso nicht. Insofern bin ich ganz Deiner Meinung. Der Denkfehler liegt im Geschäftsmodell. Sie können nur Geld machen, wenn sie verkaufen, bevor das jemandem auffällt. Es würde aber eher auffallen, wenn sie die Fragen[52] ehrlich beantworten. Insofern sind sie in einem unlösbaren Dilemma.
“bevor das jemandem auffällt”
Wenn es erst mal bei SPON steht, ist es jemandem aufgefallen.
Dennoch: Auch wenn mich der Fall verteufelt an einen Konflikt 2001 in der Munich Area erinnert (oh Gott ich klinge wie Higgins bei Magnum), in dem es ebenfalls keine Lösung zwischen flipsigster Businessideen und hochkochenden Medien gab, die einen Sündenbock haben wollten, und ihn auch bekamen, weil ihnen die Gründer in die Hände geschuftet haben – selbst in solchen Fällen ging immer noch was. Das Problem bei diesen Personalities ist aber, dass sie es einfach nicht glauben wollen, dass es hier nicht mehr nur darum geht, wie man verliert. Sie wollen den Sieg, sie glauben, irgendwie muss es doch noch zu schaffen sein.
Und deshalb wird sich dort nichts ändern. Ein guter PR-Berater würde reingehen, schauen, welche Ansprüche und Territorien man aufgeben muss, dann der Mehrheit der Kritiker damit ein Friedensangebot machen und dann versuchen, von der Basis aus wieder Vertrauen aufzubauen.
Die Realität sieht dann aber so aus, dass hier gestern ca. 20 Pro-StudiVZ Kommentare von ein und der selben IP kamen, mit 6 verschiedenen Namen. OK, auch auf der anderen Seite wurde mit sowas gespielt, kann man machen, ich bin da noch nicht mal böse – aber es zeigt die Richtung, in die sie marschieren. Geradeaus auf die nächste Mine zu.
Och nööö, das riecht ja böse nach der alten Jamba Leier… Ich frag mich was das für ein Laden ist, wenn die das immer noch nicht gecheckt haben. Mehr oder weniger jeder Blogger hat doch ein Tool laufen, dass die IPs aufzeichnet.
@50 (Die Stimme der freien Welt):
Zuerst schreibst du :
> 1. Die URL-Generierung über zufällige URLs ist nichts schlimmes und kann
> genauso gemacht werden. […] Eine solche Hash-Methode gibt ausreichende
> Sicherheit, wenn der Hash wirklich zufällig und entsprechend lang genug ist.
> […]
Dann sagst du:
> ABER: Lausig ist …
> 1. Natürlich müßte man den Zugriff zu den Bildern auch mit dem tatsächlichen
> Zugriffsschutz überprüfen. Daß das nicht gemacht wurde, ist halt der
> eigentliche Kern des Zugriffsschutzproblems.
Was der ersten Aussage natürlich widerspricht. Entweder du meinst gute Hashes sind gut genug, dass dadurch kein Problem bezgl. des Datenschutzes auftaucht, oder sie sind es nicht. (Wenn man die Benutzerrechte prüft, über bspw. Sessiondaten, dann ist die URL des Bildes ja ohnehin schnurz).
Mir ist nicht ganz klar welche Position du jetzt eigentlich beziehst.
> 2. Man hätte mal tatsächliche Zufallszahlen oder längere Hashes verwenden
> können und nicht so Kindergartenpermutationen. Da war anscheinend ein Trottel
> am Werk, nichts hätte gegen einen Bild-URL a la
> e927e0ae90e97cd6d9a71bb05adf30c2.jpg gesprochen. Tip: MD5 gibt einem
> wunderbare, garantiert zufällige Zufallszahlen.
(Nebenbei: Es gibt keine zufälligen Zahlen, es gibt nur zufällig generierte Zahlen.) Zum eigentlichen: Md5 ist eine hash-funktion, hat also mit “garantiert zufällige Zufallszahlen” nichts zu tun. md5 hashes sind nur dann nicht berechenbar, wenn der an die Hash-Funktion übergebene Eingabewert bereits zufällig ist. Würde bspw. aus User-ID + (fortlaufender) Bild-ID ein md5 hash generiert, und jemand würde das durch ausprobieren merken, dann könnte man sehr gezielt alle Bilder herausfischen – sehr viel einfacher als es jetzt der Fall ist.
Zum Hintergrund (der dir zu fehlen scheint): Das Ziel einer Hash-Funktion ist das möglichst kollisionsfreie mappen von Eingabewerten auf eine Menge von Ausgabewerten, auch (bzw. gerade dann) wenn die Eingabewerte alles andere als zufällig sind. Möchte man, dass andere nicht in der Lage sind die Hashes zu berechnen, muß man entweder seine eigene Hash-Funktion schreiben, oder die Eingabewerte vorher mittels “geheimer” Manipulation erstmal verändern (was natürlich beides im Endeffekt aufs selbe hinausläuft).
> Und noch eine Anmerkung dazu: Komisch ist, daß alle bei Brute-Force davon
> ausgehen, daß man per Saug-Script einfach alle beliebigen URLs ausprobieren
> könnte.
Nein, “alle” sowieso nicht. Ich habe oben in den Kommentaren auf einen “Bug” in allen gängigen Browsern hingewiesen, der es einem ermöglicht, mehrere tausend URLs zu testen ohne auch nur einen Zugriff auf den Server zu machen.
> Achja, und übrigens glaube ich, daß die Chance deutlich höher ist, an Daten zu
> kommen, wenn mal mal ein paar Attacken gegen PHP-Scripte fährt. So lausig, wie
> normalerweise mit PHP umgegangen wird, da ist bestimmt was drin. Von simpler
> SQL-Injection bis zur gezielten Ausnutzung von Bugs.
Was in jedem Falle und zweifelsfrei strafbar ist. Ein bißchen merkwürdig das anzubringen, nachdem man (ohne weitere Erläuterung) die potentielle Strafbarkeit von Brute-Force probieren in den Raum geworfen hat.
Offenbar kann man bei StudiVZ nicht rechnen.
Nehmen wir das Rechenbeispiel von StudiVZ (mit 9.999 x 9.999 Kombinationsmöglichkeiten), dann kommt da tatsächlich in etwa eine Zahl mit “100 Millionen” heraus. Richtig.
So, und rechnet man das dann – gemäß den Vorgaben von StudiVZ durch, so sind nach rund einem Tag (nicht: hundert Millionen Jahre) alle Kombinationsmöglichkeiten errechnet bzw. alle Bilderdaten des Nutzers runtergesaugt.
Ich gehe aber davon aus, dass selbst ein unbegabter Freizeit-Hacker nicht so lange benögtigt. Was sagt eigentlich
das PR-Manöverder Zuständige für “Datensicherheit” bei StudiVZ dazu?(Nee, sowas interessiert den nicht.)
Als privat markierte Bilder sind per URL direkt abrufbar. Das ist ein Sicherheits-GAU.
Ekliger finde ich die offensichtliche Ignoranz und Arroganz mit der mit den Benutzern und den Benutzerdaten umgegangen wird.
Und bitte, es geht nicht um die Aufgabe URLs zu raten. Wenn mein heutiger Kumpel X mir Zugang zu privaten Daten gibt und morgen ist er nicht mehr mein Kumpel, dann habe ich immer noch Zugang zu seinen privaten Daten per URL.
Dass damit auch der ursprüngliche ‘Lieferant’ der Skripte in die Tonne zu treten ist sei nur mal am Rande bemerkt. Wie viele User kumulieren unter den ganzen Facebook Clones?
@57 (Sencer):
1. Zum scheinbaren Widerspruch:
Es kommt halt nur drauf an, was man will. Sozusagen eine Frage der Anforderungen. Heißt: Ja, solange man statische URLs ohne Zugriffsschutz verwendet, sind die URLs potentiell erratbar bzw. ohne Login abrufbar.
So. Ist die Anforderung (a): «Wer die URL kennt, der darf die Daten auch abrufen – aber Erraten der URL darf nur mit unmenschlichem Aufwand funktionieren» – dann heißt die Lösung: Zufällige URLs, die lang genug sind.
Ist aber die Anforderung (b): «Bilder darf ein User nur mit vorherigem Login» angucken, dann gibt es technisch keine andere Möglichkeit, als die Session abzufragen und das Bild über einen dynamischen Zugriff auszuliefern. Mit allen Folgen die dran hängen.
Persönlicher Kommentar: Ich hätte mich persönlich für Anforderung (a) entschieden und den Usern mitgeteilt, daß Bild-URL weitergeben unabhängig vom Zugriffsschutz ist. Ich kann ja schließlich anstatt des URL auch das Bild selbst weitergeben, sobald ich einmal drauf Zugriff habe. Das macht keinen Unterschied.
2. “Zufällige Zahlen” sollte ein lustiges Wortspiel sein. War anscheinend nicht lustig, aber egal :-)
3. Ich weiß, was MD5 ist. Danke für den klugen Hinweis. Ich meinte damit, daß ich einfach den MD5-Hash der Datei selbst als URL nehmen würde. Damit muß ich mir nix zufälliges ausdenken. Eine rand()-Funktion tuts aber sicherlich auch. Die User-ID würde ich da sowieso nicht mit reinnehmen. Und daß fortlaufende Bild-IDs bescheuert sind, ist auch klar. Ich wollte den MD5-Hash aber auch nicht aus User- und Bild-ID generieren, sondern aus dem Binär-File selbst. Aber wie gesagt, rand() tuts auch.
Danke, daß Du Dir Sorgen über fehlende Hintergründe machst, das ist aber nicht notwendig.
4. Deine Anmerkung mit den Browsern stimmt, aber das ist kein spezifisches Problem dieser Site. Außerdem heißt das, daß Du einen Server mit Schadcode ins Netz stellen mußt, auf den die User erstmal zugreifen müssen. Das funktioniert nicht in der Breite und fällt auf.
5. Natürlich sind Attacken gegen PHP-Scripte strafbar. Es ging mir ja auch nicht um das Tun, sondern nur um potentielle Sicherheitslücken. Ich habe niemals behauptet, daß das legal sei.
So – what’s the problem?
By the way, heise berichtet:
http://www.heise.de/newsticker/meldung/81373
Hey, spinn ich?
Gerade wollte ich hier folgende Nachricht eintragen:
———————–
Man kann übrigens auch die Alben von verborgenen Profilen sehen. Wer sein Profil nur seinen Freunden zugänglich macht, bei dem verschwindet auch der Link zu den Foto-Alben für alle Nicht-Freunde. Den Link zu erraten ist kein Problem und: er ist gültig. Man bekommt die Alben angezeigt.
Unter Umständen ist es jedoch so, dass nur Alben angezeigt werden, die mit “dürfen alle sehen” markiert sind. War zu faul das auszuprobieren. Wenn “nur Freunde” wirklich vor unberechtigtem Zugriff schützt, ok, dann läge auch ein Versäumnis beim User. Aber: Dass der Link im Profil nicht angezeigt wird, könnte eine falsche Sicherheit vorgaukeln und in Sicherheit wiegen. Insofern wäre es besser, wenn der Link zu den Alben einfach auch bei geschützten Profilen in der Linkleiste erschiene.
———————–
dachte “nochmal checken” und siehe da: auch bei verdeckten Profilen sind nun die Alben sichtbar UND die Liste der Freunde. Und bei letzterem spinne ich bekanntlich jedenfalls nicht http://fx3.org/blog/2006/11/21/studivz-unseren-tglichen-privacy-gau-gib-uns-heute/
Das grundsätzliche Problem ist einfach, dass ist grundfalsch ist, private Bilder so zu “verstecken”. Ohne zu technisch zu werden aber: verstecken heißt immer, dass man etwas auch (wieder) finden kann. Was aber hier benötigt ist schlichtweg Autorisierung. Also, darf Benutzer a Bild b ansehen oder nicht. Das ist die einzige Frage zu zählt und es ist schlichtes Unvermögen, das anders zu handhaben, vor allem angesichts der Tatsache, dass es andere Möglichkeiten gäbe. Wie hoch die Wahrscheinlichkeit ist, ein solches Bild zu finden, ist im übrigen vollkommen egal. Vor allem deswegen, weil die Abfragen relativ beliebig parallelisierbar sind. Das heißt: hat mein Programm, das mir die Bildchen abruft zwei Threads, dann geht es doppelt so schnell, spawnt es vier, dann eben viermal so schnell usw. usf. Somit ist es am Ende eine finanzielle Frage, wie lange das braucht, denn es hängt schlichtweg davon ab, wieviele Rechner ich mir kaufe und wie untalentiert der Typ ist, der mir das implementiert.
@Lars(63): Denk nochmal drüber nach, warum kryptographische Schlüssel so lang sind.
Ich kann das Gerede vom Super-GAU grad nicht so nachvollziehen…
Bevor ich die URLs der Bilder rate/errechne und Testanfragen an den Server schicke, kann ich das nicht gleich mit dem Passwort machen?
Überschriebene Nutzerbilder werden i.Ü. auch nicht sofort gelöscht.
Jorge(65), mit den Bilder-URLs geht es halt viel viel einfacher.
@flawed:
Ist die (halbwegs) zufällig generierte URL eines Fotos wirklich leichter zu erraten als das Passwort eines typischen Users?
Ich geb zu, nicht viel Ahnung von Sicherheitsstandards zu haben. Wenn aber selbst heise.de die Meldung “Datenleck beim StudiVZ?” nur als Frage formuliert, mit den offenen Profilen anfängt und erst im unteren Teil die Sache mit den Bilder-URLs meldet, dann fällt’s mir schwer, eure Aufregung nachzuvollziehen.
Ja mach doch mal: Zeig uns doch mal simpelsten Mitteln ein Foto, dessen URL du vorher nicht kanntest.
Jorge: Ja, weil es mit dem Zufall in diesen URLs nicht allzuweit her ist. Schau mal in die Kommentare von beissreflex im anderen Artikel zu den Bildern hier.
Jorge: Deine selektive Wahrnehmung ist wirklich bemerkenswert. Der Heise-Artikel beleuchtet in seiner Antwort nämlich sehr schön, in welchem Widerspruch StudiVZ-PR, FAQ (“Nur Name und Bild”) und Realität zueinander stehen.
Dass man sich ursprünglich einen Tag Bedenkzeit für die Anfrage erbeten hatte und die ja angeblich nicht vorhandenen Probleme inzwischen klammheimlich bearbeitet wurde, passt da wunderbar ins Bild, findest du nicht?
Security by Obscurity
Nachdem dieses aufgedeckt wurde, behauptet der Datenschutzbeauftragte von studiVZ jedoch weiterhin “Die Sicherheitsbedenken sind unbegründet”. Das ist dann doch schon etwas starker Tobak, weshalb hier ein wenig auf das zugrundeliegende Prinzip (Secur…
[…] Es geht Schlag auf Schlag. Nicht nur Bilder sind unzureichend geschützt, auch andere Bereiche der Seite weisen massive Lücken auf. Während diejenigen, die auf Lücken aufmerksam machen darauf achten, dass in ihren Kommentaren keine Anleitungen gepostet werden, sieht man das im Blog von StudiVZ offenbar nicht so eng. […]
[…] Oh no, some people even come into my space and copy the pictures of my friends. They save them and upload them to their discussion group – and then they rank them. And make strange comments. And they write how sexy my friends are. I wonder if my friends really wanted this too happen, being oggled at by strangers. […]
[…] laufenden. von Oliver reaktionen auf diesen beitrag via rss 2.0 dein kommentar hierzu oder trackbacks ähnliche artikel: studivz saubillig | mitleid | links for2007-01-09 | das macht (meinen/der) tag | ja wenn … studivz | 2 Feedbacks zu “studivz goes radio” hep-cat.de […]