Ajax et password, avis

Salut,

Je suis sur une application full Ajax et j'aimerais avoir votre avis sur la sécurité de celle-ci, en particulier au niveau des transferts des mots de passe.

J'ai une table User dont un champ pwd (varchar de 32) qui contient les mot de passe de mes tuples, les valeurs de ce champ sont cryptées en md5.
Pour le login de l'application, je fais une requête Ajax vers une page php d'authentification qui envoie le pseudo et le mot de passe de l'utilisateur (en POST). Une fois les variables reçues par la page d'authentification, j'effectue une requête sql en cryptant au préalable le mot de passe en md5.

Voila ma question est donc la suivante, est-ce sécurisé?
Dans ma console firebug je vois bien mes requêtes Ajax ainsi que les valeurs de mes variables. Ne devrais-je pas crypter en md5 au niveau du javascript? Cela changerait-il quelque chose?

Vous l'auriez compris, je suis un peu perdu. Un peu d'éclaircissement me serait bien utile.

Tu peux toujours essayer de crypter en js, mais vu qu'un MD5 faut y mettre un salt rigoureusement secret pour éviter les attaques à base de dico… c'est pas la solution. Le choix du MD5 peut être contestable en lui même remarque.

Pour être tranquille utilise SSL, pas de problème pour envoyer les données sensibles avec ça, c'est fait pour.
Modifié par nod (05 Jun 2009 - 14:26)

nod a écrit :
Pour être tranquille utilise SSL, pas de problème pour envoyer les données sensibles avec ça, c'est fait pour.

+1
et au passage md5 n'est pas un cryptage mais un hashage.

Au temps pour moi.

Il est possible d'avoir un petit exemple?

Pour moi SSL c'est un protocole de sécurité qui consiste à utiliser une combinaison entre clé publique/clé privée.
Après il peut être basé sur du MD5, SHA, RSA, DES...

Avec le md5 la clé publique est représenté par le mot de passe et le salt est la clé privée.
Je me trompe?

Donc déjà un point d'éclaircie, c'est que le hashage du mot de passe doit bien se faire du côté php.

Salut,

concrètement cela correspond à une URI commençant par HTTPS://

Il faut voir en fonction de ton hébergement comment l'utiliser. Pour te donner un exemple cela donne chez OVH quelque chose comme https://ssl2.ovh.net/~example/example.php

Hello,

Envoyer le mot de passe "en clair" (c'est à dire en http:// plutot qu'en https://) te fais courir le risque que quelqu'un qui écoute ta conversation (si tu passes par un proxy, par un réseau, ou tout simplement sur un wifi mal sécurisé) puisse avoir accès à tes pass au moment où ceux-ci transitent.

Que l'information passe en une requete POST, GET, en Ajax ou depuis un simple formulaire ne change pas grand chose, l'info sera toujours là en clair.

Faire le hashage de la clé coté client n'aidera pas à protéger l'info, au contraire même, cela donne de grandes informations sur ton système de mot de passe à un éventuel intrus : tu lui dis que tu utilises md5 et tu lui fourni même le salt.

La solution ultime est donc effectivement de faire la requete de transaction en https://, à voir si ton hébergeur le permet et il te faudra configurer ton serveur en fonction.
Une autre solution, ou plutot une autre amélioration, serait de remplacer md5 par un autre algo de hashage plus difficile à percer, tel que sha1 (ou sha256)

Après quelques recherches j'ai bien cerné le problème.
J'essaie donc passer par un système RSA.

Au moment du clic du login, une requête ajax est envoyée à 'php/gen_pkey_RSA.php' pour récupérer une clé RSA publique.

gen_pkey_RSA.php créé une paire de clé RSA, stock dans $_SESSION('RSA') la clé RSA et renvoie seulement la clé publique.

Une fois la clé publique reçus, je crypte les données puis je fais une demande d'authentification.
Côté serveur, avant de questionner la base de donnée je décrypte les données avec la clé RSA privée.


Seulement voila je me heurte à des problèmes de nombre infini.
En théorie mon algo est correct mais mes nombres dépassent les valeurs maximales

Même si je génère mes clés avec des entiers p et q très petit je me retrouve avec des modulos non corrects due à des approximations de résultat.
Modifié par Glopp (09 Jun 2009 - 15:10)

Pour l'hébergeur, l'application est prévue pour tournée sur un Intranet.

Tymlis, sinon à défault d'une solution RSA ou https, pour le sha1 je hash mes données côté client et j'envoie les données hashées?
Modifié par Glopp (09 Jun 2009 - 15:27)

La solution https, je ne suis pas un grand expert, je connais la théorie mais en pratique je n'ai jamais eu à faire "réellement" cet échange de clé. Tu configures ton serveur pour qu'il s'occupe de cela tout seul, l'échange de clés publiques et le reste se fait par un certificat que je genere sur ton serveur.

D'une manière générale, il vaut mieux faire un maximum de ce qui concerne la sécurité de ton application coté serveur. Faire un cryptage sha1 coté client (déjà Javascript va pédaler dans la semoule), ensuite ça indique à un éventuel intrus comment tes mots de passe sont stockés, ce qui peut lui donner une piste de recherche.

Mais si ton appli est destinée à un intranet, je ne suis pas certain que l'https soit nécessaire, on ne peut pas "attraper" tes données au vol depuis l'extérieur.