Partie privée d'un site

Dylav · le 22 avril 2009

Je souhaite protéger par un mot de passe l'accès à la partie privée d'un site. Dans ce but, j'ai imaginé le mécanisme suivant,

au moment opportun, un formulaire demande la saisie d'un mot de passe (que tous les visiteurs agréés connaîtront),
ce mot de passe est immédiatement “chiffré” par un script JavaScript dont l'algorithme est irréversible (mais dont le code ne peut être caché aux internautes),
le résultat obtenu est comparé à une valeur de référence marquée en clair dans le code HTML (donc visible des internautes),
s'il y a égalité, on enchaîne sur une page dont l'URL, construite dynamiquement, contient le fameux mot de passe (pas sa valeur chiffrée),
cette page cible doit être située dans un répertoire au contenu non “listable” et également protégé de l'indexation des robots des moteurs de recherche.

Il est bien entendu toujours possible de “casser” le mot de passe par une recherche systématique robotisée, mais je considère le risque acceptable compte tenu de l'absence totale de valeur marchande des informations protégées.

Je voudrais vous demander s'il existe une [autre] faille dans le raisonnement (ce dont je serais tout penaud) et, si la solution est solide,

comment on protège la liste des fichiers d'un répertoire (je me suis laissé dire qu'il suffisait d'y inclure un fichier “index.html”, mais reste sceptique),
comment on protège ces fichiers des robots d'indexation (présence d'un fichier “robots.txt” dans le répertoire ?).

Pour le fun, voici une page-portail simplifiée à l'extrême,

<html><head>
<title>Test mot de passe</title>
<script type="text/javascript" src="Modepasse.js"></script>
</head>
<body onLoad="document.PswF.PswL.focus()">
<form name="PswF">
<input name="PswL" type="password" value="">
<input type="button" value="OK"
onclick="if(Modepasse(document.PswF.PswL)==89931)
{document.location='psw/' + document.PswF.PswL.value + '.html'}">
</form>
</body></html>

et l'algorithme de chiffrement (bestial mais efficace ?),

<!-- Modepasse.js --- Enchaînement contrôlé par un mot de passe -----------
//
// L'algorithme ci-dessous transforme le mot de passe saisi
// en un nombre de cinq chiffres. Il est irréversible.
// Ce nombre sera ensuite confronté à la valeur de référence.
//
function Modepasse(d) {
 var Tl = ['*','0','1','2','3','4','5','6','7','8','9',
		'A','B','C','D','E','F','G','H','I','J','K','L','M',
		'N','O','P','Q','R','S','T','U','V','W','X','Y','Z',
		'a','b','c','d','e','f','g','h','i','j','k','l','m',
		'n','o','p','q','r','s','t','u','v','w','x','y','z'];
 var lTl = Tl.length;
 var psw  = d.value;
 var pnum = 0;
 if (psw.length>4) {
for (i=0;i<psw.length;i++) {
  k=-1;
  Li=psw.substr(i,1);
  for (j=0;j<lTl;j++) {if (Li == Tl[j]) {k=j;break}};
  if (k<0) {k=lTl};
  pnum += (53*i+97)*(47*k+89);
 }
for (i=0;i<5;i++) {
  pnum *= pnum;
  pnux  = Math.floor(pnum/10000000);
  pnum  = pnum - pnux * 10000000;
  pnum  = Math.floor(pnum/100);
 }
  }
 return pnum;
}
// ---------------------------------------------------------------- End -->

N'en déplaise à KewlCat, je vous remercie par avance pour vos contributions…

KewlCat · le 23 avril 2009

Si le serveur Web est Apache, il est beaucoup plus simple et beaucoup plus sécurisé de protéger l'accès à ta page par un mot de passe en utilisant une règle dans le fichier .htaccess (et là, aucun risque de fournir l'algo et la valeur cible au visiteur).

zebuntu · le 17 décembre 2009

Si le serveur web est yaws, c'est aussi très facile :

Pour chacun des répertoires à protéger :

il faut créer un fichier nommé .yaws_auth (ne pas oublier le point au début) qui contiendra le nom des utilisateurs et leur mot-de-passe,

fichier à placer à la racine de chacun des répertoires à protéger.

Exemple de contenu d'un .yaws_auth :

{"marcel", "astalavista"}.
{"corinne", "barbie"}.

marcel et corinne sont autorisés, via leur mot de passe, et personne d'autre. Quand ils arrivent sur la page protégée, une requête s'ouvre demandant un nom d'utilisateur et un mot-de-passe.

Ne pas oublier de relancer yaws après tout changement d'un de ces fichiers .yaws_auth, par un (en root/admin)

$ yaws --hup

++

PS: pourquoi yaws me direz-vous ? Simple :

Quand j'étais sous Apache, dans mes logs, j'y trouvais en moyenne entre 100 et 300 tentatives d'intrusion (par jour !!!) dans PHPmyAdmin (écrit avec toutes les syntaxes possibles et imaginables), et les IP venaient pratiquement toutes de... l'Italie (tiens !? comme par hasard ) En clair, des mafieux avec un gros parc informatique dédié, passent leur temps à tester et trouver des failles de sécurité dans les sites sous Apache pour espérer y récupérer des données sensibles (liste de clients, n° de C.B., etc...) exploitables.

Depuis que j'ai parlé de ça à mon hébergeur, il a tout viré Apache, installé Yaws à la place... et depuis, dans mes logs, plus rien d'autre que les connexions normales de visiteurs. Et quand un petit malin interroge :

"- Apache ?

- Ha non, ici c'est Yaws

- Haa, flûte. Adios :{"

Voilà. Débarrassé...

"Exit, les pointes sèches !"

Note: Yaws utilise comme langage, par défaut, Erlang et non PHP, mais il peut aussi faire du PHP. Ca marche trop bien. Nickel.

Modifié le 17 décembre 2009 par zebuntu

le 19 décembre 2009

C'est pas parcequ'un message est incompris qu'il faut le supprimer ...

Je persiste et signe:

NEVER TRUST USER

never trust user est vrai ton. Ton code est, en matière de sécurité, totalement nul et non avenu. (et pas qu'en matière de sécurité, le choix de tes variables est affreux, et mathématiquement il est pas joli joli non plus).

Primo, tu donnes toutes les informations à l'utilisateur (longueur minimal du mots de passe, indice sur la page à joindre ect ect)

Secondo, ton algorithme permettant de calculer le hash est irréversible uniquement de pars sa destructivité mais cela implique qu'il y ai une infinité de mots de passe valide (qui seront rejeté lorsqu'on tentera de joindre l'url je l'accorde).

Tierso, Tu ne protège pas une page, tu protèges une URL (si je tape directement la bonne url, on ne demandera aucune identification).

Dans la pratique ca veut dire que tu ne protège rien du tout.

Google dispose de crawler assez sophistiqué, les bruteforce d'url en fond partie.

Pire, si en sortant de ta sois disant page cachée, tu visites google, ta page sera indexée aussi.

bref, ton code est nul et non avenu.

Des implémentations de fonction de hash plus solide qu'une méthode maison sont implémenté en javascript (md5 par exemple), de plus le PHP serait bien plus pratique pour un résultat nettement plus sécuriser. (et protégerai une page et non une url).

Il est inutile de réinventer la roue (même si dans le cas actuelle ca a plutot c'est plutot un pneu crevé)

_Michel_ · le 20 décembre 2009

Salut,

C'est tordu mais j'ai déjà vu des choses comme cela sur le web, sur des sites dits professionnels. Cette façon de faire se justifie que si tu ne peux pas faire autrement. C'est à dire que tu n'as accès à aucun langage de script côté serveur comme php et si tu ne peux pas définir de configuration locale au niveau du serveur web (.htaccess pour apache).

Le listing du répertoire constitue le plus grand problème pour cette méthode de protection. Tu peux en effet placer un fichier index.html (vide ou pas) dans le répertoire psw/ et toute tentative d'accès du genre http://tonsive/psw/ affichera ce fichier et pas le listing du répertoire (qui est le comportement par défaut sous apache). Le nom de ce ou ces fichiers "par défaut" est configurable et peut varier d'un serveur à l'autre, toutefois index.html est la norme en la matière.

Là encore, il existe des directives locales sous apache qui empêchent de lister le contenu du répertoire ("Option -Indexes" dans .htaccess).

La seule faille évidente est si tu mets un lien http vers un site extérieur sur ta page privée. Auquel cas, le moindre clic rapatria ton url secrète vers ce serveur extérieur via la variable d'entête HTTP referer. Ensuite, ce referer peut être utilisé au bon vouloir du site. Par exemple en publiant ses statistiques de fréquentation sur le web, et là tu es mal.

Les robots de type webcrawler ne peuvent pas lister le contenu d'un répertoire si tu le protèges, même avec seulement index.html. Ils ne font que sauter de lien en lien. Si ta page secrète n'est pointée nulle part, elle n'apparaitra jamais. A moins qu'elle ne soit dévoilée, comme je l'ai dit précédemment, à travers les statistiques publiques d'un site web via ses referers et là ta page peut se retrouver sous google.

Il est plus sain d'utiliser les fonctions de sécurité incorporées au serveur web (ton hébergeur doit en parler quelque part) ou utiliser un script côté serveur même bête et basique, genre "if ($pass!="monmotdepasse") die();"

Quoiqu'il en soit, l'audit d'un site ne peut se limiter à quelques fichiers. Il faut tout examiner. Ils se peut qu'une maladresse dans un code ailleurs sur ton site, qui n'avait aucun effet avant, ouvre une porte au niveau de l'accès de ta page secrète.

le 22 décembre 2009

"if ($pass!="monmotdepasse") die();"

Non, il ne faut pas comparer le mots de passe entré avec le mots de passe voulu.

"if (md5($pass)!="hashMD5demonmotdepasse") die();"

_Michel_ · le 23 décembre 2009

"if ($pass!="monmotdepasse") die();"
Non, il ne faut pas comparer le mots de passe entré avec le mots de passe voulu.
"if (md5($pass)!="hashMD5demonmotdepasse") die();"

J'ai toujours aimé les recommandations qui se limitent à "il ne faut pas" ou alternativement à "il faut". Une question de foi sans doute.

J'aurais préféré que tu cites quels sont les problèmes de sécurité associés avec cette façon de faire, c'est à dire de mettre un mot de passe en clair dans un script côté serveur et quels avantages un hash md5 peut apporter. Aussi quelles sont ses faiblesses.

Mais continuons le délire sécuritaire. Si quelqu'un accède au code du script, combien de temps crois-tu qu'il mettrait pour trouver un mot de passe entrant en collision avec ce md5 ? Je te suggère de te reporter ne serait-ce qu'à wikipedia : http://fr.wikipedia.org/wiki/MD5

Et oui, rien n'est parfait en ce bas monde. L'important est de savoir doser la serrure par rapport au contenu.

KewlCat · le 23 décembre 2009

quels sont les problèmes de sécurité associés avec cette façon de faire, c'est à dire de mettre un mot de passe en clair dans un script côté serveur et quels avantages un hash md5 peut apporter

"Un mot de passe qui circule en clair sur le réseau" me semble être une raison suffisante... Et je ne dis pas ça parce que j'ai été témoin d'un "léger" bug chez un hébergeur qui m'aurait permis d'écouter tout le trafic d'un range complet d'IP pendant presque cinq semaines...

D'un autre côté, pour des données qui circulent en clair, le problème devient non plus de deviner le mot de passe mais de deviner la valeur du hash à envoyer au serveur...

Note : MD5 c'est has been. SHA-1 serait déjà mieux :-P

Si quelqu'un accède au code du script, combien de temps crois-tu qu'il mettrait pour trouver un mot de passe entrant en collision avec ce md5 ?

S'il est entré en possession du code du script à mon avis il ne va pas s'amuser à faire une attaque "brute force" sur le hash md5, il a déjà accès à la base de données et à tout ce que cette authentification était censée protéger !!

Pour en revenir à la méthode de "protection" décrite dans le post d'origine, je rappelle qu'il est absurde d'attendre une quelconque sécurité d'un mécanisme qui fournit la description complète de la "serrure" à la vue du Monde...

_Michel_ · le 24 décembre 2009

"Un mot de passe qui circule en clair sur le réseau" me semble être une raison suffisante... Et je ne dis pas ça parce que j'ai été témoin d'un "léger" bug chez un hébergeur qui m'aurait permis d'écouter tout le trafic d'un range complet d'IP pendant presque cinq semaines...
D'un autre côté, pour des données qui circulent en clair, le problème devient non plus de deviner le mot de passe mais de deviner la valeur du hash à envoyer au serveur...

Oui, certes. Toutefois, le mot de passe circule toujours en clair avec le code fourni par hanlon. Il faut encore implémenter un code côté client qui se charge du "hashing" avant de communiquer avec le serveur.

Note : MD5 c'est has been. SHA-1 serait déjà mieux

C'était la réflexion à laquelle je voulais amener. C'est depuis quelques années déjà loin d'être infaillible pour qui est déterminé. Cependant, des choses simples telles que l'ajout d'une "graine" au mot de passe avant calcul du md5 permet de durcir assez le secret pour le rendre en pratique quasi impénétrable.

S'il est entré en possession du code du script à mon avis il ne va pas s'amuser à faire une attaque "brute force" sur le hash md5, il a déjà accès à la base de données et à tout ce que cette authentification était censée protéger !!

Là également, il n'y a aucune base de données dans le code de hanlon. Le md5 se trouve dans le script php. Par ailleurs, il n'est nul besoin de faire un "brute force" sur un md5. Il existe des sites qui recensent des milliers de md5. Si le md5 en question s'y trouve, on accède instantanément au mot de passe. Et si cela ne suffit pas, un peu de recherche permet de trouver assez rapidement une collision avec le md5 recherché (le mot de passe n'est pas le bon mais le md5 généré est le même).

Pour en revenir à la méthode de "protection" décrite dans le post d'origine, je rappelle qu'il est absurde d'attendre une quelconque sécurité d'un mécanisme qui fournit la description complète de la "serrure" à la vue du Monde...

Permet-moi de ne pas être d'accord sur ce point. De très bons algorithmes de cryptages sont publics. Cela apporte l'avantage, comme le source libre, de pouvoir être examiné par des gens talentueux qui mettront à jour les failles du système. Beaucoup de gens doutent de la sécurité par l'obscurité.

Enfin, il ne s'agit pas d'une base de données de numéro de cartes bleues non plus. Comme je le disais, s'il n'a pas le choix, cela fonctionnera je pense.

KewlCat · le 25 décembre 2009

Permet-moi de ne pas être d'accord sur ce point. De très bons algorithmes de cryptages sont publics. Cela apporte l'avantage, comme le source libre, de pouvoir être examiné par des gens talentueux qui mettront à jour les failles du système.

Comme tu le précises, ce sont les algorithmes qui sont publics. Là on a non seulement l'algorithme, mais également son implémentation et toutes les données qui sont utilisées avec...

Quand on utiilise SSH, au hasard, l'algo est peut-être public mais ta clé privée n'est pas pour autant fournie à tout va !

Connexion

Pas encore inscrit ?

Partie privée d'un site

Messages recommandés

Dylav

KewlCat

zebuntu

Invité Invité

_Michel_

Invité hanlon

_Michel_

KewlCat

_Michel_

KewlCat

Rejoindre la conversation

En ligne récemment 0 membre est en ligne

Zebulon

Outils en ligne

Naviguer