News Sicherheitsexperten kritisieren diverse Mängel bei Mega

Zur Deduplizierung im Falle von Mega:

Diese kann in 2 Fällen greifen:
Ein User lädt eine exakt oder in Teilen gleiche Datei 2x im gleichen Account hoch. Die gleichen teile werden dann nur als Referenz gespeichert.
Ein 2. User kopiert sich eine Datei von User1 in seinen Account. Auch hier wird die Datei nicht neu verschlüsselt sondern als Referenz übergeben.

Was noch möglich wäre, aber anscheinend nicht gemacht wird:
Dateien werden mit einem aus der Datei abgeleiteten Wert verschlüsselt - Damit kann man besser deduplizieren (macht Dropbox z.B. so - wenn eine Datei irgendjemand schon hochgleaden hat, ist sie sofort "hochgeladen"), hat aber für den User den Nachteil, dass man z.B. legal eine 1:1 Kopie einer CD in seinem Account hat, jemand anderer aber genau diese daten öffenltich zugänglich macht, abgemahnt wird und die Daten geblockt/gelöscht werden. Damit kann dann niemand mehr, der eventuell alles richtig gemacht hatte die Daten verwenden. Eigentlich sollte ein Betreiber bei sowas ja nur die Veröffentlichung verbieten, viele Betreiber gehen aber einen Schritt weiter und blocken dann gleich alles und ignorieren das Recht auf Privatkopie.


Zurück zu Mega: Dedupliziert wird also nur NACH dem verschlüsseln und verschlüsselt wird offenbar mit Werten die nicht nur aus dem Dateiinhalt stammen sondern auch vom User kommen (Passwort etc.). Allzu häufig dürfte das dann ja meiner Meinung nach nicht greifen, andererseits kann's ja sein, dass (wegen Trafficbeschränkungen) es üblich werden wird, alles was man laden will temporär in den eigenen Account der noch Traffic hat zu übernehmen und runterzuladen. Damit würde man ohne diese Art von Dedup auf Mega's Seite hohe Last erzeugen...
 
Gibt es Mega bisher nur für Google Chrome? Mit dem Firefox bekomme ich die Meldung, dass ich große Dateien nicht downloaden kann.

Außerdem stelle ich beim Download mit Chrome fest, dass ein CPU Kern zu 100% ausgelastet ist und der Download bei 2.2MB/s feststeht. Haben wir hier ein CPU Limit?
 
Artikel-Update: Das Blog der Gruppe fail0verflow hat sich der Sicherheit der Mega-Webseite angenommen. Wer über die Webseite anstatt über Clients auf Mega zugreift, muss ja der Seite vertrauen können. Dieses Vertrauen sehen die Tester als nicht gerechtfertigt an. Das geschilderte Szenario wirkt allerdings auch nicht besonders durchdacht. Auf dem Mega-Server liegt lediglich eine index.html, die alle anderen Inhalte von den Servern des sogenannten Content Distribution Networks (CDN) in Form von Javasript-Dateien nachladen. Da es sich hier um Server handelt, die von Partnern von Mega betrieben werden, sollte die Implementation absolut wasserdicht sein. Das scheint aber nicht so, denn zur Sicherstellung der Unversehrtheit des nachgeladenen Codes verlässt sich Mega auf ein bekanntermaßen ungeeignetes Verfahren namens CBC-MAC, anstatt beispielsweise auf das bewährte SHA256 zu vertrauen. Der englische Wikipedia-Artikel zu CBC-MAC warnt ganz klar: „...This example also shows that a CBC-MAC cannot be used as a collision resistant one-way function: given a key it is trivial to create a different message which "hashes" to the same tag.“ Also kann eine dritte Person mit Zugriff auf einen der CDN-Server fremde Inhalte einschleusen, ohne die Identitätsprüfung zu irritieren. Weiß man dann noch, das einige der Server der Mega-Partner derzeit nur mit 1024-Bit verschlüsseln, gibt das doch zu denken. Im erwähnten Blog kann man das Verfahren anhand einer Demo selbst testen.
 
Als ob Mega der einzige Anbieter dieser Art ist, welcher solche Probleme hat. Warum wird das bei Mega so gehypt???
 
Weil um den ganzen Start schon so ein Hype gemacht wurde und Mega ganz fett (und Kim auch) mit diesem schönen "Bigger. Better. Faster. Stronger. Safer."-Slogan wirbt, den sie nicht einhalten können.
 
Nur 1024bit Verschlüsselung, äh, das mich klingt das nach recht viel... :o War nicht vor "kurzem" noch 128bit oberer Standard?
 
Kimble hat sich bisher mit allen Wassern gewaschen gezeigt, man möge mir diesen kleinen Applause für den Dickbauch verzeihen, aber ich denke mal das jeder Schritt den er tut absolut Wasserdicht ist. Ich halte ihn einfach nicht wirklich für so blöd das er nachdem er das volle Augenmerk seiner Missgönner auf seiner Seite hat sich hier Fehler leisten würde. Er wusste schon bevor er MEGA angekündigt hatte das er auf dem Mikroskop liegt. Sorry, auch wenn er "streng genommen" ein Verbrecher ist, isses nicht von der Hand zu weisen das es ne coole Sau ist. So leicht kriegen se den nicht.
 
Ein Wort: BETA!

Wie manche Leute sich immer direkt die vergoldete Platin-Armbanduhr wünschen.. Primär steht erst mal die Funktionalität im Fokus; im Verlauf der Nutzung wird man dann auch Fehler finden, um diese dann beheben zu können. Das ist nunmal das Prinzip einer BETA-Phase.
 
Smagjus schrieb:
Außerdem stelle ich beim Download mit Chrome fest, dass ein CPU Kern zu 100% ausgelastet ist und der Download bei 2.2MB/s feststeht. Haben wir hier ein CPU Limit?

Das liegt einfach daran, dass Javascript nie für solche Anwendungen ausgelegt war bzw. es nie musste. Und die Webseite wird auch nie so sicher sein, wie eine richtige Client-Software. Dass es auch nur in Chrome halbwegs läuft, macht es auch nicht wirklich praxistauglicher.

Da ist aber auch die Frage, ob es bei dem ganzen Verschlüsselungskram wirklich um den Schutz der User-Daten geht oder doch etwas anderes dahinter steckt.
 
Bin mal gespannt, was dabei raus kommt:
KimDotcom schrieb:
We welcome the ongoing #Mega security debate & will offer a cash prize encryption challenge soon. Let's see what you got ;-)
Quelle: Twitter
 
ice-breaker schrieb:
Der Deduplizierung ist egal, ob die Daten verschlüsselt wurden oder nicht, aber wenn (wie korrekt von dir genannt) die Daten alle unterschiedlich aussehen - da scheinbar zufällig zusammengewürfelt - ist es für die Deduplizierung eben sehr schwierig gleiche Blocke zu finden.
Irgendwann wird die Anzahl der unterschiedlichen Chunks aber auch erreicht und spätestens ab dann, kann man alles nur noch per Referenz verweisen lassen. Bei 4 KB großen Blöcken, ist es ja nicht so "unwahrscheinlich", dass irgendwas referenziert werden kann. Weit schlechter sähe es da schon bei 1 MB aus.
T0a5tbr0t schrieb:
Und die Webseite wird auch nie so sicher sein, wie eine richtige Client-Software.
Ich geh mal davon aus, dass irgendwann auch wieder ein Mega-Client kommt, wie bei MU auch. Spätestens damit sollte die JS-Engine keine Blockade mehr sein.
 
MrChiLLouT schrieb:
Das Sicherheitskonzept muss aber zu Erst stehen, sowas kann man nicht später einfach reinpatchen und gut ist. Wenn Mega z.B. ein Kryptographie-Problem mit dem Encodieren der Uploads gemacht hat (zu schwache Verschlüsselung, schlechter Blockmodus beim Chiffrieren etc.) dann ist das fix, alle Uploads bis zu dem Datum können nicht mehr geändert werden.


Yuuri schrieb:
Irgendwann wird die Anzahl der unterschiedlichen Chunks aber auch erreicht und spätestens ab dann, kann man alles nur noch per Referenz verweisen lassen. Bei 4 KB großen Blöcken, ist es ja nicht so "unwahrscheinlich", dass irgendwas referenziert werden kann. Weit schlechter sähe es da schon bei 1 MB aus.
Ja da bin ich mir noch echt unsicher. Bei 4KB sind es ja 4 Millionen mögliche Blöcke, da wird schon viel referenziert. Dann müsste der Lesekopf einer HDD beim Auslesen einer einzelnen 1MB Datei aber schon so oft springen, dass man den ganzen Server killt. Also muss die Blockgröße dafür beträchtlich steigen, aber dann sinkt wieder die Möglichkeit für gleiche Blöcke.

Hat da jemand Informationen wie ZFS das macht? Deduplication soll bei ZFS so gut wie keine Performance kosten, also muss es irgendwie gehen.
 
Warum wird eigentlich so ein Wirbel um dieses Mega gemacht? Das ist doch nur ein weiterer Cloud-Service-Anbieter wie Dropbox, GoogleDrive und all die zahllosen anderen. Oder?
 
Schmitz ist wirklich als mehrfach Vorbestrafter, eine Vertrauenswürdige Institution die einen Dienst unter Zuhilfenahme einer Verschlüsselung anbietet.:lol:
Nicht mal einen benutzten eingescannten Schlüpper würde ich in seiner Cloud anlegen.

Haft Nr. 1 und Haft Nr. 2

Im März 1994 wurde er für den Handel mit gestohlenen Telefonkarten-Nummern verhaftet. Er saß einen Monat im Gefängnis und wurde kurz nach seiner Entlassung wegen weiterer Hacking-Vergehen erneut verhaftet. 1998 erhielt er wieder zwei Jahre auf Bewährung für einige weitere Vergehen.

Lufthansa-Deal

Schmitz nutzte seine Bekanntheit, um sein Sicherheits-Geschäft zu pushen. Seine Firma Data Protect unterzeichnete einen Vertrag mit der Lufthansa, nachdem Schmitz eine scheinbare Sicherheitslücke aufgedeckt hatte. Später stellte sich heraus, dass er mit einem Lufthansa-Mitarbeiter zusammengearbeitet und sich die Hacker-Fähigkeiten eines Komplizen zu eigen gemacht hatte.

Flucht nach Thailand

Wegen des Vorwurfs des Insiderhandels flüchtete Schmitz im Jänner 2002 nach Thailand. In Thailand angekommen, wurde er verhaftet und nach Deutschland ausgeliefert und vor Gericht gestellt. Er wurde zu 20 Monaten auf Bewährung verurteilt und musste 100.000 Euro Strafe zahlen. 2003 bekannte sich Schmitz schuldig, Darlehen für seine Firma Monkey AG veruntreut zu haben. Er erhielt weitere zwei Jahre auf Bewährung.

Quelle:

http://derstandard.at/1326503877263/Vita-Das-mega-wahnsinnige-Leben-des-Kim-Schmitz
 
Zuletzt bearbeitet:
Zurück
Oben