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

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

Comme toujours : attention à utiliser un mot de passe fort

Avatar de l'auteur
David Legrand

Publié dans

Logiciel

22/01/2013 3 minutes
53

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

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).

 

MegaCracker

 

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.

 

 

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.

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Fermer

Commentaires (53)


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 ? <img data-src=" />








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 ? <img data-src=" />





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









David_L a écrit :



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





Je sais <img data-src=" /> … Mais de ce style ? <img data-src=" />









Obelixator a écrit :



Je sais <img data-src=" /> … Mais de ce style ? <img data-src=" />





ç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 ;) )





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 :http://arstechnica.com/business/2013/01/megabad-a-quick-look-at-the-state-of-meg…



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


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








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





<img data-src=" />







David_L a écrit :



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





DSL <img data-src=" />



Oh mais … MAIS C’EST MONSTRUEUX !!!



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



La fin du monde est proche, repentisses-vous !!! <img data-src=" />



<img data-src=" />



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é”.








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 ? <img data-src=" />









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é!









blamort a écrit :



Moins que le lien de la news sur MegaCracker 0.1a ? <img data-src=" />





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



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.

<img data-src=" />


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 <img data-src=" />








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 <img data-src=" />





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.



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.


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








Athot a écrit :



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





Pareil <img data-src=" />









Athot a écrit :



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





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 <img data-src=" />



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…








Athot a écrit :



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





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









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?









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 !









Athot a écrit :



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





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 ?









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…









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.









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…







  1. 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 ?



  2. 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)



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.








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.









David_L a écrit :





  1. 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 :



  2. 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…



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



Imprimer de la viande en 3D








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 &gt; Spam ; Gmail &gt; Boite de réception. Mais ça a été reçu dans les deux cas.









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 &gt; Spam ; Gmail &gt; 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 ?









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 ? <img data-src=" />

(/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 &gt; Spam ; Gmail &gt; 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 <img data-src=" />









jackjack2 a écrit :



Et le chiffrage, il sert à quoi?





Nothing <img data-src=" />









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 ? <img data-src=" />





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. <img data-src=" />









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. <img data-src=" />





<img data-src=" />









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. <img data-src=" />





Des fois je me demande à quoi ça sert que je publie des dossiers <img data-src=" />









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.









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 ?









David_L a écrit :



Des fois je me demande à quoi ça sert que je publie des dossiers <img data-src=" />





Que celui qui n’a jamais peché me jette la première pierre ! <img data-src=" />







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.





<img data-src=" />



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 ?



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….








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é.









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 <img data-src=" />









Athot a écrit :



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





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



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.








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









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









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é.









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).









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… <img data-src=" />



Mais merci quand même <img data-src=" />









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 ? <img data-src=" /> 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é)



Mea culpa mea maxima culpa, j ai effectivement zappé la dernière page du dossier. <img data-src=" />



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. <img data-src=" />








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 <img data-src=" />

(indice: taille de hiddentextinput)