Tu n'as rien compris (ou presque) [...]
Et tu ne comprends pas non plus [...]
En fait tu ne comprends pas que la sécurité [...]
[...] tu manipules des concepts que tu ne comprends pas
Cela montre que tu ne comprends pas
C'est bon? Il y en a suffisamment à ton goût?
Première remarque: peux-tu, s'il te plaît cesser ce genre de réflexion grotesque et irritante? Tu n'es pas dans ma tête et tu n'as en aucun cas le droit de me juger sur des propos que tu penses avoir compris ou pas. Tu ne me connais absolument en rien et tu peux te dispenser ce genre de commentaire.
Le problème de MD5 est là, il n'est pas résistant aux collisions.
J'ai parfaitement compris le chapitre sur les collisions. Ce n'est pas de cela que je parle ici.
On ignore quelle est l'entrée (donc en fait comment a été généré cette suite)
Ça n'est pas suffisant pour affirmer haut et fort que le niveau de sécurité est suffisant.
Mais cela veut dire quoi craquer une URL ici ? Tu illustres ce que je dis plus haut, tu manipules des concepts que tu ne comprends pas.
Bon. Je vais tâcher de rester calme et d'ignorer ce lancinant agacement de ta remarque concernant mes capacités à comprendre. À mon tour d'être didactique.
Ce que j'entends par "craquer une URL" est un raccourci de langage, je pensais que tu aurais saisi.
L'obtention ou l'interception d'une seule URL, révélant l'utilisation de MD5 a les conséquences suivantes: s'il est possible de retrouver la donnée d'entrée, il est probable qu'alors le schéma de cette donnée corresponde à des données identifiables par un autre moyen. Avant de me voler dans les plumes, je suis conscient qu'il s'agit de pure spéculation... jusqu'à présent. Or ce qui n'était que pure spéculation de ma part quant à MD5 s'est avéré parfaitement exact. Réfléchis donc un rien avant de balancer à la poubelle mon argumentation, ainsi que ce qui pourrait bien me faire dire ça. Tu ne connais (probablement) pas Lampiris (supposition de ma part, jusqu'à preuve du contraire) ni leurs équipes informatiques ni l'état de leurs connaissances en termes de sécurité (moi non plus, objecteras-tu, n'est-ce pas?) et tu me connais encore moins (ça, c'est une certitude).
Si le craquage d'un seul hash permet de reconstituer la partie hashée de l'URL (c-à-d la donnée d'entrée), alors il est possible qu'en générant des données d'entrée, répondant au même schéma, on aboutisse à l'URL de vidéos relatives à d'autres clients.
Or jusqu'à présent, rien ne permet d'être certain que la donnée d'entrée ne fasse pas moins de 32 caractères — je ne me contenterai pas d'une simple supposition, je te rassure. Et dans ce cas, la donnée d'entrée ayant servi à générer les 32 caractères d'une URL reçue (ou interceptée) peut très bien être retrouvée — craquer un hash MD5 d'une quinzaine de caractères par force brute est tout à fait possible dans des temps parfaitement raisonnables, surtout si on dispose de plusieurs semaines ou mois. D'autant plus que les données d'entrée sont — plus que probablement — alphanumériques et non binaires, ce qui réduit considérablement le nombre de possibilités d'entrée à évaluer (la surface d'attaque).
J'objecte quant à utiliser un nombre aléatoire, hashé via MD5: ce serait absurde. Une série de 32 caractères aléatoires aurait bien plus de sens. Quant à ce fameux nombre aléatoire que tu suggères, plus il est court, plus il a de chances d'être craqué par force brute en un temps relativement court, donc plus l'utilisation de MD5 est compromise. Et plus sa longueur se rapproche de 32, moins l'utilisation de MD5 a de sens par rapport à la génération de 32 caractères alphanumériques aléatoires. Sans compter que la suggestion d'utiliser un nombre aléatoire a encore moins de sens puisqu'elle réduit à 10 au lieu de 62 (10+2x26) le nombre de symboles à utiliser pour les combinaisons d'entrée, ce qui est encore plus facile à craquer.
Avec seulement 10 symboles (0 à 9), la longueur maximum "craquable" en un mois est de 17 avec le système que j'ai mentionné. Et si tous les codes d'entrées sont sur 17 chiffres (ou moins) on génère l'URL des vidéos de tous les clients en moins d'un mois... Note que ce raisonnement est indépendant de l'utilisation de MD5 ou tout autre fonction de hashage.
Combine avec ça que, des possibilités d'entrée à tester, on peut très bien éliminer les combinaisons aussi triviales que aaaaaaa*, bbbbb* etc. C'est ce genre de "divination" que les outils de craquage prennent parfaitement en charge.
Donc, en résumé: MD5 n'élimine pas la possibilité de retrouver une seule donnée d'entrée, ce qui pourrait amener à retrouver le schéma d'entrée, complet, du hashage, utilisé dans l'URL des vidéos, d'où la possibilité de retrouver, par synthèse, d'autres vidéos personnelles. En raison de l'utilisation qui a été faite de MD5, la robustesse de la sécurité des données personnelles en jeu ne dépend que de la longueur de la donnée d'entrée: plus la seconde est petite, plus la première se rapproche de zéro.
Or je soupçonne la longueur de cette donnée d'entrée d'être bien inférieure à 32. Je ne m'en tiendrai pas, comme je l'ai annoncé, à cette simple supposition.
Note une chose, mon propos est uniquement à propos de ça et du fait que devant le peu de données réellement contenues dans ce genre de vidéo, cela n'a pas une grande importance non plus.
L'importance que tu accordes aux données personnelles ou à leur volume n'entre pas en ligne de compte quant à l'obligation légale de les sécuriser et les moyens employés.
Mon propos est que l'utilisation de MD5, contrairement aux idées reçues, n'est pas une sécurisation suffisante comparé, par exemple, à un accès authentifié.
Je suis d'accord avec toi sur le fait que :
Cette vidéo est globalement inutilement complexe pour peu d'informations ;
Ce contenu pourrait être accessible dans l'espace client uniquement.
[^] # Re: Objectivité
Posté par FantastIX . En réponse au journal Les cons? ça ose tout!. Évalué à -1.
C'est bon? Il y en a suffisamment à ton goût?
Première remarque: peux-tu, s'il te plaît cesser ce genre de réflexion grotesque et irritante? Tu n'es pas dans ma tête et tu n'as en aucun cas le droit de me juger sur des propos que tu penses avoir compris ou pas. Tu ne me connais absolument en rien et tu peux te dispenser ce genre de commentaire.
J'ai parfaitement compris le chapitre sur les collisions. Ce n'est pas de cela que je parle ici.
Ça n'est pas suffisant pour affirmer haut et fort que le niveau de sécurité est suffisant.
Bon. Je vais tâcher de rester calme et d'ignorer ce lancinant agacement de ta remarque concernant mes capacités à comprendre. À mon tour d'être didactique.
Ce que j'entends par "craquer une URL" est un raccourci de langage, je pensais que tu aurais saisi.
L'obtention ou l'interception d'une seule URL, révélant l'utilisation de MD5 a les conséquences suivantes: s'il est possible de retrouver la donnée d'entrée, il est probable qu'alors le schéma de cette donnée corresponde à des données identifiables par un autre moyen. Avant de me voler dans les plumes, je suis conscient qu'il s'agit de pure spéculation... jusqu'à présent. Or ce qui n'était que pure spéculation de ma part quant à MD5 s'est avéré parfaitement exact. Réfléchis donc un rien avant de balancer à la poubelle mon argumentation, ainsi que ce qui pourrait bien me faire dire ça. Tu ne connais (probablement) pas Lampiris (supposition de ma part, jusqu'à preuve du contraire) ni leurs équipes informatiques ni l'état de leurs connaissances en termes de sécurité (moi non plus, objecteras-tu, n'est-ce pas?) et tu me connais encore moins (ça, c'est une certitude).
Si le craquage d'un seul hash permet de reconstituer la partie hashée de l'URL (c-à-d la donnée d'entrée), alors il est possible qu'en générant des données d'entrée, répondant au même schéma, on aboutisse à l'URL de vidéos relatives à d'autres clients.
Or jusqu'à présent, rien ne permet d'être certain que la donnée d'entrée ne fasse pas moins de 32 caractères — je ne me contenterai pas d'une simple supposition, je te rassure. Et dans ce cas, la donnée d'entrée ayant servi à générer les 32 caractères d'une URL reçue (ou interceptée) peut très bien être retrouvée — craquer un hash MD5 d'une quinzaine de caractères par force brute est tout à fait possible dans des temps parfaitement raisonnables, surtout si on dispose de plusieurs semaines ou mois. D'autant plus que les données d'entrée sont — plus que probablement — alphanumériques et non binaires, ce qui réduit considérablement le nombre de possibilités d'entrée à évaluer (la surface d'attaque).
J'objecte quant à utiliser un nombre aléatoire, hashé via MD5: ce serait absurde. Une série de 32 caractères aléatoires aurait bien plus de sens. Quant à ce fameux nombre aléatoire que tu suggères, plus il est court, plus il a de chances d'être craqué par force brute en un temps relativement court, donc plus l'utilisation de MD5 est compromise. Et plus sa longueur se rapproche de 32, moins l'utilisation de MD5 a de sens par rapport à la génération de 32 caractères alphanumériques aléatoires. Sans compter que la suggestion d'utiliser un nombre aléatoire a encore moins de sens puisqu'elle réduit à 10 au lieu de 62 (10+2x26) le nombre de symboles à utiliser pour les combinaisons d'entrée, ce qui est encore plus facile à craquer.
Avec seulement 10 symboles (0 à 9), la longueur maximum "craquable" en un mois est de 17 avec le système que j'ai mentionné. Et si tous les codes d'entrées sont sur 17 chiffres (ou moins) on génère l'URL des vidéos de tous les clients en moins d'un mois... Note que ce raisonnement est indépendant de l'utilisation de MD5 ou tout autre fonction de hashage.
Combine avec ça que, des possibilités d'entrée à tester, on peut très bien éliminer les combinaisons aussi triviales que aaaaaaa*, bbbbb* etc. C'est ce genre de "divination" que les outils de craquage prennent parfaitement en charge.
Donc, en résumé: MD5 n'élimine pas la possibilité de retrouver une seule donnée d'entrée, ce qui pourrait amener à retrouver le schéma d'entrée, complet, du hashage, utilisé dans l'URL des vidéos, d'où la possibilité de retrouver, par synthèse, d'autres vidéos personnelles. En raison de l'utilisation qui a été faite de MD5, la robustesse de la sécurité des données personnelles en jeu ne dépend que de la longueur de la donnée d'entrée: plus la seconde est petite, plus la première se rapproche de zéro.
Or je soupçonne la longueur de cette donnée d'entrée d'être bien inférieure à 32. Je ne m'en tiendrai pas, comme je l'ai annoncé, à cette simple supposition.
L'importance que tu accordes aux données personnelles ou à leur volume n'entre pas en ligne de compte quant à l'obligation légale de les sécuriser et les moyens employés.
Mon propos est que l'utilisation de MD5, contrairement aux idées reçues, n'est pas une sécurisation suffisante comparé, par exemple, à un accès authentifié.
Bien. On se comprend au moins sur ce point.