MEGA : le lien de confirmation de l’inscription serait un peu trop bavard

Comme toujours : attention à utiliser un mot de passe fort

Le 22 janvier 2013 à 16h17

3 min

Logiciel

Alors que MEGA est disponible depuis samedi dernier et que le niveau de son chiffrement a été mis en cause plusieurs fois depuis, un PoC (Proof of Concept) exploitant le lien de confirmation donné lors de l'inscription vient de faire son apparition. Il permettrait de récupérer de nombreuses informations, dont la fameuse master key protégeant l'ensemble du compte.

Depuis son lancement, MEGA a été décortiqué dans tous les sens, notamment au niveau du chiffrement utilisé. Pour rappel, celui-ci exploite l'AES-128 pour les fichiers stockés, ainsi qu'une paire de clefs RSA 2048 bits pour le partage de compte à compte (voir notre dossier).

Si l'entropie de cette dernière a été mise en cause, tout comme sa confidentialité (elle est stockée en clair dans le Session storage du navigateur), le plus gros souci pourrait être ailleurs : le lien de confirmation envoyé à votre inscription contiendrait de nombreuses informations sensibles selon @Sc00bzT, comme le fait remarquer Bluetouff.

Il serait en effet composé, entre autres, de :

Votre master key chiffrée
L'empreinte de votre mot de passe
Votre adresse mail
Votre nom

Pour rappel, celui-ci se présente sous la forme d'une URL fixe (https://mega.co.nz/#confirm) suivie de 119 caractères (dans notre essai). Le tout est donc bien entendu chiffré, mais le développeur a mis en ligne un outil qui se propose de tenter de deviner ces informations depuis ce simple lien dont le code est disponible et publié sous GPL v2. D'après nos essais, celui-ci ne s'appuie pour le moment que sur le CPU et sur un seul coeur, et il n'a pas encore réussi à déchiffrer les données de notre compte de test.

Pour cela, il semble utiliser une attaque par « Brute force » en tentant toutes les combinaisons possibles, mais peut aussi exploiter une liste de mots préparée à l'avance pour essayer de gagner du temps. Autant dire que si votre mot de passe est un tant soit peu complexe, vous ne devriez rien avoir à craindre, n'hésitez néanmoins pas à détruire le mail reçu par Mega une fois votre inscription finalisée.

There have been a few wrong reports about our encryption & security. Expect a blog post on #Mega later today.

— Kim Dotcom (@KimDotcom) Janvier 22, 2013

Quoi qu'il en soit, si cette information se vérifie, on se demande comment MEGA a pu avoir l'idée de créer un lien contenant tant d'informations, envoyées par mail qui plus est (un mail est une carte postale). Dans la matinée, Kim Dotcom indiquait que des informations seraient données concernant la sécurité de MEGA. À l'heure où nous écrivons ces lignes, il n'en est toujours rien.

Commentaires (53)

Obelixator

Le 22/01/2013 à 16h23

Système de chiffrement pour se protéger des ayants-droit, mais plus ou moins volontairement en carton pour que des services tiers puissent exploiter le stockage mis à disposition ? " />

David_L Abonné

Le 22/01/2013 à 16h24

Obelixator a écrit :

Système de chiffrement pour se protéger des ayants-droit, mais plus ou moins volontairement en carton pour que des services tiers puissent exploiter le stockage mis à disposition ? " />

Euuuh, y’a une API pour ça hein ;)

Obelixator

Le 22/01/2013 à 16h28

David_L a écrit :

Euuuh, y’a une API pour ça hein ;)

Je sais " /> … Mais de ce style ? " />

David_L Abonné

Le 22/01/2013 à 16h30

Obelixator a écrit :

Je sais " /> … Mais de ce style ? " />

ça n’a rien à voir avec un chiffrement foireux ou non, c’est juste une liste de liens rajoutés manuellement (j’ai viré l’URL, ça n’a rien à faire ici ;) )

Florent_ATo

Le 22/01/2013 à 16h31

Depuis son lancement, MEGA a été décortiqué dans tous les sens, notamment au niveau du chiffrement utilisé.

Le dossier de Ars Technica sur le sujet est également très intéressant : Ars Technica

J’attends avec impatience les explication de l’équipe Mega sur le sujet.

Naneday

Le 22/01/2013 à 16h32

On est les seuls a avoirs accès a ce lien donc bon ..

Obelixator

Le 22/01/2013 à 16h33

David_L a écrit :

ça n’a rien à voir avec un chiffrement foireux ou non, c’est juste une liste de liens rajoutés manuellement

" />

David_L a écrit :

(j’ai viré l’URL, ça n’a rien à faire ici ;) )

DSL " />

Arcy Abonné

Le 22/01/2013 à 16h34

Oh mais … MAIS C’EST MONSTRUEUX !!!

J’ignorais que tu [David Legrand] avais basculé sur W8 !

La fin du monde est proche, repentisses-vous !!! " />

" />

Sinon, de telles “failles” sont pitoyables. On dirait qu’ils n’ont jamais eu l’idée de tester quoi que ce soit.

Conserver temporairement ces données dans la BdD Mega puis envoyer un lien unique validant les infos auraient été plus “sécurisé”.

blamort

Le 22/01/2013 à 16h37

David_L a écrit :

ça n’a rien à voir avec un chiffrement foireux ou non, c’est juste une liste de liens rajoutés manuellement (j’ai viré l’URL, ça n’a rien à faire ici ;) )

Moins que le lien de la news sur MegaCracker 0.1a ? " />

crocodudule

Le 22/01/2013 à 22h50

Je bloque sur un point.

Pas vraiment sur la qualité du cryptage: au final, la robustesse de celui-ci doit surtout permettre d’empêcher un accès massif aux données stockées et échangées, que certains exploits permettent d’accéder à quelques comptes aux mots de passe courts ou mal choisis, semblent inévitable au regard du public “cible”.

En revanche, mega propose la possibilité de partager un fichier avec d’autres utilisateurs. (Comme dropbox, gdrive…).

Donc, les sites de partage vont à nouveau balancer un lien pour que les utilisateurs de Mega puissent accéder au fichier partagé.

Dans ce cas, en quoi Mega se protège plus que ne le faisait Megaupload à l’époque? Il sera toujours possible d’identifier un partage public d’un fichier protégé et de sommer Mega de le retirer sans quoi crack boom pas bien contrefaçon toussa?

Du coup, sauf à utiliser Mega de façon fermé (entre quelques utilisateurs qui se connaissent et sans rien de public), Mega s’expose comme il le faisait avec Megaupload dès qu’il est utilisé pour du partage public pour peu que l’on ait un compte….

crocodudule

Le 22/01/2013 à 22h54

mazaru a écrit :

Si une personne upload une œuvre soumise à des droits d’auteur sur Mega puis transmet le lien + la clef par un forum ou un site de référencement.

Est-ce que l’auteur ou la société qui le représente peuvent :

1 - demander à Mega le retrait de ce fichier ?

2 - savoir qui l’a mis à disposition ?

Vu que lorsqu’un autre utilisateur pompe de la passante pour accéder à un de tes fichiers partagés, ton quota est diminué, il semble à minima logique qu’un partage de fichier soit associé à un compte utilisateur donné. D’où ma remarque précédente. A la limite, on peut imaginer que l’on ne puisse pas remonter jusqu’au proprio du compte, en revanche, on doit pouvoir imposer à Mega de fermer le dit compte et à défaut de le faire, Mega sera condamné.

kikoo25

Le 22/01/2013 à 22h59

Sebdraluorg a écrit :

Tu n’aurais pas utilisé un compte mail de chez Microsoft (@live, @Hotmail, @Outlook) ?

Car perso j’attends toujours mes mails de validation pour ces comptes alors que pour les autres comptes ça s’est fait instantanément…

Au vu du message d’accueil, je ne serais pas étonné qu’ils bannissent les adresses du concurrent principal du partenaire principal " />

Athot a écrit :

Ah parce que vous vous avez reçu cet email de confirmation? " /> Moi ça fait deux jours que je l’attends " />.

Tu as regardé ta boite de SPAM; moi, c’est là qu’il était

crocodudule

Le 22/01/2013 à 23h18

Bon test fait:

on peut partager un fichier sans que celui qui télécharge ne dispose nécessairement de compte.

l’URL générée ne semble ne pas permettre d’identifier l’uploader,

on peut au moment où on génère le lien de partage donner: le nom du fichier et/ou la clef de décryptage et/ou la taille du fichier… afin que celui qui ouvre lien ait ou non ces infos (on doit aussi pouvoir segmenter les infos: une url pour le fichier, une autre pour la clef…).

Reste qu’incontestablement Mega, doit être en mesure de dire sur quel compte doit s’imputer le téléchargement. On peut donc lui intimer de supprimer le lien de partage et de donner l’identité du compte.

Si j’ai bien compris, on ne peut pas nécessaire retrouver l’ip du compte et donc remonter jusqu’au proprio physique, en revanche, Mega doit être en mesure de supprimer le dit compte (qu’il le souhaite ou qu’ayant droit l’impose), à défaut il sera responsable (il aura beau jeu d’affirmer que c’est impossible, il faut bien qu’il puisse identifier les comptes pour gérer les quotas et facturer de la BP supplémentaire pour les comptes pro…).

Donc, sauf la litanie sur l’obligation de respecter les droits d’auteur…, Méga utilisé pour du partage public, ne se protège pas plus qu’avant.

mazaru

Le 22/01/2013 à 23h34

crocodudule a écrit :

Bon test fait:

…

Reste qu’incontestablement Mega, doit être en mesure de dire sur quel compte doit s’imputer le téléchargement. On peut donc lui intimer de supprimer le lien de partage et de donner l’identité du compte.

Si j’ai bien compris, on ne peut pas nécessaire retrouver l’ip du compte et donc remonter jusqu’au proprio physique, en revanche, Mega doit être en mesure de supprimer le dit compte (qu’il le souhaite ou qu’ayant droit l’impose), à défaut il sera responsable (il aura beau jeu d’affirmer que c’est impossible

….

Oui j’ai aussi l’impression que c’est pareil qu’avant.

Quelques infos sur le site :

https://mega.co.nz/#copyright

Fuinril

Le 23/01/2013 à 00h03

Freud a écrit :

Ne pas comprendre que je demande des infos sur la méthode utilisée, car je n’ai aucune idée de comment on peut accéder au contenu d’un fichier en javascript, c’est quel niveau ? Everest ?

var fichier = \(('fileInput').files[0];

\)(‘hiddentextinput’).text = mega.crypt(fichier.readAsBinary(), getCookie(‘privateKey’));

form.submit();

PS : c’est juste un exemple hein, je ne sais pas si c’est fait comme ça

anonyme_b1310e1abfee987ce8fd2e6875b2e776

Le 23/01/2013 à 03h52

crocodudule a écrit :

Bon test fait:

on peut partager un fichier sans que celui qui télécharge ne dispose nécessairement de compte.

l’URL générée ne semble ne pas permettre d’identifier l’uploader,

on peut au moment où on génère le lien de partage donner: le nom du fichier et/ou la clef de décryptage et/ou la taille du fichier… afin que celui qui ouvre lien ait ou non ces infos (on doit aussi pouvoir segmenter les infos: une url pour le fichier, une autre pour la clef…).

Reste qu’incontestablement Mega, doit être en mesure de dire sur quel compte doit s’imputer le téléchargement. On peut donc lui intimer de supprimer le lien de partage et de donner l’identité du compte.

Si j’ai bien compris, on ne peut pas nécessaire retrouver l’ip du compte et donc remonter jusqu’au proprio physique, en revanche, Mega doit être en mesure de supprimer le dit compte (qu’il le souhaite ou qu’ayant droit l’impose), à défaut il sera responsable (il aura beau jeu d’affirmer que c’est impossible, il faut bien qu’il puisse identifier les comptes pour gérer les quotas et facturer de la BP supplémentaire pour les comptes pro…).

Donc, sauf la litanie sur l’obligation de respecter les droits d’auteur…, Méga utilisé pour du partage public, ne se protège pas plus qu’avant.

Disons que si le fichier s’appelle “Hobbit 18548484545p ULTRA HD BDRIP++.mkv” effectivement, il est aisé d’en demander la suppression.

Par contre si le fichier se nomme “Tata_Jeanine.rar” et que quelqu’un en demande la suppression prétendant (à tort ou à raison) que l’archive contient un film, Mega peut se protéger en disant qu’il leur est impossible de vérifier la nature du fichier étant donné qu’il est stocké chiffré.

Freud

Le 23/01/2013 à 09h02

Fuinril a écrit :

var fichier = \(('fileInput').files[0];

\)(‘hiddentextinput’).text = mega.crypt(fichier.readAsBinary(), getCookie(‘privateKey’));

form.submit();

PS : c’est juste un exemple hein, je ne sais pas si c’est fait comme ça

Effectivement, j’ai trouvé ça :http://www.w3.org/TR/file-upload/

Mais c’est HTML5 only apparemment (bon, ça ne pose plus vraiment de problème de nos jours).

Sebdraluorg

Le 23/01/2013 à 09h16

kikoo25 a écrit :

Tu as regardé ta boite de SPAM; moi, c’est là qu’il était

Eh, je sais qu’il m’arrive de faire de conneries, mais j’utilise hotmail depuis plus de 10 ans donc je sais que lors d’une inscription à un site j’ai 80% de chance de retrouver mon message dans spam… " />

Mais merci quand même " />

David_L Abonné

Le 23/01/2013 à 18h29

RRMX a écrit :

Disons que si le fichier s’appelle “Hobbit 18548484545p ULTRA HD BDRIP++.mkv” effectivement, il est aisé d’en demander la suppression.

Par contre si le fichier se nomme “Tata_Jeanine.rar” et que quelqu’un en demande la suppression prétendant (à tort ou à raison) que l’archive contient un film, Mega peut se protéger en disant qu’il leur est impossible de vérifier la nature du fichier étant donné qu’il est stocké chiffré.

Si tu connais le nom du fichier, c’est que tu as la clef, donc que tu peux le télécharger.

crocodudule a écrit :

Bon test fait:

on peut partager un fichier sans que celui qui télécharge ne dispose nécessairement de compte.

l’URL générée ne semble ne pas permettre d’identifier l’uploader,

on peut au moment où on génère le lien de partage donner: le nom du fichier et/ou la clef de décryptage et/ou la taille du fichier… afin que celui qui ouvre lien ait ou non ces infos (on doit aussi pouvoir segmenter les infos: une url pour le fichier, une autre pour la clef…).

Reste qu’incontestablement Mega, doit être en mesure de dire sur quel compte doit s’imputer le téléchargement. On peut donc lui intimer de supprimer le lien de partage et de donner l’identité du compte.

Si j’ai bien compris, on ne peut pas nécessaire retrouver l’ip du compte et donc remonter jusqu’au proprio physique, en revanche, Mega doit être en mesure de supprimer le dit compte (qu’il le souhaite ou qu’ayant droit l’impose), à défaut il sera responsable (il aura beau jeu d’affirmer que c’est impossible, il faut bien qu’il puisse identifier les comptes pour gérer les quotas et facturer de la BP supplémentaire pour les comptes pro…).

Donc, sauf la litanie sur l’obligation de respecter les droits d’auteur…, Méga utilisé pour du partage public, ne se protège pas plus qu’avant.

Tu sais qu’on a écrit un dossier sur MEGA ? " /> Tout est expliqué dedans ;)

Globalement :

MEGA connait ton IP, le service est chiffré, pas anonyme

Il y a des formulaires de demande de retrait

Si tu publie un lien + clef, le fichier est identifiable. Pas sans la clef

Je pense que MEGA peut faciler relier un lien à un compte et donc une IP

La question est ensuite de savoir, est-ce que :

Le fichier peut être supprimé ? Oui

Le compte peut être supprimé ? Oui, au bout de plusieurs abus

L’IP transmise ? Avec une décision de justice, sans doute que oui

Pour rappel, la seule protection que fourni le chiffrement, c’est de rendre le contenu illisible côté serveur. Si tu vas sur un forum public ou accessible pour donner un lien rattaché à un fichier illicite et à ta connexion internet, ce sera le même régime que d’habitude : des ennuis.

Mais personne n’a jamais dit que MEGA était pensé pour partager des fichiers illicites sans ennuis (certains naïfs qui n’avaient sans doute pas écouté / compris l’avaient par contre sans doute espéré)

crocodudule

Le 23/01/2013 à 22h06

Mea culpa mea maxima culpa, j ai effectivement zappé la dernière page du dossier. " />

Pour l IP il n était pas question de passer par les serveurs relais pour ensuite et seulement créer / authentifier un compte sur le serveur ‘maitre’ (Principe du proxy) ou j ai ingurgité une rumeur pour un fait établi ?

Pour le reste on est d accord, une éventuelle saisie des serveurs ne permettra pas de trouver le contenu, mais le partage public par certains obligera méga a retirer des liens et/ou fermer des comptes comme pour tous les services du genre. " />

psn00ps

Le 24/01/2013 à 01h24

Fuinril a écrit :

var fichier = \(('fileInput').files[0];

\)(‘hiddentextinput’).text = mega.crypt(fichier.readAsBinary(), getCookie(‘privateKey’));

form.submit();

PS : c’est juste un exemple hein, je ne sais pas si c’est fait comme ça

T’es violent dans ton exemple, je ne te souhaite pas d’avoir à uploader un fichier de 4Go " />

(indice: taille de hiddentextinput)

David_L Abonné

Le 22/01/2013 à 18h17

Sebdraluorg a écrit :

Mega génère et stock les clés (chiffrées elle aussi certes, mais par lui) et surtout coté serveur…

Il a donc bien eu connaissance du contenu, sans compter que rien ne prouve qu’il ne retient pas les clés.

Dés lors, je ne vois pas ce qui change par rapport à MegaUpload…

Pour Hotmail en spam, tu es certain ? Car rien chez moi ni sur Hotmail, ni Outlook et pareil pour 2 connaissances…

En quoi c’est généré côté serveur ? Pour le stockage, tu voudrais que ce soit géré comment, avec une clef par fichier ? Tout retenir par coeur, les stocker côté client (avec le risque inhérent) et devoir les avoir à chaque accès à la Web app ?

Oui j’ai eu le cas (pas sur Gmail) et il y a eu plusieurs utilisateurs dans ce cas (après ça peut ne pas toucher tout le monde)

Choub

Le 22/01/2013 à 18h23

L’intérêt est quasi-nul.. Si t’as accès au mail du bonhomme, alors tu peux changer le mot de passe.

Pis bon, en brute force.. bon courage.

127.0.0.1

Le 22/01/2013 à 18h36

Choub a écrit :

L’intérêt est quasi-nul.. Si t’as accès au mail du bonhomme, alors tu peux changer le mot de passe.

Pis bon, en brute force.. bon courage.

Bah non, justement on ne peut pas changer le mot de passe. Jamais.

Donc intercepter ce mail te laisse tout le temps nécessaire pour cracker le mot de passe, et donc accéder au compte utilsateur.

Sebdraluorg

Le 22/01/2013 à 18h36

David_L a écrit :

En quoi c’est généré côté serveur ? Pour le stockage, tu voudrais que ce soit géré comment, avec une clef par fichier ? Tout retenir par coeur, les stocker côté client (avec le risque inhérent) et devoir les avoir à chaque accès à la Web app ?

Les clés elles sont générées où ?

Donc en quoi a-t-il moins connaissance du contenu qu’avant ?

Je ne voudrais rien du tout, je m’interroge sur ce que cela peut avoir de différent pour lui face à un juge par rapport au modèle de MegaUpload.

David_L a écrit :

Oui j’ai eu le cas (pas sur Gmail) et il y a eu plusieurs utilisateurs dans ce cas (après ça peut ne pas toucher tout le monde)

Tu précises “pas gmail”, ok, mais quoi ? peux tu affirmer que ça passe pour un compte chez crosoft ?

Perso, je trouve un poil suspect le fait que j’ai tenté avec 4 adresses crosoft sans jamais rien recevoir alors que j’ai reçu directement le lien sur mon compte gmail et sur mon compte Facebook, et ce depuis la même machine…

killer63

Le 22/01/2013 à 18h40

si kim veut un créneau porteur, il faut qu’il lance beefupload. chacun pourra se faire son propre burger tipiak " />

Imprimer de la viande en 3D

David_L Abonné

Le 22/01/2013 à 18h40

Sebdraluorg a écrit :

Les clés elles sont générées où ?

Donc en quoi a-t-il moins connaissance du contenu qu’avant ?

Je ne voudrais rien du tout, je m’interroge sur ce que cela peut avoir de différent pour lui face à un juge par rapport au modèle de MegaUpload.

Tu précises “pas gmail”, ok, mais quoi ? peux tu affirmer que ça passe pour un compte chez crosoft ?

Perso, je trouve un poil suspect le fait que j’ai tenté avec 4 adresses crosoft sans jamais rien recevoir alors que j’ai reçu directement le lien sur mon compte gmail et sur mon compte Facebook, et ce depuis la même machine…

Toute la partie Crypto est gérée en JS en local. Les clefs sont stockées, mais chiffrées avec la masterkey de l’utilisateur (elle même chiffrée avec un hash spécifique à l’utilisateur).

La différence vis à vis de MU c’est que : sans les pass utilisateur les données sont inutilisables. Sans la clef AES, un fichier ne peut pas être téléchargé et son nom reste inconnu.

Pour Hotmail et Gmail j’ai testé moi même : Hotmail > Spam ; Gmail > Boite de réception. Mais ça a été reçu dans les deux cas.

Freud

Le 22/01/2013 à 19h07

David_L a écrit :

Toute la partie Crypto est gérée en JS en local. Les clefs sont stockées, mais chiffrées avec la masterkey de l’utilisateur (elle même chiffrée avec un hash spécifique à l’utilisateur).

La différence vis à vis de MU c’est que : sans les pass utilisateur les données sont inutilisables. Sans la clef AES, un fichier ne peut pas être téléchargé et son nom reste inconnu.

Pour Hotmail et Gmail j’ai testé moi même : Hotmail > Spam ; Gmail > Boite de réception. Mais ça a été reçu dans les deux cas.

Donc le fichier est chiffré avant envoi à MU ? C’est fait avec quoi ça ? Nouvelle feature du HTML5 ?

Sebdraluorg

Le 22/01/2013 à 19h10

David_L a écrit :

Toute la partie Crypto est gérée en JS en local. Les clefs sont stockées, mais chiffrées avec la masterkey de l’utilisateur (elle même chiffrée avec un hash spécifique à l’utilisateur).

Ok, je n’avais pas lu ce détail ;-)

David_L a écrit :

La différence vis à vis de MU c’est que : sans les pass utilisateur les données sont inutilisables. Sans la clef AES, un fichier ne peut pas être téléchargé et son nom reste inconnu.

Oui mais le fichier est chiffré coté serveur non ? " />

(/me devrait lire les docs plutôt que les commentaires)

David_L a écrit :

Pour Hotmail et Gmail j’ai testé moi même : Hotmail > Spam ; Gmail > Boite de réception. Mais ça a été reçu dans les deux cas.

Ok merci d’avoir confirmé pour Hotmail, je vais réessayer " />

batoche

Le 22/01/2013 à 19h40

jackjack2 a écrit :

Et le chiffrage, il sert à quoi?

Nothing " />

unCaillou

Le 22/01/2013 à 19h46

Freud a écrit :

Donc le fichier est chiffré avant envoi à MU ? C’est fait avec quoi ça ? Nouvelle feature du HTML5 ?

Sebdraluorg a écrit :

Oui mais le fichier est chiffré coté serveur non ? " />

La doc dit :

Tous les cryptages, décryptages et la génération de clés est mise en œuvre en Javascript, ce qui limite le débit à quelques MB/s et provoque une charge importante du CPU. Nous attendons avec impatience la mise en œuvre du projet de l’API HTML5 WebCrypto dans tous les principaux navigateurs, ce qui permettra d’éliminer ce goulet d’étranglement.

De toute façon, réfléchissez, si c’était chiffré côté serveur, Kim Dotcom ne pourrait pas sérieusement prétendre (juridiquement) qu’il n’a aucun moyen de savoir ce qui est stocké sur ces serveurs. C’est justement LE moyen de se déresponsabiliser, vu ses antécédents et sachant que la justice l’a en ligne de mire. " />

Sebdraluorg

Le 22/01/2013 à 19h53

unCaillou a écrit :

La doc dit :

Tous les cryptages, décryptages et la génération de clés est mise en œuvre en Javascript, ce qui limite le débit à quelques MB/s et provoque une charge importante du CPU. Nous attendons avec impatience la mise en œuvre du projet de l’API HTML5 WebCrypto dans tous les principaux navigateurs, ce qui permettra d’éliminer ce goulet d’étranglement.

De toute façon, réfléchissez, si c’était chiffré côté serveur, Kim Dotcom ne pourrait pas sérieusement prétendre (juridiquement) qu’il n’a aucun moyen de savoir ce qui est stocké sur ces serveurs. C’est justement LE moyen de se déresponsabiliser, vu ses antécédents et sachant que la justice l’a en ligne de mire. " />

" />

David_L Abonné

Le 22/01/2013 à 19h58

unCaillou a écrit :

La doc dit :

Tous les cryptages, décryptages et la génération de clés est mise en œuvre en Javascript, ce qui limite le débit à quelques MB/s et provoque une charge importante du CPU. Nous attendons avec impatience la mise en œuvre du projet de l’API HTML5 WebCrypto dans tous les principaux navigateurs, ce qui permettra d’éliminer ce goulet d’étranglement.

De toute façon, réfléchissez, si c’était chiffré côté serveur, Kim Dotcom ne pourrait pas sérieusement prétendre (juridiquement) qu’il n’a aucun moyen de savoir ce qui est stocké sur ces serveurs. C’est justement LE moyen de se déresponsabiliser, vu ses antécédents et sachant que la justice l’a en ligne de mire. " />

Des fois je me demande à quoi ça sert que je publie des dossiers " />

bzc

Le 22/01/2013 à 20h31

Freud a écrit :

Donc le fichier est chiffré avant envoi à MU ? C’est fait avec quoi ça ? Nouvelle feature du HTML5 ?

Ne pas lire un article qu’on commente il faut déjà un certain niveau, mais ne pas lire ce qu’on cite ça atteint des sommets.

Freud

Le 22/01/2013 à 20h45

bzc a écrit :

Ne pas lire un article qu’on commente il faut déjà un certain niveau, mais ne pas lire ce qu’on cite ça atteint des sommets.

Ne pas comprendre que je demande des infos sur la méthode utilisée, car je n’ai aucune idée de comment on peut accéder au contenu d’un fichier en javascript, c’est quel niveau ? Everest ?

Sebdraluorg

Le 22/01/2013 à 20h49

David_L a écrit :

Des fois je me demande à quoi ça sert que je publie des dossiers " />

Que celui qui n’a jamais peché me jette la première pierre ! " />

bzc a écrit :

Ne pas lire un article qu’on commente il faut déjà un certain niveau, mais ne pas lire ce qu’on cite ça atteint des sommets.

" />

mazaru

Le 22/01/2013 à 22h35

Si une personne upload une œuvre soumise à des droits d’auteur sur Mega puis transmet le lien + la clef par un forum ou un site de référencement.

Est-ce que l’auteur ou la société qui le représente peuvent :

1 - demander à Mega le retrait de ce fichier ?

2 - savoir qui l’a mis à disposition ?

Khalev

Le 22/01/2013 à 16h39

Naneday a écrit :

On est les seuls a avoirs accès a ce lien donc bon ..

C’est vrai que c’est reconnu qu’un mail c’est vachement sécurisé!

David_L Abonné

Le 22/01/2013 à 16h39

blamort a écrit :

Moins que le lien de la news sur MegaCracker 0.1a ? " />

Oui (mais si tu ne vois pas la différence, soit hein ;))

tomy13

Le 22/01/2013 à 16h44

C’est pour la sécurité du proprio de MEGA ce chiffrage pas pour celle de l’utilisateur de MEGA, une fois compris ce concept, reste plus que le choix.

" />

Fuinril

Le 22/01/2013 à 16h58

En quoi c’est une faille ?

Je veux dire, à un moment ou à un autre il faut transmettre électroniquement la clé de toutes façons, à partir de là….

Ensuite la clé est chiffrée, il n’y a que l’empreinte du mdp, je suppose que le lien n’est valide qu’une seule fois…

Bref, le principe est donc de tenter de deviner le mot de passe en brute force… tout comme on pourrait pirater n’importe quel compte de n’importe quel site…

Reste le coup de la clé que j’ai pas du tout compris…. elle est pas salté ? elle est saltée à partir du mot de passe ? En quoi le fait de connaitre le mdp permet de connaitre la clé ? Y a pas d’option “redonnez moi ma clé” sur Mega ?

Disons qu’une fois qu’on a accès au compte on peut tout faire à prioris, donc bon " />

David_L Abonné

Le 22/01/2013 à 17h06

Fuinril a écrit :

En quoi c’est une faille ?

Je veux dire, à un moment ou à un autre il faut transmettre électroniquement la clé de toutes façons, à partir de là….

Ensuite la clé est chiffrée, il n’y a que l’empreinte du mdp, je suppose que le lien n’est valide qu’une seule fois…

Bref, le principe est donc de tenter de deviner le mot de passe en brute force… tout comme on pourrait pirater n’importe quel compte de n’importe quel site…

Reste le coup de la clé que j’ai pas du tout compris…. elle est pas salté ? elle est saltée à partir du mot de passe ? En quoi le fait de connaitre le mdp permet de connaitre la clé ? Y a pas d’option “redonnez moi ma clé” sur Mega ?

Disons qu’une fois qu’on a accès au compte on peut tout faire à prioris, donc bon " />

C’est justement tout le propos de l’actu. Par contre ce que je me demande c’est quel peut bien être l’intéret d”exploiter toutes ces infos plutôt que de générer un token à usage unique d’une autre manière.

linconnu

Le 22/01/2013 à 17h25

En même temps le but de Kim Dotcom n’a jamais été de faire quelque chose d’ultra sécurisé. Le but est uniquement de ne plus avoir de responsabilité sur la légalité des fichiers.

Athot

Le 22/01/2013 à 17h31

Ah parce que vous vous avez reçu cet email de confirmation? " /> Moi ça fait deux jours que je l’attends " />.

anonyme_2f3903e95215529534670e36d84faaa5

Le 22/01/2013 à 17h38

Athot a écrit :

Ah parce que vous vous avez reçu cet email de confirmation? " /> Moi ça fait deux jours que je l’attends " />.

Pareil " />

Sebdraluorg

Le 22/01/2013 à 17h41

Athot a écrit :

Ah parce que vous vous avez reçu cet email de confirmation? " /> Moi ça fait deux jours que je l’attends " />.

Tu n’aurais pas utilisé un compte mail de chez Microsoft (@live, @Hotmail, @Outlook) ?

Car perso j’attends toujours mes mails de validation pour ces comptes alors que pour les autres comptes ça s’est fait instantanément…

Au vu du message d’accueil, je ne serais pas étonné qu’ils bannissent les adresses du concurrent principal du partenaire principal " />

sebc22

Le 22/01/2013 à 17h42

Bah le cryptage est là pour permettre à Mega de ne pas savoir ce qu’il y a sur le site, pas pour protéger les fichiers utilisateurs…

jackjack2

Le 22/01/2013 à 17h56

Athot a écrit :

Ah parce que vous vous avez reçu cet email de confirmation? " /> Moi ça fait deux jours que je l’attends " />.

Utilise une autre adresse email alors, il arrive immédiatement

jackjack2

Le 22/01/2013 à 17h57

sebc22 a écrit :

Bah le cryptage est là pour permettre à Mega de ne pas savoir ce qu’il y a sur le site, pas pour protéger les fichiers utilisateurs…

Et le chiffrage, il sert à quoi?

Sebdraluorg

Le 22/01/2013 à 18h00

sebc22 a écrit :

Bah le cryptage est là pour permettre à Mega de ne pas savoir ce qu’il y a sur le site, pas pour protéger les fichiers utilisateurs…

Dans ce cas pourquoi garde-t-il les clés ?

Car là à moins que son code ne soit audité et signé il ne peut pas prouver qu’il n’a pas connaissance de ce qui se trouve sur son serveur !

Juridiquement parlant, le modèle est exactement le même que pour MegaUpload !

David_L Abonné

Le 22/01/2013 à 18h04

Athot a écrit :

Ah parce que vous vous avez reçu cet email de confirmation? " /> Moi ça fait deux jours que je l’attends " />.

Attention, chez Hotmail & co ça passe en spam. Sinon c’est immédiat.

Sebdraluorg a écrit :

Dans ce cas pourquoi garde-t-il les clés ?

Pas comprite ?

Sebdraluorg

Le 22/01/2013 à 18h10

David_L a écrit :

Attention, chez Hotmail & co ça passe en spam. Sinon c’est immédiat.

Pas comprite ?

Mega génère et stock les clés (chiffrées elle aussi certes, mais par lui) et surtout coté serveur…

Il a donc bien eu connaissance du contenu, sans compter que rien ne prouve qu’il ne retient pas les clés.

Dés lors, je ne vois pas ce qui change par rapport à MegaUpload…

Pour Hotmail en spam, tu es certain ? Car rien chez moi ni sur Hotmail, ni Outlook et pareil pour 2 connaissances…

unCaillou

Le 22/01/2013 à 18h11

Sebdraluorg a écrit :

Dans ce cas pourquoi garde-t-il les clés ?

Car là à moins que son code ne soit audité et signé il ne peut pas prouver qu’il n’a pas connaissance de ce qui se trouve sur son serveur !

Juridiquement parlant, le modèle est exactement le même que pour MegaUpload !

Il garde les clés pour faciliter l’utilisation du service, t’as pas à te trimballer des clés de chiffrement avec toi, avec risque de perte, oubli,…

Mais techniquement, ce qui est sur le serveur MEGA (clés, fichiers,…) ne permet pas de connaitre le contenu des fichiers stockés, sauf à devoir bruteforcer ces clés.

Car le mot de passe est l’élément d’entrée de la chaine de chiffrement vers le contenu.

Catégories

Nous Suivre

À propos

MEGA : le lien de confirmation de l’inscription serait un peu trop bavard

Comme toujours : attention à utiliser un mot de passe fort

Commentaires (53)