[R] StringEncrypt vs Crypt_HashData

Aide et conseils concernant AutoIt et ses outils.
Règles du forum
.
Répondre
Avatar du membre
scorp84
Niveau 7
Niveau 7
Messages : 405
Enregistré le : mar. 04 nov. 2008 21:51
Localisation : Avignon, France
Status : Hors ligne

[R] StringEncrypt vs Crypt_HashData

#1

Message par scorp84 »

Bonjour à tous,

A la suite d'un post récent Matwachich (http://autoitscript.fr/forum/viewtopic. ... 335#p46335) m'a conseillé d'utiliser Crypt_HashData à la place de StringEncrypt :
matwachich a écrit :PS: @scorp84: Pour un mot de passe il vaut mieux utiliser un Hash, car quand on le crypte, on peut facilement le décrypter comme je l'ai fait plus haut, mais un Hashage est irréversible.
Voir du coté de _Crypt_HashData
Hors en essayant d'en savoir un peu plus sur le "hashing", je suis tombé sur un site qui permet à partir d'un hash de retomber sur ces pattes via un dictionnaire et ce en quelques secondes malgré un mot de passe relativement complexe.

Que vaut il mieux utiliser pour encoder ses mots de passe ?

Merci d'avance.

Cordialement.

BM
Modifié en dernier par scorp84 le mer. 06 avr. 2011 11:23, modifié 3 fois.
Avatar du membre
zeshrek
Niveau 10
Niveau 10
Messages : 984
Enregistré le : mer. 17 nov. 2010 09:31
Localisation : Sur ma chaise
Status : Hors ligne

Re: [..] StringEncrypt vs Crypt_HashData

#2

Message par zeshrek »

en un mot ? rien !

Ca a déjà été dit plein de fois, et on a même fait une démo.
A partir du moment ou tu fournis un script autoit (même compilé, et même avec obfuscation), on peut accéder au code.
Si on peut accéder au code, on peut récupérer le pass. c'est pas plus compliqué que ca.
Et même si tu te dis, bon, alors je me prend un hébergement, et je met les pass sur un serveur ou bien je met une procédure ou l'utilisateur tappe un pass qui est envoyé tel quel sur le serveur, qui le check, et renvoie un jetton (ok ou ko selon que le pass est valide ou non) le probleme est le même.
A un moment il y a qqchose (le pass ou le jetton) qui est dans une variable et que tu teste.
Il suffit donc soit de changer le test (pour faire en sorte que le prog continue si c'est pas bon) soit de faire une simple msgbox qui affiche le contenu de ce qui est bon, et de le mettre dans une constante.

désolé.
Si vis pacem para bellum
Avatar du membre
scorp84
Niveau 7
Niveau 7
Messages : 405
Enregistré le : mar. 04 nov. 2008 21:51
Localisation : Avignon, France
Status : Hors ligne

Re: [..] StringEncrypt vs Crypt_HashData

#3

Message par scorp84 »

Merci pour la réponse.

C'est malheureusement ce que j'avais compris mais le post de Matwachich m'avait laissé entrevoir une lueur d'espoir... snif :-(

Amicalement.

BM
Avatar du membre
matwachich
Membre émérite
Membre émérite
Messages : 986
Enregistré le : lun. 19 oct. 2009 04:04
Localisation : Algérie
Status : Hors ligne

Re: [R] StringEncrypt vs Crypt_HashData

#4

Message par matwachich »

Oula!
Alors comme ça, on peut récupérer une donné haché! Mon dieux! Et moi qui croyait que c'était pas possible!
Je vais chercher ce site, et me renseigner sur le meilleur algo de hash
Merci pour l'info
Sortons VW du coté obscure! - La curiosité est un vilain défaut! Cliquez ici
Avatar du membre
scorp84
Niveau 7
Niveau 7
Messages : 405
Enregistré le : mar. 04 nov. 2008 21:51
Localisation : Avignon, France
Status : Hors ligne

Re: [R] StringEncrypt vs Crypt_HashData

#5

Message par scorp84 »

Je te l'envoie en MP.

Amicalement.

BM
Avatar du membre
jchd
AutoIt MVPs (MVP)
AutoIt MVPs (MVP)
Messages : 2282
Enregistré le : lun. 30 mars 2009 22:57
Localisation : Sud-Ouest de la France (43.622788,-1.260864)
Status : Hors ligne

Re: [R] StringEncrypt vs Crypt_HashData

#6

Message par jchd »

Allons, par principe il existe une infinité de chaînes en entrée (plaintext) qui produisent le même résidu (hash), pour tout tuple (encodage, algorithme, sel) donné.
On ne peut donc pas inverser un algorithme de hachage sans ambiguïté. Tout ce qu'on peut faire, c'est une table des hashs pour un minuscule sous-ensemble des combinaisons (plaintext, algo, sel). La probabilité de dénicher le bon plaintext d'après un hash dans une telle table est vite bornée par la longueur et la tortuosité de l'entrée, et bien entendu par la taille de la table.
Ceci dit, même un algo simple comme MD5 peut produire de l'ordre de 2^128 hashes distincts. Prenons une marge de sécurité et disons seulement 2^120 hashes possibles, soit de l'ordre de 1.3 10^36. C'est le nombre de molécules contenues dans 40 millions de tonnes d'eau, pour situer un ordre de grandeur. Ne serait-ce que stocker un seul couple (hash, entrée) pour chacun de ces hashes dépasse de beaucoup les possibilités technologiques.
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
Avatar du membre
zeshrek
Niveau 10
Niveau 10
Messages : 984
Enregistré le : mer. 17 nov. 2010 09:31
Localisation : Sur ma chaise
Status : Hors ligne

Re: [R] StringEncrypt vs Crypt_HashData

#7

Message par zeshrek »

certe, mais, si tu me donnes un autoit compilé, et même obfusqué, je fais sauter la protection par mdp (sout je vire la protec mdp, soir je change le mdp, soit je rajoute un 2eme mdp valide pour permettre a ceux qui ont un vrai pass de se loguer... bref, y a plein de solutions.
effectivement un MD5 n'est pas reversible, mais ca n'implique pas que ce sera mieux sécurisé...
Si vis pacem para bellum
Avatar du membre
jchd
AutoIt MVPs (MVP)
AutoIt MVPs (MVP)
Messages : 2282
Enregistré le : lun. 30 mars 2009 22:57
Localisation : Sud-Ouest de la France (43.622788,-1.260864)
Status : Hors ligne

Re: [R] StringEncrypt vs Crypt_HashData

#8

Message par jchd »

Je n'ai jamais dit le contraire !
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
Avatar du membre
zeshrek
Niveau 10
Niveau 10
Messages : 984
Enregistré le : mer. 17 nov. 2010 09:31
Localisation : Sur ma chaise
Status : Hors ligne

Re: [R] StringEncrypt vs Crypt_HashData

#9

Message par zeshrek »

Je sais bien.
Je précisais juste, pour etre sur qu'en lisant ton explication matwachich ou scorp84 ne se disent pas que puisqu'on ne peut pas faire un reverse de MD5, ca sécurisait plus les données.
voila voila.
Si vis pacem para bellum
Avatar du membre
scorp84
Niveau 7
Niveau 7
Messages : 405
Enregistré le : mar. 04 nov. 2008 21:51
Localisation : Avignon, France
Status : Hors ligne

Re: [R] StringEncrypt vs Crypt_HashData

#10

Message par scorp84 »

Merci à tous les 2 pour vos explications très claires.

Le site que j'ai trouvé possède une base de 500 millions de HASH :
► Afficher le texte
J'ai essayé avec le mot de passe Me0EqTMQvB qui me semble être quand même un mot de passe assez solide et il me l'a retrouvé immédiatement :-(

@jchd : Quand tu dis qu'il y a une infinité de chaînes qui produisent le même résidu hash, cela veut dire que si
je code une chaîne aléatoire très complexe et que j'utilise cette chaîne pour une identification, il me suffit d'avoir une autre chaîne (même très simple) qui donne le même hash pour pouvoir débloquer mon script.

Cela veut dire 1 hash => n chaînes d'origine :-(

A la lecture de la page de Wikipédia consacré au hash, je viens de comprendre l'utilité du hachage :
► Afficher le texte
Cela sert juste à créer une empreinte pour détecter un changement même infime d'une chaîne pour vérifier son intégrité et non pas à crypter.

Donc pour finir, et comme il avait déjà été dit sur ce forum..., tout ce qu'on met dans un script est récupérable d'une manière ou d'une autre, dommage :-(

PS : Si certains n'ont pas encore compris... Dernier rappel ;-)

Amicalement.

BM
Avatar du membre
jchd
AutoIt MVPs (MVP)
AutoIt MVPs (MVP)
Messages : 2282
Enregistré le : lun. 30 mars 2009 22:57
Localisation : Sud-Ouest de la France (43.622788,-1.260864)
Status : Hors ligne

Re: [R] StringEncrypt vs Crypt_HashData

#11

Message par jchd »

J'ai essayé avec le mot de passe Me0EqTMQvB qui me semble être quand même un mot de passe assez solide et il me l'a retrouvé immédiatement :-(
Si le hash est dans la BDD, l'accès sur index est effectivement très rapide.
@jchd : Quand tu dis qu'il y a une infinité de chaînes qui produisent le même résidu hash, cela veut dire que si
je code une chaîne aléatoire très complexe et que j'utilise cette chaîne pour une identification, il me suffit d'avoir une autre chaîne (même très simple) qui donne le même hash pour pouvoir débloquer mon script.
Exactement.
Cela veut dire 1 hash => n chaînes d'origine :-(
Oui, bien sûr. Toute entrée (plaintext) est mise en relation avec un seul des 2^128 (ou 2^beaucoup, on n'est pas à ça près) hashes possibles. Comme il y a un nombre infini d'entrées possibles, on a bien un nombre infini d'entrées qui correspondent à un hash donné. Un hash est une signature "assez" fiable, mais elle est horriblement ambigüe, mathématiquement parlant. Cela est vrai quelque soit le hash employé.

Un autre problème est de _provoquer_ une collision de hash : produire un fichier fortement similaire mais pas identique à un fichier donné, ayant tous les deux le même hash (avec un algo donné). De ce point de vue, on peut dire que MD5 est aujourd'hui trop faible pour être fiable, car on sait provoquer des collisions rapidement en modifiant l'entrée de façon plausible. Ceci signifie qu'un MD5 n'est plus suffisant pour juger de l'authenticité d'un document Word ou PDF ou texte (e.g. un contrat). Il peut voir son contenu modifié de façon plausible (sans que des bardées de caractères byzantins n'apparaissent) pour dire le contraire du document original, modifier une date d'effet, un montant de prestation, etc.

Des algorithmes de hash plus résistants (aux techniques d'attaque déployables aujourd'hui) existent, mais lorsqu'il s'agit de bétonner sérieusement une authenticité via hash (sans crypto), il est recommandé de produire plusieurs hashes d'algorithmes différents pour un fichier d'entrée donné. En effet, s'il est aujourd'hui possible de produire des collisions avec MD5, la possibilité de produire _simultanément_ des collisions avec MD5, SHA2 et Whirlpool (par exemple) devient objectivement négligeable et ce pour longtemps.
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
Avatar du membre
TommyDDR
Modérateur
Modérateur
Messages : 2104
Enregistré le : mar. 22 juil. 2008 21:55
Localisation : Nantes
Status : Hors ligne

Re: [R] StringEncrypt vs Crypt_HashData

#12

Message par TommyDDR »

Désolé de remonter le post mais je pense (dites moi si je me trompe) qu'il est possible d'instauré un system de mot de passe.

Il suffit simplement de hasher 2 ou 3 fois de suite le mot de passe (pour éviter les dicos) avant de le comparer.
Comme je n'ai pas beaucoup de temps, je fourni un code source d'un programme aux sceptiques pour qu'ils me retrouvent le mot de passe ;).
► Afficher le textecode
Have Fun.
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679
Avatar du membre
zeshrek
Niveau 10
Niveau 10
Messages : 984
Enregistré le : mer. 17 nov. 2010 09:31
Localisation : Sur ma chaise
Status : Hors ligne

Re: [R] StringEncrypt vs Crypt_HashData

#13

Message par zeshrek »

Bin, tu fais ton exe que tu compiles, et tu me le file.
Moi je le décompile, et je fais ca :
► Afficher le textecode
Et je recompile.
Ni vu ni connu j't'embrouille, et je te laisse deviner ce que je vais utiliser comme mot de passe pour acceder quand même a la suite tout en laissant croire a ceux qui ont le vrai mot de passe qu'ils sont les seuls a l'avoir.
Si vis pacem para bellum
Avatar du membre
Tlem
Site Admin
Site Admin
Messages : 11791
Enregistré le : ven. 20 juil. 2007 21:00
Localisation : Bordeaux
Status : Hors ligne

Re: [R] StringEncrypt vs Crypt_HashData

#14

Message par Tlem »

Houuuu. Décompiler c'est mal.
Tu as de la chance d'être un ogre, sinon le grand méchant loup te mangerait tout cru ... :lol:
Thierry

Rechercher sur le forum ----- Les règles du forum
Le "ça ne marche pas" est une conséquence commune découlant de beaucoup trop de raisons potentielles ...

Une idée ne peut pas appartenir à quelqu'un. (Albert Jacquard) tiré du documentaire "Copié n'est pas volé".
Avatar du membre
zeshrek
Niveau 10
Niveau 10
Messages : 984
Enregistré le : mer. 17 nov. 2010 09:31
Localisation : Sur ma chaise
Status : Hors ligne

Re: [R] StringEncrypt vs Crypt_HashData

#15

Message par zeshrek »

L'attaque et la défense sont les deux face d'une même pièce nommée sécurité.
Tu ne peux pas envisager la sécurité (c'est le but d'un mot de passe) sans te mettre dans la position de celui qui va vouloir la contourner.
Oui je sais, décompiler c'est le mal, mais en mêm temps cet exemple concret permet de montrer que le multi-hashage comme le propose Tommy donnerait une fausse impression de sécurité.
Autoit est tres faible coté sécurité, c'est un fait. Il se décompile trop facilement, et surtout le code obtenu est trop facilement compréhensible malgré une éventuelle obfuscation.
Donc rajouter des algos qui cryptent/codent ne sert a rien.
Il a été démontré (c'est balot, je ne sais plus par qui, mais de mémoire c'était lié aux failles de sécurité du net) que la sécurité ne peut etre ajoutée apres coup sur un système non sécurisé. On peut au mieux poser des rustines qui colmattent les brèches, et complexifient (en fonction des moyens du moment) suffisament l'acces aux données en clair pour rebuter les éventuels indélicats. le problème étant que les moyens évoluent (loi de Moore) et donc l'espérance de vie des moyens de sécurisation est tres limitée.
Mais on s'éloigne du sujet.

Tout ce que je voulais (désolé Tommy) c'est casser cette fausse impression de sécurité qu'aurait pu donner la solution proposée.

En résumé, ca sert a rien de mettre une porte blindée si les murs sont en carton.
Si vis pacem para bellum
Avatar du membre
TommyDDR
Modérateur
Modérateur
Messages : 2104
Enregistré le : mar. 22 juil. 2008 21:55
Localisation : Nantes
Status : Hors ligne

Re: [R] StringEncrypt vs Crypt_HashData

#16

Message par TommyDDR »

Oui, je ne nie pas qu'on pourra avoir accès à toutes les parties du code "protégé" par un mot de passe, c'était simplement une façon de protéger le mot de passe.

Mais il est vrai que le mot de passe est inutile à connaitre dans ce cas.
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679
Avatar du membre
scorp84
Niveau 7
Niveau 7
Messages : 405
Enregistré le : mar. 04 nov. 2008 21:51
Localisation : Avignon, France
Status : Hors ligne

Re: [..] StringEncrypt vs Crypt_HashData

#17

Message par scorp84 »

Bonjour,

Vu que la conversation continue, je me suis permis de remettre le fil en [..] (si ce n'est pas souhaitable, je le refermerai ;-)

Si la faiblesse est dans le code source, n'existerait-il pas un compilateur plus musclé que celui par défaut pour que nos petits codes soient un peu plus à l'abri ? Est ce pareil dans les autres langage de programmation ?

Amicalement.

BM
Avatar du membre
zeshrek
Niveau 10
Niveau 10
Messages : 984
Enregistré le : mer. 17 nov. 2010 09:31
Localisation : Sur ma chaise
Status : Hors ligne

Re: [..] StringEncrypt vs Crypt_HashData

#18

Message par zeshrek »

En fait le gros du problème vient du fait que d'une part le code source est tres facilement compréhensible (mais c'est aussi ce qui fait la force d'autoit, car du coup il est tres simple a apprendre), et aussi qu'il n'est pas compilé mais interprété. La 'compilation' consistant 'simplement' a merger l'interpreteur et le source. Il faudrait donc faire un véritable compilateur ce qui rendrait beaucoup plus compliqué de retrouver les sources depuis l'executable.
Ceci dit, dans l'absolu il est impossible de réelement protéger un mot de passe si l'utilisateur peut avoir acces au logiciel (le fichier executable) et a la machine sur laquelle tourne le logiciel.

Mais là on dérive grave vers des questions de sécurité qui dépassent largement le cadre d'Autoit...
Si vis pacem para bellum
Avatar du membre
scorp84
Niveau 7
Niveau 7
Messages : 405
Enregistré le : mar. 04 nov. 2008 21:51
Localisation : Avignon, France
Status : Hors ligne

Re: [..] StringEncrypt vs Crypt_HashData

#19

Message par scorp84 »

Merci pour ton complément d'info.

Je crois que je peux donc (re)clore le sujet.

Amicalement.

BM
Répondre