Bonjour

j'utilise actuellement un système de protection de site web avec une architecture pareil :

un dossier contenant un .htaccess contenant les mot de passe et login ds un fichier texte,ainsi que 2 fichier à inclure dés que l'utilisateur est identifier
fichier de démarrage de session

<?php
session_start();
$_SESSION['login'] = $login
?>

et l'autre pour verifier que l'utilisateur est identifier

<?php
session_start();
if (!isset($_SESSION['login']))
{header("Location: protect.php");}
?>

la page qui valide les mot de passe se présente comme suit

include ("fichier contenant les mot de passe et les login");
if ($_POST[Submit] != "Entrer")
{affiche();}
else
{
	$login = $_POST[login];
	$pass = $_POST[pass];
	foreach ($tableau de login&motdepasse as $log => $pas)
	{
		if ($login == $log and $pass == $pas)
		{$ok = "ok";}
	}
	if ($ok == "ok")
	{
		include ("fichier de démarrage de session");
		header("Location: Page1.php?login=$login");
	}
	else {echo "erreur";}
}

Le début de chaque page protégée commence par

<?php
include ("fichier de vérification d' ID");
?>

Une page supplémentaire détruit la session et un lien vers cette page est toujours disponnible

<?php
session_start();
session_destroy ();
header("Location: ../index.php");
?>

La sécurité du site ne dois pas être à tout épreuve mais pas non plus accessible au 1er quidam.

Merci de votre attention et de votre potentiel réponse

C'est tout-à-fait le type d'architecture que j'utilise. Quand tu le peux, place les fichiers à inclure dans un dossier NON PUBLIE par le serveur web (au-dessus de la racine par exemple), c'est plus efficace que le .htaccess dans l'absolu.

Mais là tu as fait à peu près tout ce que le développeur peut faire pour sécuriser une identification. Il faut cependant faire très attention au SQL-Injection et autres attaques basées sur la maladresse du webmaster : surveille tes formulaires

Après c'est la casquette d'administrateur réseau qu'il te faut endosser et :
- vérifier les trous de sécurité connus et les différentes versions des logiciels touchés.
- faire des mises à jour en fonction, et/ou appliquer des patch. Et s'il n'en existe pas : changer de logiciel.

Merci beaucoup

Je vais mèditer sur tes conseils.

Mais n'est 'il pas trop ennuyant de ne pas avoir un cryptage sur les mots de passe??

Spols

si, dans l'ideal il faudrait que tu utilise une fonction de hashage (MD5 ou SHA-1 ) pour 2 raisons :
- si un type met la main sur ta base, il ne faut pas qu'il puisse connaitre les mots de passe pour autant.
- par discretion : tu n'est pas cense connaitre les mots de passe de tes membres.

ces 2 raisons decoulant du fait que les gens reutilisent souvent le meme mot de passe. donc meme si le vol d'un mot de passe d'un de tes membres n'etait pas grave dans le cas de ton site, cela pourrait l'etre par aiileurs.

les mots de passe sont donnée par le webmaster et ne peuvent être changer pour des raison qui reste confidentielle par contre pour un cryptage quelqu'un aurait il un lien pour apprendre à les utiliser ??

Spols

PHP intègre des fonctions qui utilisent les algorithmes de cryptage cités plus haut, cfr la doc pour leur utilisation

md5()
sha1()

note les différents commentaires sur ces fonctions, conseils d'amélioration de ces cryptages

Un tuto sur le chiffrement de données peut-être ?

sans vouloir relancer le debat, je maintiens qu'il est plus simple, plus sur et plus rapide ( et plus déontologique ) de hacher ses mots de passe plutot que de les crypter..

- plus simple a mettre en oeuvre, ca me semble evident
- plus rapide aussi, c'est lie a la nature meme des algo
- plus sur : des l'instant qu'une cle existe qui permet de decrypte les mots de passe, cela cree une faille potentiel si le pirate s'empare de cette cle. meme si le risque est minime, c'est un risque qui n'apporte rien, donc mieux vaut ne pas le prendre
- et du point de vue deontologique, je n'aimerais pas qu'un webmaster puisse lire mon mot de passe...

@Spols : le principe est simple : tu stockes dans ton tableau les versions hachées de tes mots de passe. lorsque quelqu'un essaie de se connecter, tu hache ce qu'il a tapé et tu compare avec ce qu'il y a dans le tableau.

Merci beaucoup

Je vais réfléchir la dessus et déterminer mes besoins

Spols

sans vouloir relancer le debat, je maintiens qu'il est plus simple, plus sur et plus rapide ( et plus déontologique ) de hacher ses mots de passe plutot que de les crypter..

Il n'y a pas de débat. Ce sont deux outils qui ont des finalités différentes.

Le cryptage de mots de passe a son utilité quand on souhaite les reconstituer en cas d'oubli.

Si la reconstitution de mdp n'est pas nécessaire, mieux vaut hacher.

- plus simple a mettre en oeuvre, ca me semble evident

J'utilise deux petites fonctions perso monCrypt() et monDecrypt() ou bien les fonctions natives de MySQL AES_ENCRYPT() et AES_DECRYPT(), toutes aussi faciles à utiliser que md5().

- plus rapide aussi, c'est lie a la nature meme des algo

Exact. md5() sha1() sont environ 50 fois plus rapides.

- plus sur : des l'instant qu'une cle existe qui permet de decrypte les mots de passe, cela cree une faille potentiel si le pirate s'empare de cette cle. meme si le risque est minime, c'est un risque qui n'apporte rien, donc mieux vaut ne pas le prendre

La clé doit être stockée de manière intelligente. Hors document_root. Ou en bdd. Et il n'y a pas que la clé. Il y a l'algo, le mode de chiffrement et le vecteur d'initialisation qui peuvent également être stockés de manière sécurisée. Si un pirate trouve tout ça dans ces conditions, le serveur est brûlé de toutes les façons.

- et du point de vue deontologique, je n'aimerais pas qu'un webmaster puisse lire mon mot de passe...

+1 même si, à ce sujet, je ne me fais pas trop d'illusions

a clé doit être stockée de manière intelligente. Hors document_root. Ou en bdd. Et il n'y a pas que la clé. Il y a l'algo, le mode de chiffrement et le vecteur d'initialisation qui peuvent également être stockés de manière sécurisée. Si un pirate trouve tout ça dans ces conditions, le serveur est brûlé de toutes les façons.

je suis d'accord, mais une regle d'or en cryptographie est : si telle fonction est inutile, ne pas la prevoir, c'est un risque de moins. pour recouvrer le mot de passe, il est toujours possible d'en generer un nouveau et de permettre a l'utilisateur de lechanger. le decryptage du mot de passe n'est donc pas necessaire. donc, meme s'il y a des manieres de bien faire, ne pas utiliser de cryptage symetrique donne un risque 0 de ce cote la. l'existence d'une cle, aussi bien planquee soit elle, est un danger potentiel et inutile. et je te ferais remarquer que si la cle est stockee en BDD et que le pirate y accede, il pourra lire les mdp. ce qui n'est pas le cas s'ils sont hache. avec le hachage, quelque soit le degre de "penetration" du pirate, il ne pourra jamais lire directement les mots de passe ( je dis bien directement, cad sans utiliser de brute force ). meme si effectivement dans ce cas le site est grille, au moins tu pourras restaurer une sauvegarde et permettre aux utilisateur de conserver leurs mots de passe, puisque il n'auront pas ete lu, et tu evite que le pirate aille lire leur courrier, ou modifier leur porpre site, par exemple. je suis desole d'etre aussi categorique, mais je pense ( ce n'est que mon avis ) qu'il n'y a absolument aucune situation qui justifie un cryptage symetrique du mdp.