Discussion :

[RunCodePhp]

Ca c'est un problème de structure de l'appli. En principe ...

Justement, en principe.
- On n'en sait fichtre rien du comment est ou sera structuré son projet.
- De combien d'admin il y aura, de leur connaissance dans ce domaine.
- Du comment sera exploité cet espace, quels type fichiers y seront déposés.
- De même sur le degrés de confidentialité de tous les contenus (quand bien qu'une image présenterait aucun risque, rien ne dit que celle ci ne devra pas être accessible via une banale URL).
Bref, on en sait rien.

Avec ce couple de .ht*, on a même pas besoin de se poser la question : Quelque soit l'URL pointant sur cet espace, une identification sera demandée.
C'est quand même pas un détail.

En admettant maintenant que tout les fichiers Php sont en dehors du virtualhost, et donc que tout transit par l'index.php (routage), et bien ce fichier lui se trouve tout de même dans le virtualhost, et non protégé.
J'ai tendance à dire que s'il y a un fichier à protéger, c'est l'index.php
Avec les .ht*, il le sera.

Perso j'ai jamais eu un client qui acceptait de se logguer 2x (une fois pour le htaccess , une autre fois pour la gestion de ses droits sur le backoffice).

J'ai jamais rien dis de tel, en plus ce n'est pas le cas.

Lors d'une identification via ce couple .ht*, les login/pass sont stockés immédiatement dans $_SERVER :
$_SERVER['PHP_AUTH_USER']
$_SERVER['PHP_AUTH_PW']
A partir de là, on peut absolument tout faire, tout imaginer.

Comme par exemple créer dans sa Bdd une table "admin" avec les mêmes login/pass, voir donc une table "admin_droits" (ou autre système peu importe).
Une fois l'identification effectué, on vérifie dans foulée au niveau la Bdd, et on récupère les infos dont on a besoin (comme les droits).

Après ça, rien n'empêche d'exploiter les session pour gérer la persistance des données dont on a besoin, je dirais plutôt que l'un complète l'autre, et rajouter un système de token, les mettre en Bdd, etc ...
Bref, on fait ce qu'on veut.


Quelque part, ça fait une double vérification, mais ceci ne fait que ça renforcer d'autant plus la sécurité.
Il n'y a pas une double identification en tout cas.



Toujours est il que je suis étonné que personne ne suggère une protection par .ht*, alors que tous les CMS que j'ai pu parcourir sécurisent le backoffice ainsi, de même que tous les sites de développement il est dit que celle ci est plus sécurisée que les sessions seules.
Si ce n'est pas le cas, alors ça m’intéressais vraiment de savoir pourquoi.

[alpha232]

Salut à tous, j'ai appris beaucoup avec ce post, car je n'utilise pas les fichiers ht.access dans mes application. ça à l'air vraiment intéressant.

Je vais rajouter que l'on peut apporter un plus au niveau de la sécurité, en plaçant la partie client dans un dossier sécurisé (ssl) en utilisant HTTPS. Les hébergeurs commencent à proposer cette possibilité, même pour des hébergements mutualisés (ovh par ex).

Alpha.

[grunk]

Lors d'une identification via ce couple .ht*, les login/pass sont stockés immédiatement dans $_SERVER :
$_SERVER['PHP_AUTH_USER']
$_SERVER['PHP_AUTH_PW']

Exact, j'avais oublié ce détail.

Si ce n'est pas le cas, alors ça m’intéressais vraiment de savoir pourquoi

L'authentification HTTP (comme l'authentification par session) reste sensible au attaque du type "Man in the middle".
Du coup la seule véritable solution c'est de passer à l'https.

Il me semble (jamais testé) que l'authentification HTTP Digest est l'étape encore supérieur en terme de sécurité à l'authentification HTTP simple

[RunCodePhp]

L'authentification HTTP (comme l'authentification par session) reste sensible au attaque du type "Man in the middle".
Du coup la seule véritable solution c'est de passer à l'https.

Pour le https, pourquoi pas, mais là on change de sujet à mon sens.

Que l'on mette du SSL ou pas, une authentification par .ht* fonctionne (http/https), ça fait au moins 4 ans que je fonctionne comme ça.


Mais la question au départ était si une sécurité par session est suffisante pour un backoffice (avec ou sans SSL).
Pour ma part non.
Mais comme je l'ai dis plus haut, l'un n'empêche pas l'autre, voir même l'un complèterait l'autre.

Bref, quelqu'un demande un conseil, et bien ça me semble important de dire explicitement et sans détour que l'un est plus adapté que l'autre, sans avoir besoin de rentrer dans les détails, et même sans en connaitre tout le mécanisme.


Après ça, j'ai aussi lu quelques infos sur ce HTTP Digest, mais jusqu'à lors ça m'a paru surdimensionné.

[Capie]

J'avoue être un peu dans le brouillard avec certaines de vos interventions ^^ Mais c'est très intéressant néanmoins et j'en ai appris pas mal grâce à vous !

Pour résumer, les .ht sont bien mieux que les sessions pour un back office. Pour l'espace membres, session(s) + bdd.

[alpha232]

Salut Capie,

Je pense que tous les intervenants ont donné des réponses logiques et bien à propos.

Je me permet de résumer :
En quelques mots, tu désires faire faire un site qui donne un accès sécurisé à certaines personnes.

Si ce site est du "style" forum, blog ou autre du même genre, je me contenterais d'un système login/mdp géré au niveau de la db et des sessions (pour transférer les infos style usrname/level, ... )

Si c'est un système contenant des fichiers (pdf, images, texte, ... )ne pouvant être accessible par d'autres personnes que celles prévues, alors on pourrait appliquer la methode de RunPhpcode , qui consiste à rajouter l'authentification au niveau ht.access .... etc ...).

Dans tous les cas , tu peux prévoir une connexion https, pour la partie client, ou membre, et cela c'est chez ton hébergeur que l'on configure ....
Cela permet simplement de crypter les infos qui sont échangées en mode https.

Ceci est simplement mon point de vue, bien entendu ...
Alpha.

[ABCIWEB]

Pour ma part j'ai commencé avec des .htpassword et j'utilise maintenant des sessions. C'est plus souple par contre comme le dit RunCodePhp cela demande plus de précautions.

Dans les deux cas, prendre soin de hasher les mots de passe avant de les transmettre dans les tuyaux du web.

[grunk]

Dans les deux cas, prendre soin de hasher les mots de passe avant de les transmettre dans les tuyaux du web

J'ai bien envie de dire que ça sert pas à grand chose (sauf cas du https)

Que tu es dans ta requête HTTP

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

login=toto&pwd=titi

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

login=toto&pwd=aù*$:ckfhehkqofplv20ldf

c'est du pareil au même puisque la personne malveillante voulant s'identifier n'aura qu'a renvoyer cette requête pour s'identifier sans même avoir besoin de connaitre le mot de passe

Après effectivement crypter/hasher le mdp avant l'envoi évite de facilement connaitre le mot de passe en clair mais ca n’empêche absolument pas une authentification.

[ABCIWEB]

J'ai bien envie de dire que ça sert pas à grand chose (sauf cas du https)

Que tu es dans ta requête HTTP

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

login=toto&pwd=titi

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

login=toto&pwd=aù*$:ckfhehkqofplv20ldf

c'est du pareil au même puisque la personne malveillante voulant s'identifier n'aura qu'a renvoyer cette requête pour s'identifier sans même avoir besoin de connaitre le mot de passe

Après effectivement crypter/hasher le mdp avant l'envoi évite de facilement connaitre le mot de passe en clair mais ca n’empêche absolument pas une authentification.

Ah ben faut pas jouer la partie aussi simple non plus.
Rien ne t'empêche de concaténer ton mot de passe avec un grain de sel à chaque fois différent avant de hascher l'ensemble et d'envoyer le résultat dans ton post

[Capie]

Merci à tous pour vos réponses. On voit que vous vous y connaissez pas mal et que vous avez chacun une certaine expérience. Et c'est très appréciable de parler avec vous

Encore une question et je vous dérange ^^

- Est ce que c'est mieux d'utiliser le session_id généré automatiquement et de ne pas créer de session (session_id est stocké dans un cookie je crois) ou de générer soit-même une chaine que l'on stocke au choix dans une session (pour un back office) ou dans un cookie (pour l'espace membres, si ceux-ci veulent rester connecter plusieurs jours) ?
Cf: http://a-pellegrini.developpez.com/t...hp/session-db/

[RunCodePhp]

... ou de générer soit-même une chaine que l'on stocke au choix dans une session (pour un back office) ou dans un cookie (pour l'espace membres, si ceux-ci veulent rester connecter plusieurs jours) ?

Cette 2ème ne peu pas ce faire car le principe même des sessions repose sur 1 session ET 1 cookie.
L'un ne va pas sans l'autre.

Bon, c'est un peu faut, car il y a 2 manières de transmette cette information (un identifiant) dont a besoin pour savoir si on a affaire à la même personne (la persistance), c'est :
- Soit on la met dans toutes les URLs/formulaire, etc ... qui fera que le serveur va la recevoir. C'est à mon sens la manière la moins propre/sécurisé.
- Soit dans un cookie, qui lui est un poil caché dans l'entête de la requête HTTP.

Pour ma part, pour un backoffice on peu imposer que les cookies soient activés.
On peu même imposer bien plus que ça, pour ne serait ce ne pas se limiter dans le développement.


Je n'ai pas de véritable avis sur ta dernière question, sinon de dire que laisser le serveur accorder l'identifiant serait plus simple, ce n'est pas ça cause le plus de problème.
Le vrai fond du problème c'est qu'il manque cruellement des infos de manière fiable venant de la part du client (navigateur).
On a beau hacher/cryper, etc ..., il y aura toujours une forme d'incertitude sur la véritable identité de la personne qui interroge le serveur.

A coté de ça, il faut que tu te fasse toi même une idée du comment gérer tes sessions, qu'est ce qui te semble le minimum obligatoire ou démesuré.
Nous, on en sait rien se représente ton backoffice, qui sont les intervenants, du degrés de confidentialité des données, de sa notoriété, etc, etc ...
C'est entre autre ça qui va déterminer les moyens à utiliser.



D'ailleurs, avec le Html5, on se demande s'il n'y aurait pas là un moyen de sécuriser une partie admin/backoffice.
Il y a un tuto d'ailleurs qui donne un exemple sur 2 nouvelles fonctionnalités :
Comprendre le storage en HTML5

Je retiens particulièrement ceci :

localStorage, quant à lui, conserve les données pour une durée indéterminée

Je ne sais pas si vous pensez à la même chose, mais il y a quelque chose à exploiter la dedans.

Je me demande s'il n'y aurait pas moyen par exemple de créer 2 éléments localStorage manuellement dans chaque PC de tous les admins, qui seront les login/mot de passe.
Et bien partant ce là, coté application dans le formulaire d'identification, il suffirait alors de créer un Javascript qui se déclencherait à la validation, qui par la suite vérifierait si les login/passent saisies correspondent.
Ceci n'excluant pas bien sûr la vérif coté serveur.

Il y a même une autre fonctionnalité : WebSoket (qui s'apparente à de l'Ajax).
On peu alors prévoir qu'un WebSoket soit envoyé coté serveur avec un hachage tout de même sur une 3ème données (genre de clé privée), et le serveur la vérifierait.


Coté Html5, il y a aussi le WebSQL aussi (SQLite), mais apparemment c'est en standby, et il y a aussi indexedDB, mais je ne sais pas si c'est persistant comme données.

Vous en pensez quoi de ces nouvelles techniques ?
Je pense que c'est vraiment intéressant, que ça vaut le coup de se pencher la dessus.


Désolé, je déborde un peu, mais comme je suis en train de prospecter un peu ce Html5 ...

[ABCIWEB]

Bon, c'est un peu faut, car il y a 2 manières de transmette cette information (un identifiant) dont a besoin pour savoir si on a affaire à la même personne (la persistance), c'est :
- Soit on la met dans toutes les URLs/formulaire, etc ... qui fera que le serveur va la recevoir. C'est à mon sens la manière la moins propre/sécurisé.
- Soit dans un cookie, qui lui est un poil caché dans l'entête de la requête HTTP.

Pour ma part, pour un backoffice on peu imposer que les cookies soient activés.

J'irais même un peu plus loin en disant "pour un backoffice on doit imposer que les cookies soient activés" pour sécuriser le plus possible les sessions.

@Capie Tu peux imposer que les identifiants de sessions passent dans un cookie en faisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ini_set('session.use_only_cookies', true);

En complément (pour compléter ce paramétrage) tu envoie un cookie lors de l'authentification et tu teste sont existence. S'il n'existe pas tu ne démarre pas la session et tu indique que les cookies doivent être activés dans le navigateur.

[Capie]

Merci à tous !! J'ai toutes les infos nécessaires pour réaliser un back office sécurisé à la mesure des données qui y transiteront.