Seit einigen Tagen ist das Startup StudiVZ stark unter Beschuss. Mittlerweile kann man fast täglich eine neue Geschichte über eine Sicherheitslücke lesen. heise.de fängt auch schon an in neuen Artikeln die Chronologie zur fortlaufenden Geschichte aufzulisten.

Interessant finde ich, wie nun die laut StudiVZ mit starker Verschlüsselung chiffrierte ID die dort jedes Nutzer-Profil hat, entschlüsselt wurde.
Dieser führt Blog-Beitrag führt vor, wie ID mit ein wenig Grips auseinander nimmt.

Als Lektüre ist das meines Erachtens sehr empfehlenswert.

Ein Schutz, der nur aus einer relativ kurzen Url-Adresse besteht, ist doch kein Schutz. Und wenn lediglich die Nutzer-ID mit einem feststehenden Algorithmus auf eine Adresse (und umgekehrt) umgerechnet wird, dann ist das albern - da nimmt man sich ein paar Kombinationen, sieht sich die Bitwerte an und hat das.

Allerdings gab es ähnliche Dinge auch mal bei der Telekom, wo auch interne Nutzer nur die Zahlen am Ende ihrer Url ändern mußten, um Daten anderer Personen lesen zu können.

Genaugenommen ist das nicht 'bloß ein Datenschutzproblem', sondern eine völlig falsche Sicherheitsarchitektur, die sich jetzt eben an diesem Beispiel zeigt. Wer weiß, wie unsicher dann die wirklich kritischen Dinge (Schreibzugriff) sind, wenn schon bei solchen Banalitäten so etwas auftaucht.

Ja, die Webapps sind leider die meisten in einem solch traurigem Zustand...

Die Architektur an sich ist da in jedem Fall das Problem.
Die ID ist ja nur der Wegbereiter und gibt keine Auskunft darüber, ob man nun Berechtigung hat auf den Inhalt hinter zuzugreifen oder nicht.
Die ID ist ja auch konstant und verfällt nicht irgendwann.
Problem ist, das an manchen Stellen scheinbar die Berechtigung geprüft wird und an anderen Stellen einfach nach dem Motto "wenn der Link von unserer Webseite so generiert wurde, dann muss ja vorher die Berechtigung schon dagewesen sein" verfahren wird.

Und wenn dann auch noch verschiedene andere Schnittstellen offen sind, die Hinweise geben (/?id=123 gibt ungeprüften Zugriff wo der "normale" Zugriff /?ids=xyz auf Berechtigung prüft), dann produziert man ausreichend Motivation nach weiteren Schwachstellen zu suchen.

StudiVZ hat es schon mehrere Tage am Stück an Position 1 von Technorati geschafft. Wenn das nicht rekordverdächtig ist :-).

Eine gute Zusammenfassung des ganzen Themas gibt es hier:
http://blogs.lueke.info/unverkaeuflich/200...e-sorgenfreien/

hihi, also ich finde es irgendwie schon lustig
Bei uns gibt es inzwischen auch "Nachbauten" von StudiVZ, mal sehen wie lange es dauert, bis deren Schwachstellen verbreitet werden.

Wurde offenbar schonwieder geknackt..

Zuerst sollte man seine Passwörter aktualisieren, danach das da:

Können die sich bei 100 Millionen noch nichtmal eine ordentliche Sicherheitslösung leisten? Tz..

Kurze Zwischenfrage: Meint ihr, dass die die Passwörter unverschlüsselt in der Datebank abspeichern? Oder warum musste sich jeder Nutzer ein neues erstellen lassen?

kann ich mir gut vorstellen :-)

Es gab eine Lücke, bei welcher die Passwörter ausgespäht werden konnten...

Hallo,

selbst wenn Sie die Passwörter als md5 Hash speichern, wenn jemand eben diesen bekommt kann er mit einer genügend großen Datenbank in kürzester Zeit das Passwort bekommen.
Und solche Datenbanken gibt es, da bin ich mir sicher :-)


(wenn ich auf die Idee komme, dann sicherlich die "richtigen" Freakz erst recht)


Also es macht keinen Unterschied ob das Passwort verschlüsselt wurde oder nicht.
Wenn die Zugang zur Datenbank bzw. den "Passwörtern" bekommen haben, können die sicherlich was damit anfangen.

Sorry Leute, aber ich liege gerade am Boden und lach mich flach!

Das ist der Witz des Tages.....das beste, die Server sind so überfordert mit dem Versenden der Passwörter, dass sie es mittlerweile selbst auf der Webseite geschrieben haben.

Ich werde auch ein 08/15-Projekt in die Welt setzen, 100 Mio. dafür kassieren und das ohne auf irgendwelche Sicherheitslücken zu achten. So bin ich reich und die neuen Besitzer haben das Problem!

Da sind denen ja die kleinen Anbieter, wo man sagen muß, die haben teilweise auch über 100k User, bei weiterem vorraus was die Sicherheit betrifft.

Mich würde nur interessieren, was die jetzt alles genau für Daten haben. Und wenn die die PWs im Klartext speichern, dann ist das grob fahrlässig.

Nennt sich dann Rainbow-Tables und existiert in der Tat bereits. Komplexe Passwörter, insbesondere auch mit Sonderzeichen sind aber dennoch recht sicher, da es keine "Kompletten" Rainbow-Tables geben kann. .

ja das mit den Rainbow-Tables stimmt, aber leider verzichten immer noch SEHR viele Anbieter auf das Hashing von Passwörtern (warum auch immer - denn für mich ist es das erste in meinem Skript).

Und auch nicht selten werden solche Anbieter (erstaunlicher weise nicht einmal unbekannte/unsensible), wie z.B. damals layerads.de und euros4click.de gehacked und diese Daten kursieren dann im Netz (meistens sind es Standartpasswörter, sodass weitere Daten/Konten von einem User "gehijacked" werden..).

Ich krieg jedes mal ein Schrecken wenn ich irgendwo mal das Passwort vergessen habe und prompt eine Email mit meinem "unverschlüsselten" Passwort erhalte.

Hallo an alle,

so nun hat es auch endlich Focus-Online.de bemerkt und berichtet darüber:

Daten-Gau bei StudiVZ - Focus-Online.de - 28.02.2007

Und wer hat es geahnt.... richtig Ayom.

gruss Björn

Nun ja,
also ich denke mal nicht, dass die Passwörter unverschlüsselt in der DB liegen.
Aber mit Rainbowtables ist das nicht das Ding. Wie schon gesagt wurde kommen diese bei langen Passwörtern mit vielen Sonderzeichen nicht weiter. Aber sind wir mal ehrlich:
Susanne, Philosophie-Studentin, fünftes Semester nimmt ihren Handypin als Passwort:-)
Hashen hilft da auch nichts. Wenn der "Hacker" erstmal in deinem System drinnen ist, ist es zu spät.

Man muss dazu sagen, dass studivz auch gerade das Ziel von sehr vielen Angriffen ist weil
1. Die "Bildungselite" dort Konzentriert ist
2. Sie provozieren stark rum(z.B. die Geschichte mit der Gegendarstellung des CCC im studivzeigenen Blog)

Irgend wie beneide ich ja die Leute von Studivz. Übernehmen ein erfolgreiches Konzept nach Deutschland. Und haben das Marketing-Potenzial das umzusetzen. Mit Programmierung hat das wenig zu tun(die 30 Programmierer trinken Kaffee und zwei arbeiten). Wenn wirklich alle 30 Programmieer gut ausgebildet und voll dabei wären könnten sie wöchentlich die Community einmal neu schreiben. Marketing ist halt alles:-( Genau wie das doofe MySpace..wobei bei denen schon fast alle Sicherheitslücken gefunden wurden, glaube ich.

Problematisch sehe ich die ganze Sache, wenn es doch zu einem erheblichen Datenklau gekommen ist. Ich denke das es einige Nutzer gab die Ihr Passwort welches auch für den Login ihres Mailaccount genutzt wird, angegeben haben. Somit könnten diese Daten jetzt für erheblichen Unfug benutzt werden. Spamming wäre da das kleinste Übel.

Die Wirkung einer solchen Meinung zeigt sich in den Sicherheitslücken, von denen dieser Thread handelt.

Quick, dirty - and open.

Sicherheit ist doch eigentlich SOOO einfach... Ich kanns kaum glauben... Langsam wird das definitiv zum Kavaliersdelikt... Furchtbar!

Ein Tutorial von mir für sichere Passwörter, die sich nicht mit Rainbow-Tables knacken lassen: http://www.cybton.com/tutorials_show,Siche...0,tut,1463.html
Wenn man sich an das Tut hält, ist man genau bei einem solchen Angriff sicher.

Eine grosse Rainbow-Table online zum Testen der eigenen PWDs ist übrigens z.B. gdataonline.

Die wichtisten Regeln:
- Passwort-Hashes generieren, die am besten gemäss einem eigenen Algorithmus verschlüsselt werden sollten (am sinnvollsten ist eine Weiterverarbeitung des MD5-Hashes)
- JEDE Variable, die vom User/Browser kommt, muss "entschärft" werden. Sogar der Browsername oder die Sprache müssen mit addslashes() für Logs mit Slashes versehen werden! Genauer:
* Datenbanken: addslashes(), falls magic_quotes off (gegen MySQL-Injections)
* URLs: urlencode() (gegen XSS)
* HTML-Text: htmlentities() (gegen XSS)
* Mail-Header-Daten: Zeilenumbrüche entfernen (gegen Spam)
* JavaScript-Alerts & Co.: addslashes() und htmlentities() (je nach Bedarf, gegen XSS)
- Single Quotes im HTML-Code vermeiden (In diesem Beispiel ist die vom User eingegebene Bildbeschreibung rot hervorgehoben: <img src='bild.jpg' alt='bild' width='1000' height='1000' onmouseover='...' />, gegen XSS) ODER bei htmlentities() als zweite Variable die Konstante ENT_QUOTES verwenden, die auch Single Quotes umwandelt.
- POST-Formulare (v.a. für E-Mail-Adressen- und Passwortänderung): In einem HIDDEN-Feld die Session-ID mitsenden, den Referer checken (kann evtl. umgangen werden) oder das Passwort in jedem Formular mitverlangen (schlecht für die Usability). Scheint auf Ayom nur teilweise geschlossen zu sein. (Notizen können von aussen geändert werden, jedoch ist das nicht weiter schlimm. Trotzdem sollte es behoben werden.) (gegen externe AutoSubmit-Formulare)
- GET-Formulare für Änderungen (UPDATE- oder INSERT-Befehle) vermeiden. Abfragen sind jedoch erlaubt. (wichtige Variablen stehen sonst in der URL und können von externen Anbietern aus dem Referer gelesen werden, oder aber es existiert dasselbe Problem wie bei POST)

Wenn man diese wenigen Regeln befolgt, hat man bereits 99% der Angriffe abgewehrt.

Ayom ist in dieser Hinsicht Vorbild (Im Vergleich zu phpBB, StudiVZ und vielen anderen wirklich VIEL genutzten Services).