Si j'ai bien compris, tu veux vérifier le mdp et rediriger la personne vers une page à l'url "impossible à deviner" s'il est correct. C'est pas la bonne manière de faire. Si tu penses vraiment que ton url peut rester "secret", autant donner l'url comme mdp, pas besoin de te casser la tête avec PHP et ça sera pas moins sécurisé. Ca le sera même plus si la "difficulté" du mdp est moindre que celle de l'url. Si elle l'est plus, c'est le mdp qui sert à rien.
Maintenant si tu veux un "vrai" accés par mdp, tu vas devoir soit tout mettre dans la même page PHP protégée par elle même (affichage de la page uniquement si le mdp est correct, pas moyen de contourner comme c'est le cas dans ton exemple), soit utiliser les sessions et les cookies pour protéger les autres pages (accès que si le cookie est bon et le cookie ne peut être mis que par la page de login, ou un truc comme ça, j'ai jamais touché à ça), soit utiliser une protection au niveau d'Apache comme suggéré plus haut, qui va te permettre de protéger tout le répertoire du même coup.
A mon avis, la solution la plus facile/rapide à mettre en place est celle des htaccess. C'est pas plus compliqué que ta solution, ça l'est même moins: t'as pas à faire de PHP, t'as juste à maintenir un fichiers d'utilisateurs/mdp. Si tu veux tu peux t'amuser à faire une interface PHP pour gérer le fichier. Si tu veux vraiment pas avoir à taper un login mais juste un mdp, alors amuse toi avec les sessions/cookies ou intégre tout dans la même page si c'est possible.
Pour le problème du brute-force. Avec le système actuel, le méchant n'a qu'à brute-forcer un URL ou un mdp, le plus faible des deux. Avec le htaccess, il doit brute-forcer un login+mdp (en admettant que le login reste "secret" aussi). De toute façon toute application de ce genre est "brute-forçable". Si tu penses que ça en vaut la peine, tu as plusieurs solutions pour limiter les risques. Le plus simple est probablement de bien choisir le mdp, après tu peux t'arranger pour qu'on ne puisse pas faire plus de X tentatives de login par heure (mais pas avec des cookies, du JS ou autre truc "client-side", dans ce cas ça sert à rien et ça fait chier les visiteurs) ou commencer à chercher un système d'authentification plus correct (à coups de PGP/SSL/TLS/... par exemples) mais ça devient tout de suite plus lourd. Yavait un article sur l'authentification par mdp dans le Linux Magazine France du mois dernier je pense (si qqun avec le magazine sous la main peut confirmer...). Ca peut peut-être t'intéresser.
Personnellement, j'ai un serveur FTP avec un compte "invité" qui me sert de temps en temps ("hé pq je peux pas t'envoyer de fichiers par MSN?"). Le mdp change aléatoirement toutes les X heures et il est enregistré dans un fichier auquel moi seul ai accés. Avec ça, bonne chance pour le brute-force. Faut voir si ça peut être applicable à ton cas. Dans le même genre, voir http://slashdot.org/comments.pl?sid=111503&cid=9469343(...)
Le mdp est généré par exemple par un md5 de la somme de l'heure actuelle et du "vrai" mdp (une truc plus correct serait genre md5(md5(time).md5(passwd)), le "." pour la concaténation). Comme ça, toute personne qui a le "vrai" mdp peut reconstituer le mdp actuel mais il change toutes les X heures/minutes. Tu peux aussi t'arranger pour que le mdp change après que qqun se soit loggué, comme ça si la connexion est sniffée, l'attaquant ne sait quand même pas obtenir le mdp puisqu'il a déjà changé (mais bon dans ce cas tu as d'autres problèmes).
Par ailleurs je recommande la lecture de cet article-ci à tous ceux qui débutent dans les applications web (et ça peut surement pas faire de mal à ceux qui en font déjà depuis un moment): http://www.linux-mag.com/2002-09/security_01.html(...)
# non
Posté par Krunch (courriel, site web personnel) . En réponse au message pages perso attente pour force brute. Évalué à 3.
Maintenant si tu veux un "vrai" accés par mdp, tu vas devoir soit tout mettre dans la même page PHP protégée par elle même (affichage de la page uniquement si le mdp est correct, pas moyen de contourner comme c'est le cas dans ton exemple), soit utiliser les sessions et les cookies pour protéger les autres pages (accès que si le cookie est bon et le cookie ne peut être mis que par la page de login, ou un truc comme ça, j'ai jamais touché à ça), soit utiliser une protection au niveau d'Apache comme suggéré plus haut, qui va te permettre de protéger tout le répertoire du même coup.
A mon avis, la solution la plus facile/rapide à mettre en place est celle des htaccess. C'est pas plus compliqué que ta solution, ça l'est même moins: t'as pas à faire de PHP, t'as juste à maintenir un fichiers d'utilisateurs/mdp. Si tu veux tu peux t'amuser à faire une interface PHP pour gérer le fichier. Si tu veux vraiment pas avoir à taper un login mais juste un mdp, alors amuse toi avec les sessions/cookies ou intégre tout dans la même page si c'est possible.
Pour le problème du brute-force. Avec le système actuel, le méchant n'a qu'à brute-forcer un URL ou un mdp, le plus faible des deux. Avec le htaccess, il doit brute-forcer un login+mdp (en admettant que le login reste "secret" aussi). De toute façon toute application de ce genre est "brute-forçable". Si tu penses que ça en vaut la peine, tu as plusieurs solutions pour limiter les risques. Le plus simple est probablement de bien choisir le mdp, après tu peux t'arranger pour qu'on ne puisse pas faire plus de X tentatives de login par heure (mais pas avec des cookies, du JS ou autre truc "client-side", dans ce cas ça sert à rien et ça fait chier les visiteurs) ou commencer à chercher un système d'authentification plus correct (à coups de PGP/SSL/TLS/... par exemples) mais ça devient tout de suite plus lourd. Yavait un article sur l'authentification par mdp dans le Linux Magazine France du mois dernier je pense (si qqun avec le magazine sous la main peut confirmer...). Ca peut peut-être t'intéresser.
Personnellement, j'ai un serveur FTP avec un compte "invité" qui me sert de temps en temps ("hé pq je peux pas t'envoyer de fichiers par MSN?"). Le mdp change aléatoirement toutes les X heures et il est enregistré dans un fichier auquel moi seul ai accés. Avec ça, bonne chance pour le brute-force. Faut voir si ça peut être applicable à ton cas. Dans le même genre, voir http://slashdot.org/comments.pl?sid=111503&cid=9469343(...)
Le mdp est généré par exemple par un md5 de la somme de l'heure actuelle et du "vrai" mdp (une truc plus correct serait genre md5(md5(time).md5(passwd)), le "." pour la concaténation). Comme ça, toute personne qui a le "vrai" mdp peut reconstituer le mdp actuel mais il change toutes les X heures/minutes. Tu peux aussi t'arranger pour que le mdp change après que qqun se soit loggué, comme ça si la connexion est sniffée, l'attaquant ne sait quand même pas obtenir le mdp puisqu'il a déjà changé (mais bon dans ce cas tu as d'autres problèmes).
Par ailleurs je recommande la lecture de cet article-ci à tous ceux qui débutent dans les applications web (et ça peut surement pas faire de mal à ceux qui en font déjà depuis un moment): http://www.linux-mag.com/2002-09/security_01.html(...)
Pour le coup des md5, vaut mieux comprendre ce qu'on fait avant de l'implémenter. Voir par exemple dans le même magazine: http://www.linux-mag.com/2002-09/cryptography_01.html(...)
-- Krunch le parano
PS: désolé pour les anglicismes et fautes d'orthographes/grammaire mais il est 3h30 passé là
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.