Bonjour,
 
Jusqu'à aujourd'hui, j'utilise les sessions pour protéger les parties privés d'un site. Mais je me demande si au niveau sécurité, c'est vraiment bien pour ce que je veux mettre en place maintenant.
 
Je m'explique: j'aimerai pouvoir mettre à disposition des documents confidentiels (word, excel, images, pdf ...) qui seraient accessibles à l'aide d'un login / mdp différents pour chaque utilisateur.
 
Les documents ne sont pas secret d'état non plus mais ils contiennent des informations sur ma société et il ne faudrait pas que n'importe qui y accède. Je ne recherche pas une sécurité absolue mais un truc suffisamment balaise pour ne pas être cassé en 10sec.
 
Je ne connais pas trop SSL, est ce que ca pourrait être une solution ? Si oui, comment met on en place de genre de sécurité ?
 
Merci pour votre aide.

SSL (https://) est un protocole de transfert, tout comme le http l'est. Tu peux utiliser le https et pourtant proposer un accès public à tes documents, comme tu peux utiliser le http et proposer qu'un accès privé nécessitant des identifiants d'accès...
 
Avec le http les données transitent en clair sur Internet, alors qu'avec le https les données sont chiffrées.
 
Ce n'est pas la voie qui t'intéresse pour l'instant. Ce que tu devrais mettre en place, c'est une classe PHP de session un peu plus avancée que de simplement "utiliser les sessions". Par exemple, ajouter un contrôle du nombre de tentatives de connexion (détecter et bloquer les tentatives de type brute-force qui consistent à essayer plein de mots de passe les uns après les autres). Délivre tes documents avec PHP, vérifie qu'ils ne sont pas dans un espace accessible (empêche Apache de les délivrer avec un p'tit htaccess bien placé... etc.). Bref, des choses tout ce qu'il y a de plus basique.
 
Quand ton système d'authentification sera au point, fiable et à la pointe de la sécurité, tu pourras alors penser à proposer l'identification de tes membres par connexion https uniquement.

OK, merci pour cette réponse.  
 
Je vais regarder ce qui existe comme script pour éviter de réinventer la roue.
 
Donc les sessions sont suffisamment fiables ? A condition de rajouter les fonctions dont tu parle.  
 

Les sessions peuvent être brisées par un vol de cookie de session.
 
Enfin quand on en arrive là, c'est que c'est quand même des documents très sensibles... surtout si ta session est réglée pour ne durer que quelques minutes.
 
Les problèmes peuvent également se trouver ailleurs, par exemple si un keylogger est placé sur le PC du client et enregistre les mots de passe.
 
Le mieux c'est une solution en direct live et à base de hardware, c'est à dire comme lors d'un achat sur Internet : tu saisis ton code, puis ta banque t'envoie un code par SMS que tu dois saisir (ce code varie donc dans le temps). En séparant les identifiants sur différents hardware, on renforce la sécurité.

 
Lol attends là tu parles de soucis que même les sites de banques ne se posent pas ! le garçon là il parle de documents "confidentiels mais pas trop", qui à mon avis requiert une "simple" authentification par mot de passe, à l'image de google docs, et vu qu'on parle de "documents d'entreprise", étant donné que beaucoup d'entreprises stockent des docs confidentiels sur google docs, je pense que c'est un bon exemple.
 
 

 
le vol de cookie est vraiment le dernier des recours qu'un voleur peut trouver ! avant il aura essayé le keylogger, le fishing, la menace avec présence physique , et bien d'autres méthodes bien plus simples que le vol de cookie ! ensuite suffit d'ajouter quelques vérifications en plus, par exemple associer un cookie à une IP ainsi qu'un user-agent, rendant le vol de cookie presque inutile.
 

ça c'est un problème insoluble par le site, seul l'utilisateur du PC est responsable d'assurer que son PC n'est pas espionné ! on peut rien y faire, et la méthode de frappe visuelle sans clique du site de la banque postale ne sert absolument à rien car c'est tout aussi simple de suivre les mouvements de la souris et de capturer où se trouve les chiffres, ça ne fait que rendre inoffensif les anciens keyloggers, mais des nouveaux adaptés à la nouvelle méthode de frappe apparaissent donc au final on a rien gagné.
 

Merci pour vos réponses.
 
En effet, je ne cherche pas une sécurité identique à celle d'une banque.
 
Je vais rester sur les sessions en protégeant au maximum l'authentification. J'ai cherché un peu sur google mais je n'ai pas trouvé mon bonheur, il y a des scripts mais pas assez verrouillés. Vous en avez pas un en stock ? Ca m'éviterai de partir de zéro.
 
Merci

Perso j'ai juste un wiki avec un .htaccess et une session de 10 minutes.
Ça suffit largement.

Bon je me lance dans un script. Voici comment je compte m'y prendre :
 
les mots de passe seront stockés cryptés (sha256) dans la base sql. Est ce suffisant comme niveau de cryptage ? Vous en conseillez un autre ?
 
Une fonction d'identification se chargera de vérifier que le login / mdp sont corrects. Si c'est le cas on enregistre les variables suivantes : $_SESSION['identification'] = 1; et $_SESSION['identification'] = $id; (id du user).
 
Je compte ensuite enregistrer l'id de la session dans une base avec le timestamp à ne pas dépasser (timestamp de l'identification + x minutes) et comparer à chaque chargement de page le timestamp actuel et celui stocké. Ca ne va pas être trop lourd pour le serveur de vérifier ca à chaque page ?
 
Pour les tentatives de force brute, je ne sais pas trop comment faire. Vous avez une piste ?
 
Merci pour votre aide

Il manque un dernier truc ...
 
tu connais le film "le village" ?
 
l'espion peut aussi venir de l'intérieur. Qu'est-ce qui te garantit qu'une fois connecté à ton interfae membre, la personne n'ira pas filer le lien direct vers une image ou un doc ?
Penses-y, à sécuriser ça aussi. La "fuite" des données.
car HTTP ou HTTPS, une image est une image, donc envoyée au navigateur client (il peut donc à loisir l'enregistrer) et tu ne pourras rien faire contre.

Oui je pense protéger les repertoires avec un htaccess, je ne m'y suis pas penché encore.
 
Je comptais stocker les données dans une base sql aussi, au moins c'est plus sur non ?