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 ! :D :D :D

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

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 !

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 : [url]http://actuel.fr.selfhtml.org/articles/javascript/md5/index.htm[/url]

A +

Zeuf

D'ac , tjrs merci.

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.

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.

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.

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é ?

Merci, c'est rapide et vraiment parfait :)

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.

[list]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é?[/list]
[list]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.[/list]
[list]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é.[/list]
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,

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.
[code]
<script type="text/JavaScript"><!--
// Code en JS
--></script>
<noscript>
<!-- Redirection vers une autre page -->
<?php header("Location: page explications ou autre"); ?>
<!-- Rien n'epèche d'écrire du code (X)HTML aussi -->
</noscript>
[/code]

Salut !

Ce n'est pas que le lien que j'ai mis ne marche pas, c'est qu'il ne marche plus et pour en connaître la raison --> [url]http://www.phpfrance.com/forums/viewtopic.php?t=23199[/url]

Pour la documentation, elle est disponible ici maintenant : [url]http://www.aidadompc.info/docs/[/url].

Pour le contrôle d'accès à ton site, commence par utiliser la variable $_SESSION au début (PHP 5). Elle est super simple à comprendre et à utiliser

Exemple (et en gros) :

1 - Tu récupères les logins de l'utilisateur (Identifiant et mot de passe par exemple) depuis un formulaire HTML grâce à $_POST.

2 - Tu contrôles que les logins existent dans la Base MySQL ou autre (Il faut qu'au préalable il existe dans ta base ces logins. A toi de voir comment tu veux lui fournir son identifiant et son mot de passe). Si oui, tu autorises l'accès au site grâce à $_SESSION

3 - Tu fais un contrôle sur chaque page de ton site nécessitant l'accès par login (Si $_SESSION contient les logins, tu peux voir la page, sinon tu ne peux pas).

Voilà. Allez au boulot !

A +

Zeuf

PS : cela reste de la sécurité élementaire, donc simple. Si tu veux du costaud tu peux passer par SSL ([url]http://www.commentcamarche.net/crypto/ssl.php3[/url]). Mais alors si la doc PHP te semble difficile d'accès, bonne chance pour le SSL !

Stresse pas trop avec ça, mais garde toujours une chose à l'esprit : une règle primordiale en développement web est de ne jamais faire confiance à l'utilisateur : tu ne peux donc pas baser ton application sur des langages clients, entends par là des langages exécutés sur la machine de l'internaute : ça inclut bien entendu le JavaScript. Ça veut donc dire par exemple que si tu fais une validation de formulaire en javaScript, ça ne te dispense pas de développer une validation en PHP coté serveur. Je dirais même qu'il faut impérativement développer la validation en PHP AVANT la validation en JavaScript parce que sinon, ton JavaScript validant les données, tu ne pourras jamais tester celle en PHP.

Pour tester si le JavaScript est supporté, je ne sais pas trop. Mais l'astuce qui me vient à l'esprit, ce serait un petit bout d'AJAX : tu crée un petit script qui va par exemple initialiser une variable de session $_SESSION['jsActif'] à 1 si c'est ok mais dont la valeur par défaut sera à 0. Coté client, tu crée un appel de fonction JavaScript qui via un objet XMLHTTPRequest va appeler ton script PHP : si ça marche, ta variable vaudra 1 et ça voudra dire que le JavaScript fonctionne, sinon ben ta variable restera à 0 et tu en seras pour tes frais ;)

Mais bon, c'est une astuce imaginée à l'arrache, il existe peut-être plus simple (plus fiable j'ai des doutes, mais plus simple).

Je pensais aussi que tout le monde activait les js et puis la 1ere personne chez qui j'ai testé mon site ne supportait pas les js, du coup ça m'a bien refroidi et j'ai remplacé tous mes js par des codes php... et du coup c'est moi que ça a rendu parano et qui n'ose plus en faire.
:cry:
Tu sais si y'a moyen de detecter si js est accepté par le user pour lui dire d'activer l'option en cas de non affichage du formulaire ?