[Sécurité] Sécurité : gestion des comptes admin

[ChriGoLioNaDor]

Bonjour,

Ma question est simple, mais je n'ai hélas pas trouvé de réponse. J'ai un site de ecommerce que j'ai créé, et que je voudrais l'améliorer, en termes de sécurité. Pour le moment, l'identification des membres et de l'admin se passe ainsi :

- Lorsque l'utilisateur clique sur "s'identifier", il saisit son pseudo et son mot de passe.
- Le système vérifie les informations saisies et le résultat est stocké dans une variable de session ($_SESSION['is_logged']=true ou false).
- Dès que le client va sur une page "sécurisée", si $_SESSION['connecte']==true, il voit la page, sinon il a un petit message disant qu'il n'a rien à faire là.

Pour les membres, ce système me va plutot bien : il est très simple à mettre en place, et même si la sécurité n'est pas à toute épreuve, cela suffit. Même si quelqu'un arrivait à dérober un compte utilisateur, il ne pourrait pas faire grand chose avec (tout au plus avoir l'adresse email et postale du membre, ce qui n'est pas des plus intéressant pour un pirate informatique).

Par contre pour identfication de l'admin, si un pirate avait accès à ce compte, il pourrait faire des ravages (par exemple supprimer tous les articles du site, effacer les commandes etc). C'est pour cela que je me permets de vous demander votre avis.


Ma méthode d'identification est-elle raisonnablement sécurisée? Est-ce qu'il serait possible pour un pirate de modifier la valeur de mes variables de session (sachant que ce n'est qu'un booléen) de l'extérieur? Faudrait-il plutot que j'enregistre le pseudo et le pass du membre une fois crypté, pour revérifier l'identification à chaque ouverture de page? Mais dans ce cas, un pirate ne pourrait-il pas accéder à ces valeurs, et obtenir ainsi ces informations (j'ai vu que le cryptage md5 était maintenant décryptable facilement)?

Bref, que me conseilleriez-vous pour avoir un système d'identification fiable, et si possible relativement simple à mettre en place?

Merci d'avance

[dj-julio]

Il faudrait plutôt que tu te penches sur une sécurisation par fichier .htaccess, je crois bien avoir entendu dire que ce système n'a encore jamais été violé !!

Tu crées un répertoire "admin" par exemple, dans lequel tu mets toutes les pages auquelles les admins ont accès (ainsi que le fichier comportant les informations de connexion à ta base).
Tu protèges ce répertoire avec un fichier .htacces, tu crées un fichier .htpasswd et c'est bon !

Pense à mettre ton fichier .htpasswd (là où les mots de passes admin seront stockés) dans un répertoire comportant lui même un fichier .htaccess avec la ligne suivante : (deny from all).

De cette façon le fichier comportant les mots de passes sera totalement inviolable.

Bon courage

[ChriGoLioNaDor]

Merci de ta réponse. Je me suis documenté, et voici ce que cela donne :

Dossier_à_protéger/.htaccess

Code :

1
2
3
4
5
6
7
8
AuthUserFile /homepages/.../htdocs/test2/admin/password/.htpasswd
AuthGroupFile /dev/null
AuthName "Accès protégé"
AuthType Basic
<LIMIT GET POST>
 
Require valid-user
</LIMIT>

/test2/admin/password/.htaccess

Code :

Deny from all

/test2/admin/password/.htpasswd

Code :

Nom:mdp_crypté

J'ai bien suivi?

[fadex]

Bonjour

je suis la même démarche depuis x temps , donc je me base sur les variable session pour sécuriser mes page.

mon problème c que je ne peux pas utiliser le htaccess par ce que mais pages admin son les même que les pages client sauf qu'il a des menu disparessent si le compte n'est pas admin. c vrais que mais app marche bien mais j'ai entendu parler d'une technique de vole de session .

une solution

merci d'avance

[ChriGoLioNaDor]

Le soucis aves les htaccess, c'est que j'utilise de plus en plus d'objets. Et par définition, mon objet contient mes méthodes "libres" (par exemple lister les articles), et les méthodes "restreintes" (ajout ou suppression d'article par exempl). Donc pas possible de mettre de htaccess (du moins pas à ma connaissance).

Pour le vol de session, j'ai vu cet article, qui est plutot bien fait : http://phpsec.org/projects/guide/fr/4.html
Mais bon, il y a toujours un risque (c'est aussi à l'utilisateur de faire attention, on ne peux pas tout protéger à max).