Bonjour tout le monde,
 
Voila ma situation :
J'ai un formulaire d'authentification basique en HTML sur lequel, avant l'envoi, je remplace la valeur du champ mot de passe par ce même mot de passe chiffré à l'aide d'une fonction js qui va bien.
En gros, je fais ca avec du sha1.
 
Malheureusement, mon navigateur déclenche l'enregistrement des identifiants / mot de passe et utilise celui que je viens juste de chiffrer...
Donc au retour sur la page, l'utilisateur essaiera de se logger avec un mot de passe déjà chiffré, et mon script va essayer de le rechiffrer, et personne va comprendre se qui se passe (et fail de l'authentification bien sur).
 
 
J'aimerais savoir dans un premier temps si quelqu'un a déjà été confronté au problème, j'ai pas de grands espoirs mais ça m’étonnerai qu'on utilise uniquement le SSL pour sécuriser les formulaires ?
Parce que la concrètement tout transite en clair jusqu'au serveur avant d’être chiffré, et c'est bien sale !
 
J'aimerais garder la possibilité d'enregistrer les informations donc l'autocomplete="off", qui sert a désactiver l'enregistrement des infos par le navigateur, n'est pas une solution valable dans mon cas.
J'ai cherché au niveau de cet enregistrement automatique s'il y a des possibilités de modification du comportement mais rien, ça se déclenche juste quand on a identifiant + password + submit.
 
Je vois vraiment pas vers quoi m'orienter...
 
Merci d'avance pour les réactions et toutes pistes de recherche !

Bonjour a toi,
 
Quel est l'intérêt en termes de sécurité d'une telle pratique ?
 
Que le mot de passe passe en clair ou en forme hashée sur ton formulaire non SSL, il suffit à l'attaquant de rejouer ce qui est passé pour pouvoir se loguer.
 
Je ne vois pas la valeur ajoutée par rapport au fait de conserver le mot de passe en clair dans ton formulaire.

Tu veux dire qu'il suffit de faire une capture des paquets pendant l'authentification d'une personne, de modifier l’entête, de renvoyer les paquets et c'est gagné ?
Si c'est ça tu as raison, j'y avait pas pensé avant... La seule valeur ajoutée est que l'intrus ne connaîtra pas le mot de passe. Vu le nombre de personne qui utilise le même mot de passe partout, il ne pourra pas accéder a d'autres comptes

Comme dit, il n'y a aucune valeur ajoutée, mais ta solution se trouve surement du côté de l'ajax.

Particulièrement simple:
 
Dans ta fonction JS, avant de crypter, test si le mot de passe soumis fait 32 charactères + [a-fA-Z0-9] (donc c'est un hash MD5):
 

 
Voila.

Génial ! J'avais pensé a faire un test de ce genre, mais je savais pas sur quoi me baser comme critère...
c'est du sha1 mais c'est pareil
 
Par contre je maintient qu'il y a une petite valeur ajoutée, comme expliqué dans mon précédent message l'intrus connaitra le hash, pas le mot de passe. Si il connait le passe, il va direct tester sur la boite mail de Mme Michu si elle utilise le même, alors que le hash il mettra un peu de temps a le casser (10 minute vu que Mme Michu utilise 12345, mais quand même !)
 
Merci beaucoup Devil, merci tout le monde !

Oui et non, tel quel il va utiliser une rainbow table et rapidement remonter au résultat initial.
 
Si tu veux faire ça, la clef, c'est la LENTEUR.
 
Le problème c'est que SHA1, c'est l'inverse (très rapide).
 
Pour alourdir l'algo, habituellement ya trois pistes (que l'on utilise conjointement):
  - rajouter un salt, mais les puristes te diront que ce n'est pas suffisant.
  - passer plusieurs passes (10 passes c'est déjà pas mal), là la rainbow table devient quasi inutilisable, et l'algo 10x plus lent.
  - changer d'algo (en gardant les 10 passes hein ), genre BCrypt te donnera une sécurité plus forte (car il est plus lent).
 
En gros:
 

 
Ça alourdi le traitement (10x donc), ça rend un passe type "12345" quasi inutilisable en rainbow table.
 
Encore une fois, ca dépend du niveau de sécu que tu es prêt à faire. Mais n'oublie jamais que le temps perdu pour un utilisateur à multi-passer ton algo, c'est autant de temps perdu pour un hacker en face pour remonter au mot initial.
 
 
Donc, ce genre de truc:
https://code.google.com/p/javascript-bcrypt/
Couplé à une boucle
 
Peut être un bon point de départ, mais fait attention à un point important: les nombres aléatoires en JS c'est pas ça, donc les algos de sécurité (souvent basés dessus), restent plus fragile que dans d'autres languages s'ils n'ont pas implémentés de vrais générateurs de nb aléatoires (j'ai pas regardé le code de cette bibli).
=> entre nous soit dit, si déjà tu mets 10 passes de SHA1 avec un salt, tu es au dessus de 90% des sites existant sur cette planète.
 
 
EDIT: et ccp6128 a raison, si le hacker arrive à avoir le mot de passe haché, il peut envoyer tel quel ca passera. Le seul avantage est qu'il aura du mal/ne pourra pas, connaitre le passe initial. Mais il pourra quand même se logger au compte de l'utilisateur.

Wow,
 
J'ai eu des cours en crypto et lu un bouquin, mais je me rappelle pas avoir entendu parler de rainbow table, je pensais ca prendrait un peu plus de temps pour casser un passe quand même.
Merci beaucoup pour les détails et les pistes, ça va m’être très utile pour savoir concrètement vers quoi je dois m'orienter pour avoir une sécurisation décente. J'ai de quoi me documenter !
Je crois que j'ai deja entendu parler de Bcrypt, je vais regarder un peu ce qui existe. Le salage est très intéressant, je vais vite appliquer ça !
 
merci encore

La mise en place de SSL t'éviterait quand même de devoir mettre une solution un peu "bancale" (dans le sens ou tu fais beaucoup d'efforts qui ne vont pas sécuriser ton site, mais juste protéger un peu le mdp sur des sites tiers).
 
Si tu ne peux pas ou que tu fais ca pour le fun, alors mets carrément en place une solution basée sur du challenge dérivée de l'authent HTTP (DIGEST : https://www.ietf.org/rfc/rfc2617.txt ).

D'après ce qu'il mettait c'était déjà le cas non le SSL ? Il voulait une étape en plus si j'ai bien compris...

Je n'avais pas compris ca, puisqu'il explique que tout transite en clair vers le serveur dans son premier post.
 
Ou alors il n'a pas saisi que le SSL crypte les communications entre le serveur et le client de façon bidirectionnelle ?
 
Autre possibilité, il veut se protéger contre les attaques MITM.
 
Dans tous les cas, crypter côté client ne sert a rien si un attaquant peut renvoyer les données d'authent telles quelles, il faut passer par du challenge.

Non, j'ai bien compris le fonctionnement du ssl, c'est juste que je vais être emmené a coder des systèmes d'authentification sans couche SSL.
Je prend aussi tes infos ccp6128, j'ai tres peu entendu parler de ça, faut que je mate

Exact pour le SSL méa culpa, donc oui avant ca faut mettre en place SSL
 

Je note, ssl à utiliser en priorité