Sécurité d'un site web : htaccess ou base de données [Résolu]

[PoichOU]

Salut à tous,

une petite question toute simple : Comment bien gérer la sécurité sur un site web ?

Par exemple pour accéder à la partie administration du site, mieux vaut-il utiliser un htaccess ou stocker un login et un mot de passe en base de données ?

merci

PoichOU

[blueice]

Tout dépend de ton besoin et du niveau de sécurité que tu recherches.

[PoichOU]

Je ne sais pas trop ce que je recherche, je dirai le meilleur niveau de sécurité possible.

Si je fais un site e-commerce tu me conseil quoi et pourquoi ? est-ce différent je fais un site pour mon association de tennis de table ?

[tugal]

Cela depend de ce que tu recherche :

Un seul admin ( ou plusieurs admin sans dictinction de droits ) : htaccess

Plusieurs admin avec differents niveau de droit : Base de Donnée

C'est mon avis, bonne chance

[_Mac_]

Tugal : c'est plus complexe que ça. La question n'est pas de savoir combien y a d'admin et quels sont leurs droits mais plutôt de savoir comment tu veux gérer les utilisateurs et quels sont les process associés à cette gestion. Et ce d'autant plus que .htaccess et base de données ne sont pas contradictoires : tu peux utiliser une base de données pour faire de l'authentification basique par .htaccess et de même, tu peux utiliser des fichiers plats (i.e. pas de base de données) pour gérer des utilisateurs de manière plus évoluée qu'un simple fichier de mot de passe. Bref, tout un programme.

On va déjà commencer par dégager 2 modes d'implémentation : authentification par fichier .htaccess (authentification gérée par Apache) et authentification gérée au niveau script (j'entends par là qu'on n'utilise pas de .htaccess et que c'est donc "aux pages" (ou au scripts) ou à l'application de vérifier l'authentification).

Sur la question du "qu'est-ce qui est le plus sécurisé entre le .htaccess et la base de données", la réponse est "ce n'est pas la bonne question". Déjà parce que, comme je le disais, les 2 ne sont pas contradictoires. Les termes de la question ne sont pas bons. Tu peux obtenir le même niveau de sécurité avec un fichier plat ou une base de données, un fichier .htaccess ou une authentification basique gérée par les pages/scripts. La différence se joue sur l'implémentation de la sécurité. En effet, un .htaccess est une solution immédiate et protégeant tout le contenu d'un répertoire (et de ses sous-répertoires) d'un seul coup, en une seule opération. Si tu gères l'authentification par les pages, il faut s'assurer que chaque page dont l'URL est ou peut être connue est protégée et fait la vérification de l'authentification. Cela peut donc supposer de modifier toutes les pages d'un site. Si tu fais du J2EE, tu peux passer par un filtre, c'est plus direct.

Pour ce qui est vraiment de l'aspect "sécurisé", il y a donc 2 choses :
1. S'assurer que toutes les ressources qui doivent être protégées (i.e. les pages) sont bien protégées et qu'on ne peut pas y accéder directement sans devoir s'authentifier.
2. Chiffrement des mots de passe. Ici, on ne veut pas que qq'1 puisse lire le mot de passe d'un utilisateur. Apache permet de définir des fichiers d'utilisateurs avec mots de passe chiffrés ou non. Il en va de même quand tu utilises une base de données (ou tout autre support de stockage) : tu peux décider de chiffrer le mot de passe en base de données ou de le stocker en clair. Il est évident qu'un stockage chiffré est mieux du point de vue sécurité. Ensuite, et c'est valable pour tout mécanisme d'authentification par login/mot de passe, on peut mettre en place du SSL pour s'assurer que personne ne pourra lire le login/mot de passe en live en "sniffant" la connexion. Enfin, la sécurité se joue aussi côté navigateur car les navigateurs peuvent mémoriser les logins/mots de passe. Est-ce acceptable ou non ? A ce propos, avec une authentification basique, un navigateur pourra toujours sauvegarder le login/mot de passe alors qu'avec une authentification par formulaire, tu peux bloquer cette sauvegarde avec l'attribut autocomplete=off dans la balise <form>.


Pour ce qui est de la détermination du choix de la solution, un point rédibitoire : l'authentification par .htaccess fait de l'authentification dite basique : en gros, y a un pop-up qui s'ouvre quand tu veux accéder à certaines pages. Tu ne peux pas avoir de page de login toute jolie avec des images et tout. Donc déjà, si cette solution n'est pas acceptable, oublie le .htaccess et dans ce cas il faut mettre en place des sessions. Si la pop-up d'authentification est acceptable, tu peux la mettre en place avec un fichier .htaccess mais tu peux aussi la mettre en place avec des scripts PHP, ASP ou autre sans .htaccess.

Après, la question vraie c'est de savoir quel est le référentiel pour tes utilisateurs. Et c'est ça la vraie question : fichier ou base de données. Et là, la réponse dépend de ce que je disais au début : les process de gestion des utilisateurs. En gros, la différence se joue sur le nombre d'utilisateurs à gérer et les "services" de gestion proposés. Si tu as peu d'utilisateurs et que tu n'as pas besoin d'infos supplémentaires comme une adresse, un numéro de téléphone (bref, tu fais que de l'authentification login/mot de passe), le .htaccess est largement suffisant. Si tu vas au-delà (beaucoup d'utilisateurs, besoin de stocker d'autres informations), il te faut une base de données ou un annuaire. La différence se situe surtout ici : nombre d'utilisateurs, données associées à stocker, possibilité pour les utilisateurs de changer de mot de passe ou leur profil, etc. C'est donc avant tout une question de complexité des données utilisateurs à gérer.

Dernier point : la notion de rôle (des admins ou des utilisateurs) n'est pas un critère déterminant à mes yeux : on peut définir des groupes dans les fichiers du .htaccess. On peut donc analyser ces fichiers dans les scripts (ou l'application) pour savoir si l'utilisateur a tel ou tel rôle.

J'ai oublié de dire : si le stockage des utilisateurs se fait dans des fichiers, il faut bien entendu que l'accès à ces fichiers depuis le réseau soit impossible (accès uniquement par les scripts/l'application). Il en va de même pour la base de données : elle ne doit logiquement être accessible que depuis les scripts/l'application, même si son accès requiert une authentification.

[PoichOU]

je te remercie Mac pour ta réponse que j'ai lu bien attentivement, c'est exactement le type de renseignement que je cherche.

En fait je distingue 2 choses sur mon site, l'utilisateur qui sont enregistrer en bdd et l'administrateur.

Pour mon site il n'y aura qu'un administrateur, donc pas de problème de gestion de droits spécifique. S'il a le login et le password il peut tout faire ! Je vais donc opter pour le .htaccess. Plus pratique car je suis sûr que tout sera sécurisé (autrement je pourrais toujours oublier une page )

Par contre pour la partie front office je vais stocker des utilisateurs en bdd pour pouvoir gérer des droits d'accès à certaines pages.


Merci beaucoup

PoichOU

PS : merci également pour 2 points que je connaissais pas :
- la notion de rôle dans le htaccess
- le autocomplete=off (super pratique !)*

[_Mac_]

Oui, c'est une très bonne façon de faire.

Envoyé par PoichOU

PS : merci également pour 2 points que je connaissais pas :
- la notion de rôle dans le htaccess

Attention : j'ai pas dit que le .htaccess permettait de gérer les rôles. Je dis juste que le .htaccess peut utiliser des groupes et qu'il est dès lors facile de construire des groupes qui correspondent à des rôles. Il faut quand même faire du code pour lire le fichier de groupes pour "décoder" ces rôles. Apache ne voit que des groupes à utiliser éventuellement avec un Require.

[PoichOU]

oui j'imagine bien que ce n'est pas évident à faire et qu'il faut faire un petit peu de code pour ça.

Je ne pense pas en avoir besoin pour le moment, mais je garde l'idée dans ma tête.