Bonsoir,

Tout le monde parle de sécurité. A ce jour on peut dire qu'il n'y-a pas de méthode(s) infaillible(s).
Si on utilise la méthode des sessions, elle est efficace que si le MP est crypté entre le navigateur et le serveur, mais comment faire si on ne doit pas utiliser de logiciel(s) coté client (JS ou autre) ?
Elle doit obligatoirement sortir en clair du navigateur, un coup de « sniff » et hop!, c'est fini.

Dans cette optique seule une connexion sécurisée (https) est à ce jour envisageable, quoi que...
Et ça implique deux serveurs (un en http et un en https). Je m'explique: Le serveur https est très gourmand, il n'est à envisager que pour les pages contenant des données sensibles (MP, Nº de compte, ....) car sinon le client qui choisi des articles dans le catalogue du site (il navigue) le temps de réponse le fera vite grincer des dents (Je vous parle même pas d'une connexion RTC).

Si on pousse la paranoïa jusqu'au bout, on doit prévoir les logiciels mal vaillants qui lisent les touches au clavier et transmettent leur récolte. Dans ce cas, un clavier virtuel avec un positionnement aléatoire des touches et l'usage de la sourie ?, Mais j'oubliais, pas logiciel coté client !

Pour les partisans de la politique du double usage (client et serveur), on peut considérer qu'ils se complémentent.

Les utilisateurs sont eux, aussi sensibles, sinon plus que nous, de cette sécurité, mais souvant mal informés. Si un utilisateur, parano (comme le fait remarquer Cyrano), bloque son JS, on le redirige vers une page lui expliquant les risques qu'il encourt, et pourquoi il doit activer le JS pour le site concerné il changera d'avis.

Donc il faut faire de son mieux et avec les moyens qui sont les nôtres.

Concernant la détection de JS coté client, la ou une des meilleurs méthodes est celle indiquée par Cyrano mais plus complexe à mettre en place.

HTML prévoie une balise <noscript> qui s'exécute que si le script ne s'est pas exécuté, un Exp.

• Cyrano: Merci pour l'astuce de detection de js.
  Je vais me renseigner mais en 2 mots, AJAX c'est un langage ? C'est quoi son utilité?

• Zeuf:Quels pourris ces Lycos, halucinant... ça confirme le merite de free de tjrs tirer les pris vers le bas, et de ne pas faire chier pour les sites.
  Merci pour les infos.

• Ajoloca: bon je ne vais pas me mettre tout de suite à HTTPS donc allons-y pour js, après ta confirmation je n'hesite plus.
  Pourquoi les js ne sont pas tjrs activés par défaut? parce que ça represente un risq de virus ou parce que leurs navigateurs sont vieux?
  Je demande ça parce que si je leur dis qu'ils ont interet a activer js, il faut etre sur que le risque de virus q cela peut apporter est negligeable par rapport a la securite pour les mdpasses.
  Merci pour cette definition poussée de la securité.

C cool cet internet, autant y'a des gens qui en profittent pour se défouller et insulter tout le monde puisqu'on ne les voit pas, autant y'a des altruistes comme vous qui aident sans interret perso... et c'est tres bo !!!
Merci encore.

Bonsoir,
Je ne pense pas que ce soit une question de vétusté des navigateurs, mais une peur, comme on la vu fondée (pas de protection miracle). La plus part des navigatuers actuels permettent d'activer JS que pour un site, une période, etc, d'autres préviennent qu'ils on bloqué le script et proposent de l'activer que pour ce site, cette page...

Le principe de l'information est de leur dire que les virus, et autres logiciels malveillants ne viennet pas de sites dignes de ce nom, et que même leur meilleur ami en envoyant une photo de vacances peut les contaminer.
Et aussi, et surtout, que ce sont leurs données personnelles qui sont en jeu. Si le mot de passe est crypté sur leur machine (grace à JS) les chances quil soit interprété par d'autres que vous-même, sont quasiment nulels, quite à désactiver JS une fois qu'il a quité le site.

Lui expliquer le principe (utilisation de méthodes de chiffrement avec deux clés, une publique et une privée, etc, ...) sans donner les détails mais qu'ils se sentent impliqués (on ne les prend pas pour des idiots)

AJAX est une technologie qui permet de passer de requêtes (pas dans le sens SQL) au serveur à partir du poste client, les récupérer et d'actualiser la page sans la réafficher. Ça demande l'utilisation de JS sur le poste client.

Merci, c'est rapide et vraiment parfait

Petite precision:
Si l'utilisateur oublie son mot de passe, il faut donc q je le connaisse pour pouvoir lui renvoyer.
Il faut donc que je l'enregistre non crypté avant de cryptage (sur une table temporaire avant de le mettre hors du reseau) ou y'a moyen de decrypter le mdp crypté ?

Bonjour,

Une donnée cryptée, peut être décryptée, donc retrouver l'originale. Avec une donnée chiffrée il n'existe acun moyen de revenir en arrière. Pour des chiffrements "maison" très simples c'est possible mais avec du temps, beaucoup de temps, encore du temps et pas mal de chance. Avec des shiffrements plus poussés c'est même pas la peine d'essayer.

Un mot de passe, par définition, est secrét. Seul l'utilisateur doit le connaître.
S'il l'oublie, tu lui envoie un temporaire (généré au hasard) qu'il pourra ensuite changer à sa guise.

Je suis parti pour utiliser la fonction MD5, je suppose que ça chiffre les données (ou ça les crypte?).
Merci pour la methode, je ne vais donc pas faire un chiffrage maison, vive les mdp temporaires.

Re,
md5, sha1, crc32, etc sont des méthodes de chiffrement.

Si tu disposes de sha1 sous JS je te conseille de l'utiliser, elle est plus sure.

D'ac , tjrs merci.

Salut !

J'ai oublié une étape entre la 1 et la 2.

Il faut éviter de faire transiter sur le réseau le mot de passe en clair (il faut aussi éviter de mettre le mot de passe en clair dans ta base de données- BD).

Etape 1 bis (et pour faire simple)
L'UNE des solutions est de stocker dans ta BD le mot de passe crypté (par MD5) par exemple. Dans ton formulaire HTML, lorsque tu demandes le login et le mot de passe, à l'aide d'une routine en JAVASCRIPT (donc côté client, cela ne transite pas sur le réseau), tu codes le mot de passe en MD5 (Javascript sait le faire) et tu compares le codage MD5 du mot de passe saisi par l'utilisateur avec celui qu'il y a dans ta BD. Ainsi même si l'information est "saisie au vol", le mot de passe, lui, ne l'est pas.

Voilà. Pour un complément d'info : http://actuel.fr.selfhtml.org/articles/ ... /index.htm

A +

Zeuf

Bonjour,

@zeuf
Avec ta méthode tu ne changes rien au PB, quelle est la difference de 'capter' le mot de passe ou de capter son chiffrement, si comme dans ton cas, le chiddrement donne toujours le même résultat qui en plus est comparé toujours à la même valeur?

Le but est d'utiliser des clés, plusieurs techniques existent, mais la plus souvant utilisée c'est 2 clés, une plublique et une privée.

La première fournie par le serveur et la seconde par le client(JS).

Salut Aj !!

Oui la méthode des clés, c'est ce qu'utilise HTTP+SSL (HTTPS) (OVH et Cybergraphik en propose pour pas cher cependant).

Et bien avec le chiffrement seulement, il ne peut pas récupérer le mot de passe (enfin au prix de quel effort). Car on utilise toujours (ou presque) les mêmes mots de passe. C'est toujours mieux que rien je pense. Et puis cela ne demande pas beaucoup de temps et de savoir à mettre en place.

Mais honnêtement je pense que si on a un mec suffisamment balèze pour récupérer le chiffrement d'un mot de passe (où toute information qui transite sur le net), puis de s'en servir pour se connecter au compte d'un utilisateur sur le dos de notre site, on est mort !

Et puis je préfère dire à mes clients : votre mot de passe circule en crypté sur le net, plutôt que : votre mot de passe circule en clair... Mais de toute façon, je vais utiliser HTTPS... Le temps de me renseigner !

Hé, tu dors jamais toi !!

A +

Zeuf