Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 119 reacties
Submitter: basst85

Mega heeft gereageerd op kritische geluiden over de gebruikte encryptiemethoden bij zijn onlangs geopende cyberlockerdienst. De start-up van Kim Dotcom zegt niet onder de indruk te zijn van de kritiek, maar belooft toch enkele aanpassingen te zullen doorvoeren.

Onder andere in een artikel op Ars Technica werd ingegaan op de gehanteerde clientside-encryptiemethoden. Volgens de schrijver hebben de ontwikkelaars van Mega een aantal fundamenteel verkeerde keuzes gemaakt bij de toegepaste encryptie op de opgeslagen data. Zo zou de toegepaste entropie bij het genereren van de aes-128 master key, tegelijk het wachtwoord voor Mega, onvoldoende zijn. De javascriptfunctie math.random zou onvoldoende willekeurige waardes genereren, die daarom geraden kunnen worden. Het gebruik van javascript voor cryptografie wordt in het algemeen al afgeraden. Volgens Mega klopt de kritiek deels en zal er naast entropie die is verkregen via muis- en toetsenbordbewegingen een optie aan de sleutelgenerator worden toegevoegd om nog voor het genereren van de sleutel extra entropie toe te voegen.

Mega gaat ook in op de kritiek dat er geen werkend mechanisme is voor het herstellen van een wachtwoord. Volgens de cyberlocker is dit inherent aan het gebruikte encryptieproces. Het is mogelijk om een nieuw wachtwoord aan te maken, maar bestanden die met de oude sleutel zijn versleuteld, blijven logischerwijs ontoegankelijk. Mega wijst naar de mogelijkheid om de gebruikte encryptiesleutels te exporteren.

De vernieuwde cyberlockerdienst van Mega gaat ook in op enkele opmerkingen uit een verhaal van Forbes. Zo stelt Mega dat het alleen 'zwakke' 1024bit-sleutels gebruikt voor statische content, terwijl voor gebruikersdata de als veilig omschreven 2048bit-rsa-encryptie wordt toegepast. Forbes schreef echter dat Mega uitsluitend 1024bit-encryptie heeft toegepast. Verder claimt de cyberlockerdienst javascriptcode te verifiëren voordat deze binnen de browser wordt gedraaid.

Ten slotte gaat Mega kort in op de tool MegaCracker. Met deze tool wordt een brute force-aanval ingezet op de hashcode die Mega per mail naar gebruikers stuurt. De MegaCracker-tool gebruikt standaard-dictionary-aanvallen, volgens Mega een goede reden om geen eenvoudig raadbare wachtwoorden te gebruiken.

Lees meer over

Reacties (119)

Reactiefilter:-11190118+185+29+30
Moderatie-faq Wijzig weergave
ik heb onderhand al een stuk of 100 keer geregisteerd, maar ik krijg geen registratie binnen...
Ik weet niet van welke mail provider je gebruik maakt ? Maar ik heb het hierboven al gezegd wanneer je bijvoorbeeld een @outlook adres gebruikt van Microsoft krijg je geen verificatie mail binnen. Wanneer je dit echter met een @hotmail adres gebruikt krijg je de mail wel binnen. @gmail werkt ook. Meer mail providers heb ik zelf niet uitgeprobeerd.
Heb meerdere hotmail en andere accounts geprobeerd, bij sommige wel activeringslinks binnen gekregen, maar alleen gmail werkt goed.
Ik krijg hem op @hotmail niet binnen hoor.
Eindelijk wel slim gezien. Maar wil dat dan zeggen dat je met een fout wachtwoord de namen van de bestanden kan zien? Of zin die namen ook versleutelt ?
Hmm zoveel kritiek... maar als je data zo belangrijk is waarom upload je het dan naar een cloud dienst?
Omdat ik de url nergens in het artikel terug kan vinden: https://mega.co.nz/
Staat er gewoon in hoor, het blog staat op https://mega.co.nz zelf en daar kan je direct naar de homepage.

[Reactie gewijzigd door Seditiar op 23 januari 2013 15:07]

"MegaCracker" die dienst is amper online en er is nu al een speciale cracktool voor? 8)7
Uit het artikel;
Met deze tool wordt een brute force-aanval ingezet op de hashcode die Mega per mail naar gebruikers stuurt. De MegaCracker-tool gebruikt standaard-dictionary-aanvallen, volgens Mega een goede reden om geen eenvoudig raadbare wachtwoorden te gebruiken.
Niet heel spannend dus. Ditzelfde kan je zonder al teveel moeite op een truecrypt volume doen. Zoals Kim al aangeeft, eenvoudig raadbare wachtwoorden worden afgeraden. Buiten dat moet je eerst nog het mailtje van je slachtoffer zien te bemachtigen met hierin de hashcode.

Zoals ik al zei, niet zo heel spannend dus.
Op zijn ego getrapt, maar toch weer de comunity die een dienst helpt verbeteren. Dank je wel, zeg je dan.
Dat zal wel meevallen denk je ook niet? Waarom zou hij anders het volgende op twitter zeggen?

We welcome the ongoing #Mega security debate & will offer a cash prize encryption challenge soon. Let's see what you got ;-)

[Reactie gewijzigd door Perkouw op 23 januari 2013 16:58]

Dit gaat gewoon keihard in een rechtzaak eindigen. Is het hosten van illegale content in versleutelde vorm strafbaar? Hoe kan bewezen worden dat de content illegaal is, en wie is daarvoor verantwoordelijk. ?

Ik denk dat er al een legertje advocaten alles aan het uitpluizen zijn. Kim DotCom zal er ook wel zin in hebben: hij doet trouwens niets anders dan uitdagen. Ik denk dat ze hem het best pakken op iets strafbaars dat niets met Mega te maken heeft, waardoor zijn bedrijf mee de afgrond in duikt.
Even afgezien van wat je allemaal in je tweede alinea zegt. Hoe zit dit volgens jou dan met bedrijven als DropBox? Spideroak? SugarSync? Google Drive? Skydrive? etc....
Volgens mij zijn die veel strikter en werken veel beter mee met Amerikaanse anti-piracy agentschappen. Ik zou daar totaal geen illegale content durven uploaden. Die sluiten direct je account, en sturen je ip door naar bevoegde instanties. Bij MegaUpload verwijderde ze enkel de link, en kon je doorgaan.
Bij Megaupload hadden de "gedupeerde" bedrijven ook gewoon toegang tot het systeem om illigale bestanden te verwijderen, dat zal nu wellicht weer het geval zijn, kijk dat interview met DotCom op youtube daar even op na ;)
Wat dotcom beweert en wat waar is hoeft niet hetzelfde te zijn,
Hoe registreert men toetsenbordbewegingen?

Ik vind het wel positief dat Mega ingaat op de kritiek van hun gebruikers. Veel bedrijven zouden met een smoesje komen of gewoon geen commentaar geven.
Het - mijn inziens - belangrijkste punt dat Ars maakt over de toegepaste deduplicatie lees ik helaas niets over. Het komt er in het kort op neer dat zodra het mogelijk is te dedupen er dus een link gelegd kan worden tussen data van verschillende gebruikers. Zelfs als Mega niet op de hoogte is van de inhoud van het bestand is het wel mogelijk direct te zien welke gebruiker nog meer inbreukmakend materiaal in zijn/haar locker heeft (door slechts 1 versie te identificeren)
Kan me goed voorstellen dat, in theorie, 2 stukken verschillende data na encryptie met verschillende sleutels het zelfde resultaat hebben, en dus gededuped kunnen worden, maar daar mag de dan weer niet uit afleiden dat, als de ene inbreuk maakt op auteursrecht, de andere dat ook doet.
In tegenstelling juist. Omdat de sleutels verschillend zijn is de brondata dat zeer waarschijnlijk ook.

Dus kunnen dedupen staat niet gelijk aan het kennen van de sleutels, en ook niet aan het herkennen van geencrypte gepirateerde bestanden.
De efficientie van het dedupen zal dan wel laag zijn, afhankelijk van de blokgrootte.
Dus kunnen dedupen staat niet gelijk aan het kennen van de sleutels, en ook niet aan het herkennen van geencrypte gepirateerde bestanden.
De efficientie van het dedupen zal dan wel laag zijn, afhankelijk van de blokgrootte.
Dedupen werkt toch op basis van overeenkomende hashes? Als de hashes van twee bestanden gelijk zijn dan zijn die 2 geuploade bestanden, bit voor bit, aan elkaar identiek.

Als er dus aantoonbaar gemaakt wordt dat bestand A inbreuk maakt, dan doet bit-wise copy B dat ook.

De-dupen kan alleen met versleutelde bestanden gewoon lastig. Je kan niet bestand A met sleutel B gaan encrypten om hem aan gebruiker B te serveren, want dan moet je eerst bestand A weer kunnen ontsleutelen. Dan is je hele principe van beveiliging (waarin Mega geen sleutels heeft) totaal zinloos geworden.
Als ik het hele verhaal lees houden ze de mogelijkheid open om te dedupen *na* encryptie.
Uiteraard mogelijk, maar met een perfecte encryptie zinloos.
Misschien om in te dekken de voorwaarden iets te ruim opgezet?
Verder claimt de cyberlockerdienst javascriptcode te verifiëren voordat deze binnen de browser wordt gedraaid.
Ik vraag me altijd af hoe dit gebeurd, als ik de javascript code kan aanpassen kan ik toch ook de functie die javascript code controleert aanpassen?

[Reactie gewijzigd door kikker81 op 23 januari 2013 15:42]

Ja, maar niet de originele webpagina die op de server staat, tuurlijk je kan de .js file downloaden van de webserver (gewoon met ctrl+s) en bewerken dan, maar dan verander je uiteraard niks aan de code die op de webserver staat. Alleen aan het bestand dat op JOU computer staat.

Elke zichzelf respecterende webserver heeft een uitgebreid permissions managementsysteem, waardoor dit onmogelijk zou moeten zijn, ten minste dat is mijn ervaring van buiten af (ik ben geen webserverbeheerde o.i.d., maar ik heb wel eens geprobeerd om een html bestand van een site te editen puur uit nieuwsgierigheid en ik heb wat linux (meest gebruikte (web)server OS) ervaring)

Ik heb zelf geen uitgebreide kennis van UNIX permissionbeheer, maar ik weet wel wat rw(lees en schrijf rechten), r (bestand kan alleen gelezen worden en niet bewerkt of uitgevoerd etc.) en x (bestand mag uitgevoerd worden/executable) zijn. ;)

[Reactie gewijzigd door Superpelican op 23 januari 2013 16:01]

Dat bedoelde ik, dus als je write access hebt tot het filesystem van de server houdt het hele verhaal qua beveiliging op, dan zou je zelf de javascript code kunnen aanpassen om alle bestanden en wachtwoorden niet encrypted naar jouw eigen server te sturen.

Edit, volgens het blog van Mega zit het zo, en dat klinkt best logisch:
Fact #1: The JavaScript is not verifying itself. Fact #2: A piece of JavaScript coming from a trusted, 2048-bit HTTPS server is verifying additional pieces of JavaScript coming from untrusted, HTTP/1024-bit HTTPS servers.

[Reactie gewijzigd door kikker81 op 23 januari 2013 16:23]

Op dit item kan niet meer gereageerd worden.



LG G4 Battlefield Hardline Samsung Galaxy S6 Edge Microsoft Windows 10 Samsung Galaxy S6 HTC One (M9) Grand Theft Auto V Apple iPad Air 2

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True