Discussion :

[okoweb]

Bonjour,
J'ai réalisé un script de connexion en ajax. Avec un utilitaire comme firebug, les identifiants de connexion sont en claire visible. Est-il possible de les cryptés.

Merci d'avance...

[Golgotha]

Bonjour,

Un plugin MD5 peut être ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$.md5("password");

[okoweb]

Merci, mais que faire coté serveur pour retrouver (décrypter) le mot de passe initial crypté.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
$.post(
  'includes/login.php', 
  { user: username, pass: $.md5(password) },
  onLogin, 
  'json' );

Pour ce cas dans login.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$_POST['pass'] //est cryptée

Merci d'avance...

[Golgotha]

Normalement, même toi tu ne doit pas connaitre le contenue en claire.

Voilà comment ça ce passe avec un scénario ou un utilisateur s'inscrit par exemple sur un site web :

- L'utilisateur donne un mot de passe à sont inscription, tu le crypte en MD5 et l'enregistre en base de donnée.

Exemple :
Mot de passe de l'utilisateur : banane
Mot de passe crypter en MD5 : 5473e3f141e0328ce87dac9366e0aace

En base de donnée on a uniquement le MD5

Ensuite, si l'utilisateur veux se loger, on lui demande sont mot de passe, on le passe en md5, et on le compare avec le md5 en base de donnée, si la comparaison est correcte, on connecte l'utilisateur. Ainsi, même si quelqu'un accède à ta base de donnée, il n’aura que les mot de passe crypté.

A savoir :

En changeant juste la casse d'une seule lettre dans le mot de passe, le hachage md5 sera complètement différent.

Texte : banane
MD5 : 5473e3f141e0328ce87dac9366e0aace

Texte : Banane
MD5 : f6ae02c12ed752bcdf92060492cf6572

Voilà, le but du md5 est de comparer deux hash.

j'espère que ça réponds à ta question

[Loceka]

Pour info c'est pas plus sécurisé (ni moins) d'appliquer le MD5 sur le mot de passe en javascript car :

1. tu pourras toujours récupérer le mot de passe en clair avec un outil comme firebug (car c'est un outil côté client qui aura toujours accès à ton javascript et donc à toutes tes variables, ce n'est pas du tout l'outil à prendre en compte/utiliser pour faire de la sécurité)
2. s'il y'a un man in the middle, le md5 sera visible "en clair" comme l'était le mot de passe auparavant et du coup le mec pourra se connecter au site en utilisant le md5 de même qu'il utilisait le mot de passe auparavant

La seule solution (qui me vienne à l'esprit) pour sécuriser la transaction, c'est de crypter la transaction elle-même.
Donc soit en passant par un protocole https, soit en cryptant soit-même la transaction avec une clef privée côté serveur et la clef publique correspondante côté client.
Afin d'avoir toujours une chaîne cryptée différente, il serait aussi pas mal d'ajouter des données aléatoires dans les données cryptées.

[Golgotha]

Mouai.

tu pourras toujours passer à travers la sécurité d'un programme.

Reste à savoir si c'est une connexion pour un site bancaire ou pour un forum de passionné de tricot...

Il me semble que le https demande un certificat et les certificats sont payant. Mais oui, c'est effectivement une mesure à mettre en place pour sécuriser la transaction.

[Loceka]

C'est surtout que faire le md5 côté client n'apporte strictement rien niveau sécurité.

La seule chose que ça apporte c'est la certitude pour l'utilisateur (qui regarderait le code source de la page) que son mot de passe ne sera pas stocké en clair dans une base.

[Golgotha]

C'est surtout que faire le md5 côté client n'apporte strictement rien niveau sécurité.

La seule chose que ça apporte c'est la certitude pour l'utilisateur (qui regarderait le code source de la page) que son mot de passe ne sera pas stocké en clair dans une base.

Oui c'est vrai, aucune raison de faire le passage en md5 coté client.

[okoweb]

La seule solution (qui me vienne à l'esprit) pour sécuriser la transaction, c'est de crypter la transaction elle-même.
Donc soit en passant par un protocole https, soit en cryptant soit-même la transaction avec une clef privée côté serveur et la clef publique correspondante côté client.
Afin d'avoir toujours une chaîne cryptée différente, il serait aussi pas mal d'ajouter des données aléatoires dans les données cryptées.

Je peux avoir une idée de code ?

Merci d'avance...

[Loceka]

J'ai jamais fait mais dans le principe, un cryptage asymétrique c'est :

1. le serveur génère un couple clef publique/clef privée (de façon durable ou juste pour la session)
2. le client génère lui aussi un couple clef publique/clef privée
3. le client (donc javascript) connaît uniquement la clef publique du serveur et le serveur uniquement la clef publique du client
4. le client encode ses message vers le serveur avec la clef du serveur
5. le serveur décrypte le message en utilisant sa clef privée et renvoie la réponse en utilisant la clef publique du client
6. le client décrypte la réponse du serveur en utilisant sa clef privée

Par contre la génération de couple clef publique/clef privée est apparement assez lent, ce qui fait qu'on a plutôt tendance, pour un cas comme ça, à utiliser un chiffrement hybride : utilisation d'un cryptage symétrique pour les messages et utilisation d'un cryptage asymétrique pour échanger la clef symétrique générée pour la transaction :

1. le serveur génère un couple clef publique/clef privée (le plus sûr est d'avoir une clef publique "signée" afin d'être sûr qu'elle n'est pas générée par une tierce personne interceptant la connexion)
2. le client génère une clef symétrique qu'il renvoie au serveur en utilisant la clef publique du serveur
3. le serveur et le client s'échangent leurs messages en utilisant les cryptant avec la clef symétrique temporaire

Après je te conseille de te renseigner sur comment implémenter ça.
L'algo le plus connu/utilisé pour le chiffrage asymétrique est le RSA par contre pour le chiffrage symétrique il en existe plein (AES, Blowfish, ...).