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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 119 reacties, 27.110 views •
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
Inhoudelijke response op kritiek, opzich wekt dat vertrouwen in het bedrijf. Veel andere bedrijven laten hun PR-afdeling een antwoordje schrijven waar de (potentiële) klanten het maar mee moeten doen.
Of je hebt geen geld om een fatsoenlijke PR erop na te houden dan wel genoeg grootheidswaan om te denken dat je het allemaal zelf beter kan, van het laatste heeft meneer Schmitz al vele malen aangetoond dit te bezitten.

[Reactie gewijzigd door Tijger op 23 januari 2013 16:27]

Maar wat noem jij fatsoenlijke PR? Ik bedoel juist te zeggen dat de antwoorden die de gemiddelde PR-afdeling bij andere bedrijven schrijft (zelfs xs4all helaas) soms huilen met de pet op zijn. Dat is dan wel geen grootheid - maar wel compleet waanzinnig. Dan doet Megaupload het toch een stuk beter.
Je vergeet het doel van "meneer Schmitz", namelijk dat Mega niet kan weten welke data is opgeslagen.

Het is geen beveiliging voor de gebruiker maar bescherming van de site. Dat is het enige doel. Alle cloud diensten kunnen op dit moment gedwongen worden om inzage in de data te geven. Ook Mega, maar Mega kan alleen de geencrypte zooi laten zien en daaruit kun je helemaal niets opmaken. Mega kan niet worden gewongen om de bestanden te decrypten want dat kunnen ze gewoon niet. Je kan van een provider niet eisen om bestanden te gaan kraken met wat voor tool ook, zelfs al zou dat mogelijk zijn. En niemand kan de provider verwijten dat ze hadden kunnen weten dat er copyright beschermde bestanden op staan want dat kan de provider niet weten zonder niet eerst de beveiliging van elk bestand te kraken, iets wat je onmogelijk kan eisen.

Zolang de versleuteling daarvoor goed genoeg is en Mega nooit de beschikking krijgt over sleutels is het doel bereikt. Dus sleutels kraken, verspreiden enz is allemaal okay, zolang je ze maar niet aan Mega geeft. Ik vindt de oplossing van "meneer Schmitz" behoorlijk slim.

Als je bang bent voor privacy dan upload je gewoon een TrueCrypt volume maar die site, kun je ook bij Dropbox, SkyDrive of wat ook doen.

[Reactie gewijzigd door pe1dnn op 23 januari 2013 17:48]

"De start-up van Kim Dot.com zegt niet onder de indruk te zijn van de kritiek, maar belooft toch enkele aanpassingen te zullen doorvoeren." moet natuurlijk Dotcom zijn.

Ik ben vrij enthousiast over MEGA maar ik ben niet van plan het te gaan gebruiken tot dit soort kinderziektes opgelost zijn. Het lijkt me een prima alternatief voor Dropbox en de encryptie op je bestanden is ook erg welkom. Wel wil ik mijn wachtwoord kunnen opvragen maar dit is geen must.

[Reactie gewijzigd door Sneek op 23 januari 2013 15:17]

Ik moet zeggen dat ik eigenlijk geen last ondervind van de kinderziektes zoals men die aangeeft, niet kunnen registreren tot het niet kunnen uploaden van bestanden. Hier werkt eigenlijk alles van het begin af aan al gewoon goed en snel, goed de eerste paar uur was het wat beholpen.

Wat veel mensen niet weten is dat je bijvoorbeeld met een @outlook adres geen verificatie mail krijgt (of kreeg inmiddels). Wanneer je dan bijvoorbeeld @hotmail gebruikt kreeg je deze wel. Of dit een fout is aan de kant van Mega of Microsoft, daar ga ik geen uitspraak over doen want dat weet ik niet.

Wat betreft je wachtwoord opvragen. Zoals hierboven al gezegd wil je een password recovery doen dan moet je wachtwoord ergens zijn opgeslagen en laat dat nu net iets zijn wat ze niet willen. Wederom zoals hierboven al gezegd, maar vergelijk het met een TrueCrypt volume daarvan kan je het wachtwoord ook niet opvragen. Password kwijt is data kwijt.
Wat veel mensen niet weten is dat je bijvoorbeeld met een @outlook adres geen verificatie mail krijgt (of kreeg inmiddels). Wanneer je dan bijvoorbeeld @hotmail gebruikt kreeg je deze wel. Of dit een fout is aan de kant van Mega of Microsoft, daar ga ik geen uitspraak over doen want dat weet ik niet.
Ik had geregistreerd met een oud live.nl adres (in feite ook hotmail, tegenwoordig outlook) en daarbij kwam ook geen verificatiemail binnen.
Bedankt voor je reactie

Ik geef je groot gelijk, maar er is ook altijd een doelgroep (waar ik toe behoor) die niet (veel) waarde hecht aan encryptie. Daarnaast vermoed ik niet dat mijn vakantie foto's dusdanig interessant zijn dat ze een zware encryptie nodig hebben.

Nu is het ook zo dat gebruikers gewoon het wachtwoord moeten onthouden maar gezien mijn browser alles onthoud wil ik nog wel eens mijn wachtwoord vergeten wanneer ik elders inlog.

Van encryptie heb ik weinig verstand. Het moet me altijd mogelijk lijken om een reset link te kunnen versturen maar dan heb je natuurlijk geen toegang meer tot de eerder gemaakte bestanden. Het probleem is denk ik dat veel mensen niet beseffen hoe belangrijk je MEGA wachtwoord kan zijn, wanneer men met TrueCrypt gaat werken zijn ze hiervan op de hoogte.
Nu is het ook zo dat gebruikers gewoon het wachtwoord moeten onthouden maar gezien mijn browser alles onthoud wil ik nog wel eens mijn wachtwoord vergeten wanneer ik elders inlog.
Kijk eens naar KeePass of LastPass.

Jouw vakantie fotos zijn voor jou kennelijk niet zo belangrijk, maar kijk er eens naar met een ander oog naar diezelfde fotos?
Hoe zit het met chanteerbaarheid? Moeder de vrouw minder gekleed of zo, of de kinderen die voor sommige lieden interessant kunnen zijn.
Hetzelfde geldt voor fotos van thuis. Oh, een dikke vette computer, mooie tv, zie ik daar sieraden? Daar is een andere branche weer in geinteresseerd.

Ik kijk heel erg uit wat ik "de cloud" in slinger. En als het voor een zogenaamde backup is vindt ik encryptie wel belangrijk.
Je hebt groot gelijk en ik heb er eerlijk gezegd nog niet zo over na gedacht. Misschien extreem naïef om te denken dat encryptie voor mij niet belangrijk is.

Echter zet ik ook veel foto's op Facebook (van bovenstaande) en heb hier gelukkig nog geen slechte ervaringen mee gehad. De foto's die ik niet op Facebook zou zetten zet ik ook niet op MEGA (of Dropbox, of wat dan ook).
In de terms of service staat :

8. Our service may automatically delete a piece of data you upload or give someone else access to where it determines that that data is an exact duplicate of original data already on our service. In that case, you will access that original data.

maar dit kunnen ze toch helemaal niet als alles geencrypt is?
Volgens mij is de hash dan ook precies hetzelfde?
Zie http://en.wikipedia.org/wiki/Data_deduplication

Op het moment dat je inlogt of een link shared dan wordt jouw 50 GB private home directory gemount. Op dat moment kan bijvoorbeeld ZFS (ik noem maar iets) deduplication uitvoeren op die specifieke data.
Misschien dat ze client site hashes maken en vergelijken. Je weet dan nog steeds niet wat voor data het is, maar wel dat het dezelfde data is...

Even een mogelijk scenario:

Misschien zit het wel iets ingewikkelder in elkaar en is de gebruikersleutel niet de encryptie sleutel voor de data. Bijvoorbeeld: je maakt een hash van de data, die hash code gebruik je om de data te versleutelen en vervolgens berg je de hash op in een container die je met de gebruikerssleutel versleuteld. Vervolgens sla een een andere hash code van die data op voor het vergelijken. Je hebt nu 3 elementen:
  • Maak van de gebruiker data 2 hashes: hashcode_1 en hashcode_2
  • Versleutel de data met hashcode_1
  • Maak een container met hashcode_1 en hashcode_2 en versleuteld die met de gebruikers sleutel
  • Maak van hashcode_2 een link naar de versleutelde data
Je hebt zo via hashcode_2 een link naar de data, maar de data is alleen bruikbaar met de veilig opgeborgen hashcode_1

Als een andere client met dezelfde data komt dan is het eenvoudig. Bepaal hashcode_1 en hashcode_2 met de te uploaden data en zoek of de data al bestaat. Zo ja, maak een nieuwe container met hashcode_1 en hashcode_2 en versleutel die met de gebruikerssleutel.

Die hashes zijn zelf ook crypto sleutels, je kan ze alleen bepalen als je zelf de data hebt. Zo kun je dus data enkelvoudig versleuteld opslaan zonder dat je weet wat het is. Uiteraard als je hashcode_1 hebt kun je de data ontcijferen, maar dat is dan nutteloos want die data had je toch immers al want anders kon je hashcode_1 niet bepalen.

Dit is maar een idee, ik weet natuurlijk niet of het zo werkt maar in deze richting zou je kunnen denken. Misschien dat je nog veel ingewikkelder constructies kan bedenken om hetzelfde te bereiken, geen idee hoe Mega het doet. Maar in elk kan versleutelen, het vinden van duplicaten en het onbekend blijven van de inhoud bij Mega op een dergelijke manier wel.
Dit is maar een idee, ik weet natuurlijk niet of het zo werkt maar in deze richting zou je kunnen denken.
Daar komt het grofweg inderdaad op neer als je het artikel op Ars Technica mag geloven. Het artikel noemt 'Convergent Encryption' als een manier van encryptie die de mogelijkheid biedt unieke sleutels uit te delen en toch identieke bestanden op dezelfde manier te versleutelen. Op de pagina Is Convergent Encryption really secure? wordt min of meer dezelfde methode beschreven als jij hierboven beschrijft.

Er wordt tevens een belangrijk nadeel genoemd en dat is dat iedereen die bekend is met de encryptie methode (niet de sleutel) of in staat is daar gebruik van te maken en hetzelfde bronbestand bezit in staat is om aan te tonen wat de inhoud van het bronbestand is. In encryptie wordt dat als een ernstige tekortkoming gezien en dat is het in dit geval zeker ook.

Praktisch gezien komt het er op neer dat als ik een encrypted versie van bijvoorbeeld een overheidsdocument op mijn schijf heb bewezen kan worden dat het om het betreffende document gaat zonder de noodzaak om mijn encrypted versie te decrypten. De overheid bezit het document immers al en kan door dit simpelweg op dezelfde manier te encrypten mijn encrypted data reproduceren. Dat is voldoende bewijs.

Wat zou dat praktisch inhouden voor mega.co.nz? Dat ze eigenlijk weer terug zijn waar ze met Mega Upload waren. Zodra er een verzoek komt om een bepaald bestand te verwijderen zijn ze er daarmee ook van op de hoogte welke andere uploaders hetzelfde bestand hebben geupload. Verwijderen ze nu net als mega upload alleen de verwijzing of sleutel van de gebruiker waarover ze een melding ontvangen dan volgen ze dezelfde werkwijze als mega upload. In dat geval verwacht ik dat het ook hetzelfde met mega.co.nz af zal lopen als met mega upload.
Ik snap de kritiek niet echt. Je bent (deels) ook zelf verantwoordelijk voor het opslaan van je data. Dat een 'dump-site' niet voldoende beveilig zou zijn, dat is toch iets waar je als gebruiker vind ik rekening mee moet houden. Je wilt bijvoorbeeld (tenminste neem ik aan) geen persoonlijke data op een dump-site willen opslaan.

Het is van de andere kant wel opmerkelijk dat 'Mega gebruikt maakt van een encryptie die op de client staat i.p.v. de server. Maar dit maakt het wel weer veiliger als de servers (weer) eens in beslag zouden worden.

Ik ben wel overigens blij met de kritiek van andere gebruikers. Als er eenmaal betere en veiliger encryptie mogelijkheden zijn die kunnen worden ingezet, waarom niet? :)
Een simpel antwoord op je 'waarom niet?' is "performance".

Waarom wordt 1024 bits beveiliging gebruikt als 2048 ook kan?
Die regel gaat ook op voor 'waarom 2048 als 20480 ook kan?': wil jij drie dagen zitten te wachten voor de sleutel is gegenereerd om je bestand mee te versleutelen?
Dat een 'dump-site' niet voldoende beveilig zou zijn, dat is toch iets waar je als gebruiker vind ik rekening mee moet houden.
Dus je mag zelfs geen kritiek hebben als die dump site zelf beweert dat het superveilig is door de gebruikte encryptietechnieken, "omdat je nou eenmaal zelf verantwoordelijk bent"?
@.oisyn: Heb je men comment wel helemaal gelezen of alleen het eerste gedeelte?
"Ik ben wel overigens blij met de kritiek van andere gebruikers. Als er eenmaal betere en veiliger encryptie mogelijkheden zijn die kunnen worden ingezet, waarom niet..."

@Durandal: Een mogelijkheid om de sleutel te exporteren zou inderdaad een veilige oplossing zijn. Ik blijf bij mijn standpunt dat de gebruiker (deels) verantwoordelijk is voor zijn eigen gegevens, maar ook voor het opslaan van sleutels, wachtwoorden, etc.

Wat Durandal hieronder ook aangeeft, wil je een optie om toch te herstellen gebruik dan bijvoorbeeld Dropbox als alternatief. (Je kunt tevens Dropbox ook extra beveiligen met sms-code)
Ik reageer op het feit dat je het niet snapt ("Ik snap de kritiek niet echt"). Dat je er ondertussen wel blij mee bent is daar ondergeschikt aan.
Kritiek mag je altijd hebben, maar erg realistisch is dat niet.
De site wordt aangeboden als 100% veilig. Dat is dus waar je voor kiest als je daar je data parkeert.
Als nu blijkt dat ze je password kunnen geven als jij hem krijt bent kunnen ze dus bij je data, en 3e partijen ook, en is je data dus 0% veilig.

Wil je dat niet gebruik dan gewoon dropbox, waarbij je weet dat de VS inzage hebben.

Is het trouwens zo moeilijk even ergens een backup van je sleutel te maken, 'voor als'?
Wil je dat niet gebruik dan gewoon dropbox, waarbij je weet dat de VS inzage hebben.
Ga er maar gewoon vanuit dat de VS en kwaadwillenden bij elke dienst inzage kunnen hebben. Is het niet nu dan misschien over een jaar. Kortom, versleutel voor je iets in de cloud zet.
Kritiek mag je altijd hebben, maar erg realistisch is dat niet.
Waarom is het niet erg realistisch om kritiek te hebben op een dienst die niet levert wat ze zeggen te leveren?
Als nu blijkt dat ze je password kunnen geven als jij hem krijt bent kunnen ze dus bij je data
En als ze zeggen dat ze dat niet kunnen terwijl ze het eigenlijk wel kunnen dan is dat reden voor kritiek. Dit gaat overigens niet over Mega, want het niet bij je wachtwoorden kunnen komen is een essentieel onderdeel van de dienst, voornamelijk voor hunzelf (plausible deniability)

[Reactie gewijzigd door .oisyn op 23 januari 2013 15:55]

Dat de gegevens kunnen verdwijnen kan ik mee leven. Waar ik vooral nieuwsgierig naar ben is hoe veilig mega nou is om bijv mijn foto's op te slaan tov Dropbox etc. En met 'veilig' bedoel ik dan dat ik er van op aankan dat mijn gegevens niet in handen van derden terecht komen.
Van dropbox is al bekend dat jij niet de enige bent met een sleutel, dus dan is de keuze snel gemaakt.

Aan de andere kant, is er iemand die zich interesseert voor jou foto's?
Wil je mij al jouw foto's toesturen via WeTransfer of gelijkwaardige dienst?
En met 'veilig' bedoel ik dan dat ik er van op aankan dat mijn gegevens niet in handen van derden terecht komen.
Dat kan je met een USB harddisk thuis ook niet. Als er bij je wordt ingebroken en ze nemen je disk mee dan kunnen anderen je foto's en films ook zien.

Opslaan in een TrueCrypt volume is inderdaad een optie. Alleen als het je familie foto's zijn en je loopt onder een trein kan ik mij voorstellen dat de overige gezinsleden toch weer bij de foto's willen kunnen (gelukkig hebben we de foto's nog...). Je zou de passphrase op kunnen schrijven maar dan kom je weer terug bij het diefstal scenario.

Er zijn maar 2 zekerheden in het leven en dit is er niet een van...

[Reactie gewijzigd door pe1dnn op 23 januari 2013 16:00]

het wordt in je eigen browser versleuteld. Als jij een sterk wachtwoord kiest: heel veilig.

Daarnaast kan (of kon) dropbox gewoon bij je bestanden. Dit moest omdat ze moesten kunnen scannen of er wijzigingen waren (of iets dergelijks. kan me vaag zoiets herinneren).
Daar kan je nooit 100% van uitgaan natuurlijk. Ze kunnen altijd gehacked worden of weet ik veel wat. Wat je zelf kan doen is je bestanden zelf encrypten met bijvoorbeeld TrueCrypt om het risico reduceren. Maar zelfs dan, wie zegt dat die data over een jaar of 10 niet heel makkelijk is te kraken ?

Het is dus nooit 100% veilig en hoe groot het risico is dat mensen bij jou bestanden kunnen heb je zelf ook voor een groot deel in de hand.
Ik vind het best goed, die beveiliging van Mega. Er zit echter ook een staartje aan. Wanneer het echt zo goed is beveiligd als beweerd dan zal het netwerk binnen de kortste keren zeer zeker worden gebruikt door criminelen die daar hun data veilig kunnen opslaan zonder dat er ooit iemand bij kan. Aangezien Mega geen controle heeft, kan niemand er ooit bij. Dat is heel leuk en aardig, maar wanneer vanuit daar een leuk netwerk wordt opgezet voor kinderporno of erger, dan vind ik dat een schadelijke zaak. Zo zouden ook de maffia en dergelijke daar belangrijke bestanden kunnen leggen, aangezien het niet gekraakt kan worden.
Enige wat wel fijn is, is dat ze Java hebben gebruikt. Java is zo lek als een mandje wat betreft beveiliging. Maar de essentie vam Mega is goed, maar leent zich uitstekend voor illegale zaken.
Java?

WTF?

Javascript heeft, in tegenstelling tot wat de naam doet vermoeden, helemaal niets met Java te maken.
Criminelen gebruiken al lang en breed software zoals SSL, TrueCrypt, GPG, enz.

De zwakste schakel is nog steeds de mens. Zwakke wachtwoorden en achterdeurtjes, bijvoorbeeld.

[Reactie gewijzigd door Jerie op 23 januari 2013 16:36]

Ik zie u punt. Maar men moet de producenten van die illegale content aanpakken (de ziekte), niet hun manier van opslaan (de symptomen).

Dat is zoals met bvb hamers. Hamers worden gemaakt om dingen mee te bouwen, maar er zijn er altijd die daar iets anders mee doen (iemand de kop inslaan). Draagt de hamerproducent enige verantwoordelijkheid? Natuurlijk niet.

Punt is: men moet de criminelen oppakken en opsluiten ipv achter services te zitten die zouden kunnen gebruikt worden om illegale shit op te slaan.
Maar de essentie vam Mega is goed, maar leent zich uitstekend voor illegale zaken.
Om maar weer even een autologie in de groep te gooien; een auto ook.

(en natuurlijk een miljoen andere dingen).
Denk je nu echt dat criminelen encryptie en het beheer van hun bestanden overlaten aan een derde als Mega ? Dat denk ik niet.

En als ze de files al zouden stallen bij een clouddienst als Mega dan zullen ze ongetwijfeld hun bestanden zelf encrypten met iets als TrueCrypt. En als ze het helemaal gek willen doen, zorgen ze dan ook voor een paar lagen encryptie. Maar dan kan je het net zo goed bij een cloud dienst als DropBox stallen.

Al met al zie ik geen reden voor je 'angst' dat deze dienst door dergelijke criminelen zoals jij omschrijft uitgebaat zal worden.

[Reactie gewijzigd door Perkouw op 23 januari 2013 15:38]

Maar de enige manier om dat tegen te gaan is het verbieden van encryptie door burgers. Ik denk niet dat er veel mensen zijn die daar positief tegen overstaan.
Maar de burger encrypt hier niet, dat doet MEGA. Net als je bank dat doet bij transacties.

Eer dat de overheid de scheidslijn precies heeft waar ze het hebben wil leven we in een politiestaat, en dan zijn de consequenties om het niet te gebruiken misschien wel groter dan die van het wel te gebruiken.
Dat zeg je nou wel, maar ik meen juist gelezen te hebben dat de versleuteling in Javascript gebeurt. Aan de kant van de burger dus!
De cryptografie is wel echt een hele slimme zet uit 'de markt' op het content gebruik van klanten. Op deze manier kan Mega nooit weten wat de gebruikers doen. En in de voorwaarden staat ook dat het er niet voor bedoeld is. Je krijgt een bijna elementaire vraag die volgens mij in het voordeel van Mega uitpakt. Een schroevendraaier kan je gebruiken om in te breken. Het is er niet voor bedoeld maar wel te gebruiken. De fabrikant van het produkt prijst het gebruik van de schroevendraaier ook niet aan. En weet ook niet wat zijn klanten ermee doen. So far so good.

Echter dit is internet. En een aantal partijen zal hier niet zo blij mee zijn. Zij zullen vast wel weer gaan proberen om hier aan te zagen. Maar voorlopig is dit een hele mooie stap van Mega.

Maar, na wat er met Megaupload is gebeurd. Zou jij al je foto's, of je bedrijfsmail .pst back-uppen naar Mega. Want als je dat naar Megaupload hebt gedaan (en alleen daar) had je wel mooi een probleem. De afhankelijk van de cloud is natuurlijk ergens wel kwetsbaar.
Zou jij al je foto's, of je bedrijfsmail .pst back-uppen naar Mega. Want als je dat naar Megaupload hebt gedaan (en alleen daar) had je wel mooi een probleem. De afhankelijk van de cloud is natuurlijk ergens wel kwetsbaar.
Even afgezien van het feit dat ik dit zelf niet zou doen met persoonlijke gegevens. Maar waarom niet ? Als je cloud als je enige back-up gebruikt ben je sowieso niet handig bezig. Wat als ze down/slecht bereikbaar zijn om wat voor reden dan ook ? In het geval van Megaupload ben je echt alles kwijt, in het gunstige geval kan je er alsnog op een later tijdstip bij.

Persoonlijk zou ik dan ook nooit een cloudopslag als enige back-up optie gebruiken. Als het wat nonsense spul is mogelijk, maar zelfs dan zou ik dit al eigenlijk niet doen omdat ik echt niet uit mijn hoofd weet wat ik allemaal heb en waar alles exact staat.
Als het goed en veilig geencrypt is dan gebruik ik het zeker wel voor online backup, zeker voor mijn persoonlijke data wat toch eigenlijk alleen interessant is voor mij (en bedrijven die aan me willen verdienen).
Maar inderdaad, je moet het niet als enige backup gebruiken. Met een on-site backup er bij zit je wel goed.
De enige reden om cloudopslag te gebruiken is het feit dat de data van meerdere plekken toegankelijk is, in elke andere situatie lijkt het mij altijd veiliger, om meerdere redenen, om je data zelf te bewaren op een manier die je zelf onder controle hebt.

Jezelf afhankelijk maken van een dienst is nooit slim, zeker niet voor gevoelige of belangrijke data. Die moet je zelf bij je houden, alleen dan kan je garanderen dat het veilig is - of in ieder geval zo veilig is als jij zelf nodig acht.

Er is geen enkele clouddienst of webbased service die 100% uptime garandeert (daar begint het al) en zelfs met die garantie kan er genoeg fout gaan: bij stroomuitval ben je de lul, bij een connectieprobleem ook, en je bent door gebruik van een service ook nog eens afhankelijk van het politieke klimaat (zie Megaupload). Doe je je opslag zelf, dan ben je zelfs in staat je eigen noodgenerator te hebben in geval van stroomuitval. Zomaar even een greep uit de verschillen in afhankelijkheid.

Men lijkt weleens te vergeten dat elke centrale database alle aangesloten gebruikers voorziet van een zwakte, terwijl het voordeel vaak marginaal is.

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

Ik had nooit begrepen waarom iedereen maar "the cloud, the cloud!" ging roepen een paar jaar geleden. Persoonlijk ben ik met mijn Android toestel, bijvoorbeeld, verplicht om Google *iets* van mij te laten weten wil ik een beetje "normaal" mee om gaan - maar meer dan dat probeer ik echt niet los te laten. Ik vond het al eng genoeg toen Google verschillende accounts van YouTube enz. alsmede mijn (non-gMail) mail account ineens en ongevraagd allemaal aan mijn (voor Android gemaakte) gMail account koppelde - daar was ik best pissig over, eigenlijk!

Ik heb dan ook nooit synching, remote opslag van contacts enz. plaats laten vinden.

En toen mijn vrouw laatst een Android tablet kocht hebben wij besloten om alles via mijn bestaand account te regelen ipv. een nieuwe aan te maken.

Van persoonlijke bestanden op de cloud zetten is er voor mij voorlopig echt geen sprake!

[Reactie gewijzigd door MossMan op 23 januari 2013 17:36]

Hoe wordt die javascript code dan gecontroleerd voordat het gedraaid wordt? Dit kan je toch altijd als user zelf aanpassen als je dat zou willen ?
Hier staat het hele artikel: https://mega.co.nz/#blog_3

Ze hebben '2' servers. De veilige 2048, die voor de geencrypte bestanden gebruikt en een minder veilige 1024-bit ssl server die alleen statische content serveert.

Via de 2048 server sturen ze checksums mee die gebruikt worden om de (js) content van de minder veilige 1024 bit servers te controleren.

Op zo'n manier hebben ze minder CPU capaciteit nodig (2048 is zwaarder dan 1024) en zijn man-in-the-middle-attacks alsnog niet mogelijk zonder de 2048 servers/encryptie te hacken.

De reden dat ze uberhaubt SSL voor de statische content gebruiken is het feit dat browsers veiligheidswaarschuwingen geven als je op 1 enkele pagina zowel SSL als non-SSL content ophaalt. Maar eigenlijk zeggen ze dat SSL daar niet eens nodig is.
Kan me er ergens wil in vinden, het is gewoon vreemd dat je een password niet op kan vragen. Dan kan je het wel leuk aanmoedigen een moeilijk te raden password aan te maken, maar juist die zal je eerder vergeten.
en dus moet je goede en beveiligde password files aan maken, dat kan in je OS (veel linux systemen bieden dit bijv standaard), of je print de key uit en legt die in je kluis... ik zie daar het probleem niet zo erg van in...

waar ik me iets drukker over maak is het gebrek aan degelijke standaarden om in je account te komen, via bijv webdav. ftp, rsync of een ander degelijk protocol... zolang dat er niet is heb je helemaal NIETS aan zo'n mega ... tenzei je er publieke bestanden wilt plaatsen zoals bijv je custom android / wp roms en andere zulk soort dingen. voor filehosting is zo iets natuurlijk minder belangrijk..
Dit is hetzelfde met True Crypt hoor, als je daar je wachtwoord kwijt bent, kan je ook niet meer inloggen.

Ook dan kan je alleen maar een nieuwe partitie / file aanmaken
Je kunt je wachtwoord bij geen enkele dienst opvragen. En als dat wel kan, dan is er iets goed mis, want dan slaan ze het op zonder encryptie.
Dat is - zoals gezegd in het systeem - inherent aan het systeem. Een van hun USP's is dat zij er niet bij kunnen, dat kan je alleen garanderen als de gebruiker echt de enige is die het weet. Wanneer je je password kan opvragen, betekent dat zij dat ook weten en dus het kunnen overdragen aan jusititie. Een ww reset schiet je ook niks mee op, omdat ze met die sleutel je bestanden versleutelen.


Bij bijv. TrueCrypt is dat ook zo: raak jij je password kwijt, kom je ook nooit meer bij je data. Als dat wel had gekund, dan kan er iemand anders dus ook bij.
Het hele idee van die site is dat ze dat wachtwoord niet hebben, daardoor dus niet kunnen zien wat jij in je locker hebt en dus niet aansprakelijk gehouden kunnen worden voor de inhoud. En belangrijker: ook niet gedwongen kunnen worden het wachtwoord aan een opsporingsinstantie te geven.

Je moet van het wachtwoord dus zelf een backup maken.
Als je ergens je wachtwoord opvraagt en ook daadwerkelijk je wachtwoord krijgt zou ik als ik jou was heel snel het verzoek indienen om al je gegevens te laten vernietigen.

Wachtwoorden plain text opslaan is wel zo enorm slecht en dom.
Plaintext opslaan is enorm slecht: volledig mee eens.

Echter kan je wel een wachtwoord gecodeerd en verspreid opslaan. Als je de methode maar hebt om het originele wachtwoord weer samen te stellen dan kun je die gewoon mailen. Het risico zit dan nog in het lekken van de procedure (en daarom moet je zoiets ook niet gebruiken voor gevoelige zaken). Maar een wachtwoord dat encoded is én verdeeld over meerdere tables (of meerdere databases) is redelijk veilig voor scriptkiddies [en dat is toch 99,5% van alle leaks].

Maar in het geval van Mega is het juist de bedoeling dat niemand, zelf niet als er juridische dwang is, de boel kan decoderen.
Maar wat je zelf al aangeeft: Mega - of wie dan ook - heeft dus de mogelijkheid om het wachtwoord te encrypten. Als de broncode van Mega op straat komt te liggen om wat voor reden dan ook, dan dus ook de methodes om het wachtwoord te decrypten. Een niet-omkeerbare manier om een wachtwoord te encrypten is dus altijd veiliger dan een omkeerbare manier.
Het lijkt me zowiezo logisch dat je een password niet op kan vragen. Die horen niet opgeslagen te worden 'aan de andere kant'.
Je kunt vaak na een verificatie procedure wel een password laten resetten, maar dan krijg je dus een ander password.
En met dat ándere password kan je geëncrypte data dus niet decrypten.
dat is dus inherent aan encryptie.

als je met wachtwoord 'xyz' hetzelfde kan ontcijferen als met wachtwoord 'pqw' dan werkt ieder wachtwoord blijkbaar en is wellicht de encryptie niet zo goed..

Als je je fietssleutel kwijt bent pak je toch ook niet je huissleutel om alsnog je slot open te maken? Nee, dat slot kun je gewoon weggooien als je geen sleutel er voor hebt.
Anders zou iedere inbreker je fiets mee kunnen nemen omdat ze toevallig een sleutel hebben.

Wel zijn er bijvoorbeeld lopers in omloop waarmee alle sloten van type X geopend kunnen worden. Dit is exact wat MEGA niet wil aangezien zij dan gedwongen zouden kunnen worden om jouw data te decoderen; exact hetgeen wat dus NIET kan met deze service.
Je kunt inderdaad wel je account laten resetten (toewijzing nieuwe sleutel), maar daarmee zijn de OUDE bestanden niet ineens ontsleutelt.

Mega kun je vergelijken met BitLocker of TrueCrypt op je eigen harde schrijf. Als je daarvan het wachtwoord kwijt raakt kun je ook niet meer bij je bestanden. Mega bied nu min of meer een cloud variant van bitlocker/truecrypt aan.

Dus om te voorkomen dat je je prive sleutel kwijt raakt, moet je hem dus goed backuppen.
Dat is juist niet vreemd, maar veilig. Het op kunnen vragen van een wachtwoord schiet voorbij aan zoveel basisprincipes uit de beveiliging, dat je de dienst dan wel meteen kunt opdoeken.

Immers, als het encryptie-algoritme in orde is dan is het wachtwoord nooit te herleiden uit iets dat opgeslagen staat. Als jij je wachtwoord invoert wordt dat op dezelfde manier versleuteld en het resultaat wordt vergeleken met het opgeslagen resultaat. Zijn die hetzelfde dan mag je naar binnen. Zijn ze niet hetzelfde dan heb je pech. Het herleiden van een wachtwoord uit wat opgeslagen staat, is een probleem dat 'in de praktijk oneindig veel rekenkracht vergt' als de sleutel lang genoeg is (*).

Zou je nu het wachtwoord ergens opslaan, dan hoeft iemand het alleen maar uit te lezen. Iets dat eerder van hard werken en geluk afhankelijk is dan dat het principieel lastig is. Dat zijn factoren waarop je niet moet willen vertrouwen in de beveiliging.


(*) Zo'n probleem heet in de informatietheorie een NPC-probleem Zou er ooit aangetoond worden dat P=NP (een heilige graal in de computerwetenschap) dan is een van de consequenties dat alle informatie op straat ligt. Gelukkig is het zeer onwaarschijnlijk dat dit 'any time soon' zal gebeuren en kunnen we dus volstaan met het veilig opslaan van wachtwoorden.

[Reactie gewijzigd door mae-t.net op 24 januari 2013 18:02]

Bij encryptie wordt er vanuit gegaan dat het factorizeren van een getal in zijn priemfactoren heel erg duur is. Dit probleem zit echter niet in NP, het zou dus om het even zijn of P gelijk is aan NP aangezien dat niks zegt over de moeilijkheid van het factorizeren of ontbinden in factoren van priemgetallen.

Zo zijn er ook nog andere klassen van problemen die we niet in P lijken te zitten maar waarvan we ook niet kunnen aantonen dat ze in NP zitten. Een voorbeeld hiervan zijn de graafisomorphismen. Je kunt aantonen dat een aantal varianten in een klasse zitten maar je kunt niet aantonen dat die klasse hoort bij P of bij NP.

Dit aantonen van equivalantie is overigens erg interessant. Allereerst toon je aan dat het in NP zit en vervolgens toon je aan dat als je het probleem op zou kunnen lossen, je ook een bestaand NP compleet probleem op kunt lossen, zoals bijvoorbeeld vertex cover. Je zegt dus eigenlijk, dit probleem is minstens zo moeilijk als vertex cover en dus NP compleet.

Als je aan zou kunnen tonen dat het ontbinden in priemfactoren minstens zo moeilijk is als vertex cover of een ander NP compleet probleem, dan pas kun je stellen dat factorizering van priemgetallen NP compleet is.
Hoe zie je het dan voor je? Mega wil juist de garantes bieden dat zij niet aan jou data kunnen, en dus eventuele andere (overheids) organistaties ook niet. Omdat ze de encrpytie sleutel nergens opslaan kunnen ze jou dus ook geen nieuwe laten aanmaken, want de data is versleuteld en niemand heeft de sleutel.
Natuurlijk is het onderdeel van hun vermeende 'legal loophole', maar gebruiksvriendelijkheid is anders. Edoch is een password door allerlei andere wegen te achterhalen, hoeveel encryptie je er op gooit maakt in die zin niet uit.
Misschien niet meest gebruikersvriendelijk, maar wel vereist om er zeker van te zijn dat Mega niet zomaar bij jouw data kan. Ik gebruik Wuala en die gebruikt precies hetzelfde principe. Daar kan ik mijn wachtwoord ook niet opvragen; als zij mijn wachtwoord zouden hebben dan zouden ze zo bij mijn data kunnen. Dat wil ik niet.
Jouw reactie geeft enkel blijk van jouw enorme onkunde. Je moet zelf op je wachtwoorden letten. Als ze enig manier hadden om jouw data terug te brengen als je je wachtwoord bent kwijtgeraakt, dan was het blijkbaar toch niet echt goed veilig opgeslagen. Dit is precies hoe het zou moeten zijn. Ze slaan geen wachtwoorden op, geen hashes ervan, niets. Alleen je data en zo hoort het ook.
Hoe bevestigd Mega dan je identiteit als je inlogt? Je toetst je wachtwoord/master key in, dat moet de server bevestigen op een of andere manier. Daarvoor is toch een hash nodig om tegen te spiegelen, en bij een match, is de login geslaagd?
Niet. Iedereen die de juiste key heeft kan bij je bestanden. Iedereen die jij een kopietje van jouw bestanden stuurt, versleuteld met hun publieke sleutel kan bij dat specifieke bestand. En aangezien Mega jouw bestanden absoluut niet wil zien, willen ze ook niets met jouw sleutels temaken hebben.
Het enige wat Mega weet is dat zoveel GB aan data versleuteld op hun servers staat in de directorystructuur van gebruiker X. Daar verdienen ze geld mee op het moment dat het gaat om premium accounts. Voor de rest kan jouw data ze gestolen worden (letterlijk; als jij niet zorgvuldig met je sleutels omgaat en iemand anders krijgt ze in handen dan heeft diegene toegang tot al jouw bestanden en al jouw bestandsruimte en Mega zal daar niets tegen doen).

[Reactie gewijzigd door jiriw op 23 januari 2013 19:35]

Ik neem niet aan dat je gegevens van het kaliber "boodschappenlijst" van een dusdanige beveiliging wilt voorzien. Als je de hele collectie kinderporno, om maar iets te noemen waar andere niks van mogen weten, daar wilt opslaan wordt je toch wel creatief in het verzinnen van een wachtwoord wat je zelf alleen maar weet.

Ik neem niet aan dat je dan hetzelfde wachtwoord als van je e-mail gaat toepassen of voor de verandering de naam van de hond van de buren neemt omdat je dat wachtwoord nog nergens hebt gebruikt.

Als het goed beveiligd moet worden dan verzin je wel een goed wachtwoord.
En er zal altijd wel software zijn die volgens het '00001' '00002' '00003' etc. probeert je code de forceren, maar op goed geluk zal dat niet weer gaan.

Het is aan de gebruikers zelf om een goed wachtwoord te bedenken, de beveiliging is tenslotte zo sterk als de zwakste schakel. Ofwel de eindgebruiker.
Als je de hele collectie kinderporno, om maar iets te noemen waar andere niks van mogen weten
Ja hoor, daar is ie dan. Ik zat al te wachten op deze dooddoener. Om dit vervolgens te delen zul je altijd nog de sleutel naar iemand moeten sturen, ook vervolgens weer via een beveiligde verbinding. Dat overheden en 'veiligheidsdiensten' *kuch* dit argument altijd inzetten is al erg genoeg. Laten tweakers hier nou niet mee aan komen zetten a.u.b. Denk je nou echt dat criminelen anders geen manier kunnen vinden om informatie te delen als deze diensten niet zouden bestaan?
Ja hoor, daar is ie dan. Ik zat al te wachten op deze dooddoener.
[...]
Denk je nou echt dat criminelen anders geen manier kunnen vinden om informatie te delen als deze diensten niet zouden bestaan?
Over dooddoeners gesproken... :z

Kinderporno was slechts een voorbeeld. Het had ook iets anders kunnen zijn dat je goed wilt beveiligen.
Tuurlijk zijn er zat andere manieren, maar deze wordt vermoedelijk ook gebruikt, zij het door onwetender malloten. Da's geen reden om meteen al onze privacy de deur uit te gooien (in tegenstelling tot wat sommigen beweren), maar wel een reden om de boel enigzins in de gaten te houden. Mega heeft dat expliciet onmogelijk gemaakt, wat hun goed recht is. Die keuze betekent dat jij, als data-plaatser, verantwoordelijk bent voor je key, en niemand anders.
Het was in de gaten te houden. Maar blijkbaar laat de VS een cyberlocker die bestanden van gebruikers kan zien niet bestaan. Omdat ze dan vinden dat je verantwoordelijk bent. Er is genoeg gewaarschuwd dat de copyright heksenjacht het hele net zou dwingen alles te versleutelen.

Het zal even duren maar straks zijn er weer honderd duizenden links die naar hetzelfde media bestand verwijzen. En worden er voor elke verwijderde link weer 100 nieuwe gegenereerd. Volgende stap is dat de uploaders weten welke link + sleutel combo een DMCA heeft gekregen zodat ze die persoon uit hun vertrouwens groep kunnen gooien.

Allemaal heel voorspelbaar gedrag. Vol met de zelfde denk-fouten als ten tijden van de drooglegging.
Maar de verantwoordelijkheid is in ieder geval verschoven en dat is waar het Mega om te doen is. En ik kan ze geen ongelijk geven. Deze dienst is voor backups gewoon een uitkomst.
Het is een interessante technische maar ook juridische constructie. Wat de technische kant aangaat, dat is en blijft altijd onderhevig aan de wet van de eeuwige wedstrijd tussen de kogel en het pantser.

Wat het juridisch aspect aangaat, daar moet me toch van het hart dat waar hun theorie en implementatie an sich redelijk sluitend is, de constructie zelf echter absoluut niet "veilig" is. Mocht de gehanteerde insteek een trend worden, zal menige overheid of lobby orgaan de weg zoeken die het hangijzer volledig doet vermijden. Denk bijvoorbeeld aan wetgeving waar het niet toegestaan is om een dergelijke dienst te opereren zonder een mogelijkheid voor inzicht en toezicht / controle.

In juridisch opzicht is het eigenlijk makkelijker om de methodiek van Mega onwettig te maken dan dat het praktisch is om op individuele basis via facturatie of inspectie via de kant van de ISP achter de individuele gebruiker aan te gaan.
In juridisch opzicht is het eigenlijk makkelijker om de methodiek van Mega onwettig te maken dan dat het praktisch is om op individuele basis via facturatie of inspectie via de kant van de ISP achter de individuele gebruiker aan te gaan.
En hoe denk je dat voor elkaar te krijgen? Een verbod afdwingen op het versleuteld opslaan van data in een cyberlocker? Op welke grond?

Oh ja, omdat we dan niet in de data kunnen kijken. Want er zou nog wel eens, hypothetisch, potentieel gezien, allerlei verkeerde dingen in kunnen staan, en dat willen we als overheid natuurlijk voorkomen. We willen niet dat brave burgers ineens gordijntjes over hun data heen gaan gooien...

Dus wat wordt dan de juridische argumentatie? Verbieden omdat het niet te lezen valt? Of iemand by default gaan veroordelen op elke mogelijke aanklacht omdat hij geen tegenbewijs kan produceren, terwijl er ook geen bewijs te halen valt wat voor zijn schuld pleit?

Dat wordt een beetje een veroordeling in de trant van: "Je hebt een moord gepleegd. Dat weten we, omdat we geen lijk kunnen vinden, dus je hebt het lijk verstopt. En je gaat pas vrijuit als je álles laat zien om te bewijzen dat je geen lijk in je handen hebt gehad..."

Juridisch wordt dat wel héél glad ijs.
Je* overschat de moeilijkheid om dit als overheid te implementeren nogal. De overheid maakt de wet. De rechter en juridische kant toetst de zaak van de gedaagde hier slechts aan. In de praktijk.

Volgens jou mag de US govt dus ook niet alles wat online staat in de USA inzien? Oh wacht, dat mogen kunnen en doen ze dus wel. De patriot act en co.

* en velen met jou
Hoewel het niet helpt als je je wachtwoord vergeten bent, is er een redelijk simpele manier om het veranderen van wachtwoorden te implementeren: Maak voor elk account een random 'Masterkey' aan waar alle data mee versleuteld wordt en versleutel deze vervolgens met het wachtwoord van de gebruiker.
Als de gebruiker nu het wachtwoord wil veranderen en z'n oude wachtwoord nog weet kan de Masterkey ontsleuteld worden en vervolgens weer versleuteld met het nieuwe wachtwoord.

Dit is natuurlijk wat versimpelt en er zitten een paar haken en ogen aan de implementatie, maar correct geïmplementeerd is het (theoretisch) niet onveiliger of zwakker dan het wachtwoord direct gebruiken. Enige nadeel is dat er twee sleutels zijn die een aanvaller kan proberen te raden, maar in de meeste gevallen zal het gebruikers-wachtwoord toch zwakker zijn dan de langere en willekeurige masterkey.
Dit staat op de lijst om in te voeren.

https://mega.co.nz/#blog_3
A password change feature will re-encrypt the master key with your new password and update it on our servers
A password reset mechanism will allow you to log back into your account, with all files being unreadable. Now, if you have any pre-exported file keys, you can import them to regain access to those files. On top of that, you could ask your share peers to send you the share-specific keys, but that's it - the remainder of your data appears as binary garbage until you remember your password.

[Reactie gewijzigd door Conzales op 23 januari 2013 15:56]

Alsnog wat vreemd. Als de data niet kan worden geopend tot je de sleutel weer herinnert, hoe kan de master key dan worden gedecrypt en opnieuw ge-encrypt? Dat zou betekenen dat de master key los op de server staat - zeer slecht idee. Er mist informatie, of ik ben erg dom, of beiden. Kan iemand dit toelichten?
Nee er mist niks. Met de masterkey alleen kunnen de bestanden niet ontsleuteld worden. Het wachtwoord is waar het om draait. Deze is onderdeel van de totale encryptie op de bestanden. Om die te ontsleutelen heb je het originele wachtwoord nodig. Bestanden zijn dus versleuteld met een aparte (public) key die is gemaakt met de masterkey + het wachtwoord + overige "entropy". Wachtwoorden zijn onbekend voor Mega.
Wachtwoorden zijn onbekend voor Mega.
Heb je daar bewijs van? Ik heb namelijk geen idee hoe wachtwoorden daar worden opgeslagen. Het is allemaal wat vaag.
En waarom nu nog beginnen met het invoeren van wachtwoordopties en dergelijke. Dat had Kim al lang geregeld moeten hebben. Dan maar een maand later deze dienst openen.
Het is niet vreemd als je begrijpt hoe het werkt.

De cryptografische sleutels waarmee jou bestanden zijn geencrypt is gebaseerd op je wachtwoord. Jij bent de enige die je wachtwoord weet, en als jij je wachtwoord kwijt bent ben je dan ook meteen de sleutels tot jouw bestanden kwijt.

Het enige dat MEGA aanbiedt is een opslagruimte voor enorme reeksen geencrypte data, en webapp eromheen. Zij zien niks van wat jij opslaat. Dat is het hele punt.
Daarnaast als "jij" je wachtwoord vergeet zijn de gegevens ook niet ZO belangrijk voor je.
Vraag mij af of Uncle Sam hier blij mee is. Het kan niet anders dat Dropbox op de achtergrond kan meekijken.
Natuurlijk niet, dat is het hele punt.
Uncle Sam zal niet blij zijn, maar hij woont in de VS en MEGA staat in Nieuw Zeeland.
Iedereen die zo naief is om privegegevens onversleuteld op te slaan in "The Cloud" :O moet zich maar eens afvragen of het verstanding is om uberhaupt belangrijke gegevens digitaal te verwerken. Snel een andere hobby zoeken zou ik zeggen. Geen enkele 'cyberlocker' kan mij garanderen dat gegevens veilig zijn. Controle heb je niet, punt. Eerst zelf versleutelen en dan uploaden!

[Reactie gewijzigd door Conzales op 23 januari 2013 23:40]

Een tool als https://www.boxcryptor.com/ doet momenteel al exact hetzelfde als Mega maar dan voor bestaande cloud oplossingen (standaard Skydrive, Dropbox,...) waardoor het geen belang heeft hoe zij het nu opslagen, alles is toch client side al encrypted.
De aanname dat als jezelf controle hebt over je gegevens hebt dat je dan veiliger af bent is ronduit belachelijk.

Bedrijven als Dropbox en Microsoft zijn dag in, dag uit bezig met het veilig maken van hun systeem. Als jij een keer een paar maanden vergeet een distro-update te doen, je PHP of FTP-server van veiligheidspatches vergeet te geven of een tijdje vergeet je systeem te monitoren op inbraak kun je gewoon de lul zijn. Bij een clouddienst heb je dat probleem simpelweg niet. Die hebben er mensen 24 uur per dag op zitten om de veiligheid van jouw gegevens te garanderen. De veiligste diensten zijn de diensten waar je geen omkijk naar hebt.

Dat je niet de controle over je eigen bestand kwijt wilt, is enigszins begrijpelijk. Maar ga niet net doen alsof je eigen bestanden beheren ook 'veiliger' is. Controle is niet hetzelfde als veiligheid.
De geschiedenis zal het leren. Ik ben bang dan je ongelijk hebt. Bedrijven zijn niet te vertrouwen met persoonlijke gegevens. Dat is keer op keer bewezen. Hoe groter het bedrijf, hoe onveiliger gegevens zijn.

Als je verstand van zaken hebt is een eigen server veiliger, makkelijker en vooral sneller dan een 'remote' oplossing. FreeBSD + jails + GELI AES encryptie met keys & wachtwoord all the way! Alle poorten dicht, behalve voor toegang extern via VPN en eventueel poorten voor de mailserver en webserver. Alle protocollen beveiligd met SSL of via SSH.

Offsite backup en het delen van bestanden, daar is het enige waar "The cloud" *blech* goed voor is! Vraag maar aan Amazon klanten en vooral bedrijven die verschillende keren niet bij hun bestanden konden. Of je moet vooral bij KPN zijn, ook zo lekker betrouwbaar,.. NOT.

[Reactie gewijzigd door Conzales op 23 januari 2013 23:59]

Iedereen die zo naief is om privegegevens onversleuteld op te slaan in "The Coud" :O moet zich maar eens af vragen of het verstanding is om uberhaupt belangrijke gegevens digitaal te verwerken. Snel een andere hobby zoeken zou ik zeggen. Geen enkele 'cyberlocker' kan mij garanderen dat gegevens veilig zijn. Controle heb je niet, punt. Eerst zelf versleutelen en dan uploaden!
En/of gewoon je eigen cyberlocker gebruiken. Harde schijven kosten niets in verhouding met wat het oplevert qua ruimte. Een NAS met PHP kan prima iets draaien zoals AjaXplorer. Dat werkt natuurlijk ook op een 'gewone' server van jezelf. ;)

[Reactie gewijzigd door The Zep Man op 23 januari 2013 16:43]

Daar ben ik inderdaad ook zelf een voorstander van. Gewoon lekker zelf doen. Meer mogelijkheden en vooral veiliger. Een centraal opslagpunt in huis is gewoon het meest ideale en werkt prachtig; betrouwbaar, snel, veilig.
Tot het moment dat je huis afbrandt. Als je het goed wilt doen zul je ook buitenshuis een backup van al je data moeten opslaan.

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