MassaliaLive.com

[sillicate]

Les codages simples, on en utilisait aux scouts. C'était marrant. Tu vas aussi nous expliquer les clés de cryptage 128bits et compagnies ?

[Betsamee]

sillicate, je vais tacher d'en expliquer ce que je comprend

[killerdemars]

Betsamee, pas mal comme premier post, très intéressant (sans ironie).

[Betsamee]

FSNLT JXY ZSJ WFHQZWJ ZSJ XFQJYJ ZS UFWFXNYJ JY ZS UWTKNYJZW FSNLT JXY AWFNRJSY UFX HTTQ FSNLT JXY ZS HFHF

Anigo est une ... (la flemme pour le reste )


EDITH : ah oualà j'ai trouvé un site qui bouge l'alphabet :

Spoiler: montrer

ANIGO EST UNE RACLURE UNE SALETE UN PARASITE ET UN PROFITEUR ANIGO EST VRAIMENT PAS COOL ANIGO EST UN CACA

[Betsamee]

Betsamee, pas mal comme premier post, très intéressant (sans ironie).

Merci, content que ca ait pu interesser, j'essaierais de monter un peu le niveau au fur et a mesure, meme si je me reserve le droit de parler de securite sans forcement parler de crypographie

[peezee]

Ouais d'ailleurs dès que c'est un peu plus compliqué y'a plus degun...

viewtopic.php?p=2953540#p2953540

[Garm]

Bonne idée ce topic. J'avais trouvé mes cours de cryto asymétriques vraiment intéressants/stimulants (alors qu'AES me donnait plutôt mal au crane), mais bon courage pour vulgariser

[gaby]

Voici nos cours d'audit informatique de l'an dernier.

http://libpfb.so/uploads/media/Cours_Securite_MCCA_2012_2013.pdf

Vous y trouverez ce dont parlait Bets la page précédente (cryptographie...)

[niqos]

gaby, merci bien !

[Odd]

Intéressant comme topic.

[jod.ko]

True !


Jodko.

[Betsamee]

Bonne idée ce topic. J'avais trouvé mes cours de cryto asymétriques vraiment intéressants/stimulants (alors qu'AES me donnait plutôt mal au crane), mais bon courage pour vulgariser

Je te rassure tout de suite, je compte pas vulgariser AES, j'en suis pas capable

[Betsamee]

Je reviendrais a la crypto un peu plus tard (je sors d'un séminaire de cryptographie passionnant ...) et vu que le sujet du topic est la sécurité informatique, je voulais vous présenter des attaques connues sur les mots de passes cette fois;

1) Attaques physiques

TODO

2) Attaques de timing

Essayez d'imaginer comment, si vous étiez un informaticien efficient, vous implementeriez (mettrez en oeuvre) un algorithme (logique du programme informatique) pour verifier un mot de passe entré par un utilisateur, de maniere efficace ?

La logique voudrait d'opérer de la sorte (pour économiser du temps de calcul inutile);


POUR CHAQUE CARACTERE DU MOT DE PASSE TAPE PAR L'UTILISATEUR
------SI LE CARACTERE #n EST EGAL A SON CORRESPONDANT #n DANS LE MOT DE PASSE A TROUVER
-------------ON CONTINUE LA COMPARAISON AVEC LE CARACTERE SUIVANT #n+1
------SINON
-------------C'EST LE MAUVAIS MOT DE PASSE FIN DE L'ALGORITHME

Disons que le mot de passe a trouver est "JOSEANIGOESTUNSACAMERDE" ?

Disons que l'utilisateur a essayé le mot de passe "DERUDA", a votre avis y a t'il besoin de comparer tous les caracteres pour arriver a la conclusion que ce n'est pas le bon mot de passe ?
Non , il suffit de remarquer que le premier "D" est different du premier "J" pour directement invalider le mot de passe "DERUDA" (temps de traitement tres court on tombe tout de suite dans le SINON).

Si par contre l'utilisateur avait essayé le mot de passe "JIMMYTRACTOR" le mot de passe n'aurait pu etre invalidé qu'a la comparaison du deuxieme caractere "I" vs "O".(temps de traitement court mais un peu moins, on ne tombe dans le SINON qu'a la deuxieme tentative).

Et ainsi de suite, si l'utilisateur avait entre "JOBELLO" , l'erreur n'aurait ete détectée qu'a la comparaison du troisieme caractere "B" vs "S".

Que ressort t'il de cela ? Plus le mot de passe est "ressemblant" , plus le temps de traitement est "long".

Donc en mesurant le temps de reponse pris pour chaque reponse , et en conservant le caractere de celui qui a pris le plus longtemps, on peut facilement trouver le mot de passe en un nombre de tentatives BIEN INFERIEUR a celui nécessaire si on voulait essayer tous les mots de passes possibles (force brute) jusqu'a tomber sur le bon.

Le principe dans bon nombre d'attaques est de limiter le champs de reponses a un nombre réalisable de maniere automatique, et la c'est exactement ce que l'on fait.

Avec cette methode pour trouver par exemple le mot de passe "4257" (juste numérique pour simplifier) prendrait un MAXIMUM de 10 + 10 + 10 +10 = 40 tentatives, alors que la force brute prendrait dans le pire des cas 10000 tentatives (en moyenne 5000).

Comment rémédier a cela?

On peut volontairement rendre l'algorithme moins efficace (on verra paradoxalement les algos efficaces sont souvent exploitables) en vérifiant a chaque fois TOUT les caracteres, meme si la comparaison échoue des le premier, de ce fait le temps de traitement sera toujours le meme, que le password soit tres loin ou tres proche du password a trouver.

3) Attaques de dictionnaires

TODO

[peezee]

Le temps de réponse un chouïa variable (ping) entre un pc et un serveur distant doit brouiller un peu cette approche par timing, nan...? (surtout vu que cette variation du "ping" est non négligeable vs le temps d'éxec de l'algo de vérif du passwd, voire lui est mm nettement supérieure, en gros tu as un rapport signal/bruit temporel inférieur à 1 quoi ^^)

[sonny]

Betsamee, C'est possible pour un serveur (ou un PC) de différer aléatoirement la réponse au mot de passes ? (via un algorithme par exemple).

[gaby]

Betsamee, j'y connais absolument rien et j'ai trouvé ton post très intéressant mais 2 choses m'interpellent.

La première est sur le temps de réponse, qui doit se limiter à un interval temps faible donc difficile à analyser 2 situations differentes à mon sens et la seconde c'est que pour mettre en œuvre cette pratique de décryptage, cela suppose un débit de connections constant, non ?

[peezee]

sonny, cette "faille" est très simple à contourner, soit en forçant un temps de réponse aléatoire comme tu dis soit mm en forçant un temps de réponse fixe. En plus d'un point de vue exécution sur le serveur ça ne prendrait quasi aucune ressource supplémentaire niveau CPU vu qu'il suffit de mettre un "wait" (qui est géré par un timer côté serveur, et pas par des boucles cpu ^^) pour faire durer la validation du mdp jusqu'au temps fixe, fin bref rien de bien sérieux.

[Betsamee]

Le temps de réponse un chouïa variable (ping) entre un pc et un serveur distant doit brouiller un peu cette approche par timing, nan...? (surtout vu que cette variation du "ping" est non négligeable vs le temps d'éxec de l'algo de vérif du passwd, voire lui est mm nettement supérieure, en gros tu as un rapport signal/bruit temporel inférieur à 1 quoi ^^)

Ce que tu dis est vrai dans certains cas, ou la reponse met du temps a parvenir du serveur vers le client.

Met il reste de nombreux cas ou l'exploit reste possible;
- L'exploit est effectue en local sur le serveur (ca arrive souvent, par exemple si tu essaie de cracker un logiciel tournant sur ton pc).
- L'acces est dans le reseau local ou la latence reseau est quasi constante et le bruit s'annule.
- Le serveur te donne en cadeau "cette page a ete generee en X msecs" en bas de la page, ce qui n;est pas rare et correspond exactement au temps de traitement sur le serveur sans aucun bruit cause par le reseau.

Betsamee, C'est possible pour un serveur (ou un PC) de différer aléatoirement la réponse au mot de passes ? (via un algorithme par exemple).

C'est completement possible, c'est une solution parfois utilisée, mais avec précaution, l'aleatoire généré par un ordinateur est pseudo-aléatoire et est un faux ami.

[Betsamee]

Mais ce qui est interessant c'est que cette methode peut etre extrapolée de maniere plus generale, si tu connais par exemple l'algorithme qui est utilisé dans un certain programme, et qu'a coup de tentatives et de mesures, tu arrive a isoler a quel moment tu te fais ejecter, tu peux deduire pas mal de choses sur le input que tu as rentre (pareil en electronique d'ailleurs, et je rentrerais pas ici dans les problematiques de Power Analysis, ou les gars sont capables de reverse-engineerer un circuit rien qu'en mesurant la consommation de power).

[Betsamee]

Betsamee, j'y connais absolument rien et j'ai trouvé ton post très intéressant mais 2 choses m'interpellent.

La première est sur le temps de réponse, qui doit se limiter à un interval temps faible donc difficile à analyser 2 situations differentes à mon sens et la seconde c'est que pour mettre en œuvre cette pratique de décryptage, cela suppose un débit de connections constant, non ?

J'ai en partie repondu plus haut , mais il faut bien savoir qu'en informatique tous les intervalles de temps, meme les plus faibles sont mesurables et quantifiables.