Authentification "Sécurisée" via PHP/MySQL et JS
Je viens de mettre en oeuvre une méthode d'authentification "sécurisée" entre un navigateur et le serveur afin d'authentifier les utilisateurs sans pour autant faire passer le mot de passe en clair sur le réseau.
Une première version de mes scripts d'authentifications cryptais en MD5 le mot de passe de l'utilisateur avant de l'envoyer. Le serveur ne stockant que les mots de passes en MD5 la sécurité était correcte. Aujourd'hui il est cependant très facile de trouver la provenance d'un Hash MD5. Pour vous faire une idée, codez un hash simple en md5 (ex: 5EB63BBBE01EEED093CB22BB8F5ACDC3) et donnez-le à ce site : http://passcracking.com/ vous serez surpris du résultat.
Il fallait donc trouver autre chose. Après avoir parcouru un bouquin sur la mise en œuvre du WIFI, j'ai trouvé que la méthode de cryptage par clé WEP était plutôt appropriée à notre cas. Certes il est facile de retrouver une clé WEP en WIFI... Mais si vous ne pouvez pas écouter le réseau avouez que c'est déjà plus contraignant. Après quelques recherches il s'avère que Google utilise cette méthode d'authentification au dessus de SSL.
Voici le process :
En cas d'attaque de type MIM le pirate verra passer le challenge dans le sens serveur-client puis la réponse au challenge dans le sens client-serveur il lui faudra cependant un très grand nombre d'authentification par le même utilisateur pour arriver à déterminer le cryptage utilisé pour le challenge. Si en WIFI il est très facile d'avoir rapidement des millers de paquets cryptés avec la même clé, ici il ne se produira qu'une authentification toutes les 1/2h au maximum !
D'ailleurs si vous ajoutez un cryptage SSH au tout la sécurité deviens alors très forte.
Dans un prochain billet je reviendrais sur les méthodes que j'utilise en plus de celles-ci pour sécuriser les pages sans utiliser SSL.
Note : SSL deviens évidement impératif en cas de données très sensibles.
Une première version de mes scripts d'authentifications cryptais en MD5 le mot de passe de l'utilisateur avant de l'envoyer. Le serveur ne stockant que les mots de passes en MD5 la sécurité était correcte. Aujourd'hui il est cependant très facile de trouver la provenance d'un Hash MD5. Pour vous faire une idée, codez un hash simple en md5 (ex: 5EB63BBBE01EEED093CB22BB8F5ACDC3) et donnez-le à ce site : http://passcracking.com/ vous serez surpris du résultat.
Il fallait donc trouver autre chose. Après avoir parcouru un bouquin sur la mise en œuvre du WIFI, j'ai trouvé que la méthode de cryptage par clé WEP était plutôt appropriée à notre cas. Certes il est facile de retrouver une clé WEP en WIFI... Mais si vous ne pouvez pas écouter le réseau avouez que c'est déjà plus contraignant. Après quelques recherches il s'avère que Google utilise cette méthode d'authentification au dessus de SSL.
Voici le process :
- Le serveur génére une chaine de caractères purement aléatoire (un caractère n'étant utilisée qu'une seule fois) appellé "Challenge".
- Il l'envoie au client (via un champ HIDDEN dans une page par exemple).
- L'utilisateur saisi son mot de passe "en clair" dans un champ "password" puis valide le formulaire
- Sur l'évenement "onsubmit" du formulaire, le mot de passe est alors passé une première fois en MD5 (ceci deviens alors l'équivalent d'une clé WEP forte sur 32 caractères).
- Le challenge envoyé par le serveur est alors ajouté au premier hash MD5 obtenu grâce au mot de passe le tout est ensuite rehashé en MD5. On obtiens donc un hash MD5 qui sera unique pour cette authentification.
- Ce hash final est envoyé au serveur qui possède les hash MD5 des mots de passe en base de données. Il appelle le hash de l'utilisateur, ajoute le challenge et recrypte le tout en MD5. Il ne reste plus qu'a regarder si le résultat obtenu par le serveur est identique à celui fourni par le client. Si c'est le cas alors le client connaissait le mot de passe.
En cas d'attaque de type MIM le pirate verra passer le challenge dans le sens serveur-client puis la réponse au challenge dans le sens client-serveur il lui faudra cependant un très grand nombre d'authentification par le même utilisateur pour arriver à déterminer le cryptage utilisé pour le challenge. Si en WIFI il est très facile d'avoir rapidement des millers de paquets cryptés avec la même clé, ici il ne se produira qu'une authentification toutes les 1/2h au maximum !
D'ailleurs si vous ajoutez un cryptage SSH au tout la sécurité deviens alors très forte.
Dans un prochain billet je reviendrais sur les méthodes que j'utilise en plus de celles-ci pour sécuriser les pages sans utiliser SSL.
Note : SSL deviens évidement impératif en cas de données très sensibles.
Commentaires
Enregistrer un commentaire