Mega reageert op kritiek op toegepaste cryptografie
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.
Reacties (119)
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.
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.
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.
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.
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.
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?Als je de hele collectie kinderporno, om maar iets te noemen waar andere niks van mogen weten
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.
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.
Over dooddoeners gesproken...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?
Kinderporno was slechts een voorbeeld. Het had ook iets anders kunnen zijn dat je goed wilt beveiligen.
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).
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 woensdag 23 januari 2013 19:35]
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.
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.
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
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 woensdag 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.
Heb je daar bewijs van? Ik heb namelijk geen idee hoe wachtwoorden daar worden opgeslagen. Het is allemaal wat vaag.Wachtwoorden zijn onbekend voor Mega.
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 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.
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.
En hoe denk je dat voor elkaar te krijgen? Een verbod afdwingen op het versleuteld opslaan van data in een cyberlocker? Op welke grond?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.
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
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
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.
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.
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 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.
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.
Vraag mij af of Uncle Sam hier blij mee is. Het kan niet anders dat Dropbox op de achtergrond kan meekijken.
Uncle Sam zal niet blij zijn, maar hij woont in de VS en MEGA staat in Nieuw Zeeland.
Natuurlijk niet, dat is het hele punt.
Iedereen die zo naief is om privegegevens onversleuteld op te slaan in "The Cloud" 
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!
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 woensdag 23 januari 2013 23:40]
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.Iedereen die zo naief is om privegegevens onversleuteld op te slaan in "The Coud"
[Reactie gewijzigd door The Zep Man op woensdag 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.
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.
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.
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 woensdag 23 januari 2013 23:59]
Daarnaast als "jij" je wachtwoord vergeet zijn de gegevens ook niet ZO belangrijk voor je.
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.
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.
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.
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.
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.
Je moet van het wachtwoord dus zelf een backup maken.
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.
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 donderdag 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.
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.
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.
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.
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.
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
Ook dan kan je alleen maar een nieuwe partitie / file aanmaken
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..
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..
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.
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.
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 woensdag 23 januari 2013 15:07]
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?
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?
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"?Dat een 'dump-site' niet voldoende beveilig zou zijn, dat is toch iets waar je als gebruiker vind ik rekening mee moet houden.
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'?
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'?
Waarom is het niet erg realistisch om kritiek te hebben op een dienst die niet levert wat ze zeggen te leveren?Kritiek mag je altijd hebben, maar erg realistisch is dat niet.
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)Als nu blijkt dat ze je password kunnen geven als jij hem krijt bent kunnen ze dus bij je data
[Reactie gewijzigd door .oisyn op woensdag 23 januari 2013 15:55]
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.Wil je dat niet gebruik dan gewoon dropbox, waarbij je weet dat de VS inzage hebben.
@.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 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.
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?
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?
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)
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?
Uiteraard mogelijk, maar met een perfecte encryptie zinloos.
Misschien om in te dekken de voorwaarden iets te ruim opgezet?
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.
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.
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.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.
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.
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.
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.
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.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.
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.
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.
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 woensdag 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!
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 woensdag 23 januari 2013 17:36]
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.
Maar inderdaad, je moet het niet als enige backup gebruiken. Met een on-site backup er bij zit je wel goed.
"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.
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 woensdag 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.
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.
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.
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.
Kijk eens naar KeePass of LastPass.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.
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).
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).
Ik had geregistreerd met een oud live.nl adres (in feite ook hotmail, tegenwoordig outlook) en daarbij kwam ook geen verificatiemail binnen.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.
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.
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.
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.
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).
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).
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.En met 'veilig' bedoel ik dan dat ik er van op aankan dat mijn gegevens niet in handen van derden terecht komen.
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 woensdag 23 januari 2013 16:00]
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?
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?
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 ;-)
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 woensdag 23 januari 2013 16:58]
Hmm zoveel kritiek... maar als je data zo belangrijk is waarom upload je het dan naar een cloud dienst?
Precies.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
