Discussion :

[philouuuu]

Bonjour

Pour un projet, j'accède au webserver d'une camera ip, j'ouvre un socket, j'envoie la bonne requête http, je reçois une image, pas de problème.

Dans la requête, je dois envoyer un cet argument :

Authorization: Basic YWRtaW46YWRtaW4=\r\n

Qui est enfet le login et le mot de passe (admin:admin)

Pour le moment j'ai trouvé YWRtaW46YWRtaW4= en sniffant une connection a l'application fournie par le constructeur de la camera.

J'aimerai pouvoir généré moi même ce code, pour que ce soit simple de changer de login et de password et de ne pas devoir à chaque fois sniffer une connection.

Sur ce site : http://www.securiteinfo.com/conseils/htaccess.shtml
j'ai trouvé ceci :

es informations de l'utilisateur circulent quasiment en clair sur le réseau. Prenons l'élément "crypté" : QWxpY2U6TGFwaW4=. Cet élément est en fait "login:password" uuencodé en base 64, ce qui n'est d'aucune protection (l'uuencodage est un procédé servant à coder du binaire en ASCII et inversement, autrement dit de passer de 24 à 32 bits tout en restant dans l'intervalle des caractères imprimables, ce qui permet de transférer des fichiers binaires sous forme de texte par exemple).

Est ce que quelqu'un sais comment effectué cet transformation? j'ai utilisé google mais sans succès.

J'espère avoir été clair

Merci

EDIT : j'ai oublié de précisé, je suis sous Vista et VS2008 (C++)

[ram-0000]

c'est de l'encodage et du décodage en base64, regarde ici : http://fr.wikipedia.org/wiki/Base64

[droggo]

Xou,

c'est de l'encodage et du décodage en base64, regarde ici : http://fr.wikipedia.org/wiki/Base64

+1

et envoyer login et mot de passe encodé en base64 est une très mauvaise idée.

[ram-0000]

et envoyer login et mot de passe encodé en base64 est une très mauvaise idée.

Oui mais pour le coup, on n'y peut pas grand chose. C'est dans la spec du protocole pour le www-authenticate (et aussi pour le proxy-authenticate). Il y a une méthode faible (qui utilise base64) mais tout le monde l'utilise

[droggo]

Zoa,

Oui mais pour le coup, on n'y peut pas grand chose. C'est dans la spec du protocole pour le www-authenticate (et aussi pour le proxy-authenticate). Il y a une méthode faible (qui utilise base64) mais tout le monde l'utilise

C'est bien le genre de truc qui me gêne ...

... encoder en base64, tu parles de la sécurité d'une authentification.

[JulienDuSud]

Bah en même temps, quand le protocole est ouvert, ça change quoi d'avoir un super cryptage ou pas de cryptage du tout ?

[Médinoc]

Bah en même temps, quand le protocole est ouvert, ça change quoi d'avoir un super cryptage ou pas de cryptage du tout ?

Ne pas se faire piquer les mots de passe admin?

Comme le terme "encodage" l'indique, le mot de passe est transmis non-crypté. Mais ne peut-on tout simplement utiliser HTTPS à la place de HTTP? Vu que la sécurité est au niveau transport, tout sera crypté, mot de passe compris...

[JulienDuSud]

Ne pas se faire piquer les mots de passe admin?

Comme le terme "encodage" l'indique, le mot de passe est transmis non-crypté. Mais ne peut-on tout simplement utiliser HTTPS à la place de HTTP? Vu que la sécurité est au niveau transport, tout sera crypté, mot de passe compris...

Rien ne t'empêche de l'utiliser, https c'est au niveau transport, pas au niveau protocol. Crypter le protocole ne sert à rien si la manière de le décrypter est connu.

[Médinoc]

Pour moi, le protocole n'est pas crypté. Il n'y a cryptage qu'à partir du moment où il y a clé (vu que la méthode est toujours connue).

D'où la différence encodage/cryptage.
Encoder le mot de passe a un sens vu qu'il peut y avoir n'importe quoi dedans; mais ce sens n'a rien à voir avec la confidentialité, seulement avec l'intégrité.

[JulienDuSud]

Pour moi, le protocole n'est pas crypté. Il n'y a cryptage qu'à partir du moment où il y a clé (vu que la méthode est toujours connue).

D'où la différence encodage/cryptage.
Encoder le mot de passe a un sens vu qu'il peut y avoir n'importe quoi dedans; mais ce sens n'a rien à voir avec la confidentialité, seulement avec l'intégrité.

On est bien d'accord .

Ma réponse initiale s'adressait à droggo qui disait qu'un encodage base64 n'était pas suffisant.

Or, à partir du moment où on sait qu'un message ou une partie de celui-ci est crypté ou encodé d'une certaine manière, on peut le décrypter/décoder. Surtout que dans un protocole ouvert, la manière de le faire est connue. Maintenant, si on veut éviter que le mot de passe soit illisible par le premier sniffer venu, l'encodage est aussi utile qu'un cryptage dont la(les) clé(s) serai(en)t connue(s).

La seule méthode fiable pour éviter un MITM, à l'heure actuelle, reste la sûreté du transport, qui est d'une certaine manière atteignable via HTTPS. Et pour ça, rien ne t'empêche de rajouter une couche https à n'importe quel logiciel, déjà existant ou non, dont on possède le code source ou non.

[bacelar]

JulienDuSud, le cryptage, ce n'est pas crypté la manière de chiffrer mais rendre illisible, à des personnes ne connaissant pas un secret, le contenue du message.
Le secret, cela peut aussi bien t être une clé secret que l'un des éléments de la paire de clés public/privé.

Le fait que le protocole soit ouvert n'interdit en rien un cryptage efficace.

[JulienDuSud]

JulienDuSud, le cryptage, ce n'est pas crypté la manière de chiffrer mais rendre illisible, à des personnes ne connaissant pas un secret, le contenue du message.
Le secret, cela peut aussi bien t être une clé secret que l'un des éléments de la paire de clés public/privé.

Le fait que le protocole soit ouvert n'interdit en rien un cryptage efficace.

Et qu'obtiens-tu de plus qu'un encodage ?
Ca prendra 1h de plus au reverse-engineer d'aller trouver les clés et la méthode de décryptage dans le binaire, tout au plus. Bref, complètement inutile en somme.

[Médinoc]

Et qu'obtiens-tu de plus qu'un encodage ?
Ca prendra 1h de plus au reverse-engineer d'aller trouver les clés et la méthode de décryptage dans le binaire, tout au plus.

Ça, c'est seulement en cas de cryptage à secret partagé; ce qu'on peut contourner en utilisant du cryptage asymétrique. Et en utilisant correctement le cryptage asymétrique, on peut éviter également les attaques MITM.

[JulienDuSud]

Ça, c'est seulement en cas de cryptage à secret partagé; ce qu'on peut contourner en utilisant du cryptage asymétrique. Et en utilisant correctement le cryptage asymétrique, on peut éviter également les attaques MITM.

Bon.

Je vais reprendre les choses lentement.

Comment veux-tu protéger un protocole ouvert, qui par définition DONNE les méthodes de cryptage/décryptage ?

Que la clé soit différente pour chaque implémentation ne change rien au problème. Qu'elle soit calculée à la volée non plus. Il suffit de désassembler le binaire pour voir les clés en clair ou savoir comment les calculer.

En supposant que:
Le client/serveur doit savoir à un moment donné comment décrypter/crypter.

On peut admettre que:
Les clés seront en clair quelque part à un moment donné.

En partant de ça, et en admettant que tu possèdes au moins le client, tu peux retrouver la clé.
Lorsque tu as la clé, tu peux retrouver le message chiffré.

Et pour continuer dans ma démarche, même pour un protocole fermé, tu peux avec un bonne connaissance de la cryptographie retrouver la méthode et les clés. Ca demande juste plus de compétences en lecture asm.

Je ne dis pas que le cryptage est inutile, mais dans un protocole ouvert, un cryptage fort n'est pas plus utile qu'un cryptage faible. C'est la méthode et la sécurité de la transmission qui est importante.

Peux-tu me donner un exemple où il sera impossible pour quelqu'un, qui possède au moins le client, de décrypter un message ?

2 cas de figures:
Le client envoi un message: on peut récupérer le message en clair avant le chiffrement avec la clé publique du serveur
Le client réceptionne un message: on peut récupérer le contenu du message en le décryptant avec la clé privée qu'on récupère dans le code asm du client.

En sommes, tout ce que le MITM a à faire là dedans (et je le répète bien, pour un protocole ouvert) c'est de se faire passer pour le serveur au client. Le client ne saura jamais qu'il existe un "vrai" serveur. Et de se faire passer pour le client au "vrai" serveur. Le serveur ne saura jamais qu'il y a un "vrai" client. Un proxy, quoi.

[bacelar]

Et pour un cryptage symétrique, allez essayer de faire du reverse-engineering sur une puce "cleaper" qui s'autodétruit à coup d'acide en cas d'infraction physique.
Là il faut sortir la caméra thermique ou l'azote liquide, un jeu d'enfant.

[JulienDuSud]

Et pour un cryptage symétrique, allez essayer de faire du reverse-engineering sur une puce "cleaper" qui s'autodétruit à coup d'acide en cas d'infraction physique.
Là il faut sortir la caméra thermique ou l'azote liquide, un jeu d'enfant.

Non mais là on entre dans une protection hardware. Je peux comprendre pour une banque de le faire, mais je vois mal Google ou un fournisseur de webservice fournir les clients