[Sécurité] Sécurité totale pour un espace membre [Débat]

[doof]

Envoyé par ermelir

et le vol de sessions? c'est pas bien difficile, il suffit d'etre patient
m'enfin bon, je doutes que sur un site perso des utilisateurs tentent de faire du vol de session

D'autant plus que seulement ip + port ne permet pas d'identifier de facon unique quelqu'un, que faisons nous de ceux qui sont sur un reseau local, derriere un proxy ? (bien sur, sans utiliser les sessions a ce moment comme le concoit Sub0)

Envoyé par ermelir

:s tu peux pas différencier les utilisateurs derriere un proxy alors?

Cruel dileme, ne pas doubler la verification de session + verification d'IP permet le vol de session ! c'est embetant ca.

Tout ceci me fait réfléchir et m'amene a 2 questions :

1* Pourquoi vouloir eviter les cookies ?? Ils ne sont dangereux que dans le cas ou l'on peut publier un texte lisible par d'autres utilisateurs, ce qui n'est pas trop le cas pour un acces 'admin'

2* Finalement, un htaccess n'est-il pas la solution ultime par rapport aux sessions ? ... peut-on voler un acces de ce type ? comment le serveur reconnait le client dans ce cas ? cookies ? ip ? ...

[Sub0]

Je profite du topic pour ajouter quelques liens sur le sujet...
Pour les membres qui veulent faire la synthèse du topic, il ya des éléments intérressants :

http://bob.developpez.com/phpauth/
http://thierrylhomme.developpez.com/php/php_secure/
http://www.hsc.fr/ressources/present...ss/ces-xss.pdf
http://www.urec.cnrs.fr/securite/out...tation-ssh.pdf
http://securit.free.fr/ressources/ssl_v3.pdf
http://www.salemioche.com/doc/ssl4.php
http://www.rcmp.ca/scams/ccprev_f.htm
http://www.certa.ssi.gouv.fr/site/CE...ex.html.2.html

Cordialement.

[Sub0]

Envoyé par m@

un utilisateur qui donne le bon mot de passe est le bon utilisateur point.
et si quelqu'un réussit à intercepter le mot de passe, il est très probablement capable de transmettre les bones infos de navigateur, ip...

Je suis bien conscient qu'il n'est pas possible de protéger tous les accès. Un utilisateur qui se ferait voler son cookie, un pirate qui arriverait à se faire passer pour un membre par exemple. Mais ce pirate ne pourra pas aller plus loin que l'affichage de ce compte... La protection des autres comptes sera assurée et c'est l'essentiel... En gros, il ya 2 étapes :
-> L'enregistrement du membre (1ère identification)
-> La connexion automatique (cookie & session, navigation).

L'hébergeur pour lequel je travail utilisera prochainement une connexion http sécurisée (SSL)...
Pour l'instant, voici ce que j'envisage :

1) Un utilisateur entre sur le site. Les informations de sa config seront cryptées et enregistrées temporairement, soit dans la base de données, soit dans un fichier php (je ne sais pas trop encore)... Remarquez qu'un utilisateur qui ne veut pas s'enregistrer ou s'identifier n'aura pas grand chose à faire sur le site... Un utilisateur qui utilise un proxy pourra lui être demandé de se reconnecter sans proxy aussi (faut voir si cela serait vraiment utile ?).
2) Il remplit le formulaire d'inscription et valide son enregistrement en activant son compte par email (comme pour le forum). A l'activation du compte, il obtiendra un mot de passe généré aléatoirement de 8 caractères. Un cookie pour la "connexion automatique" pourra être crée (option du formulaire de connexion).
3) Le visiteur devient "membre". A chaque visite sur le site, ses paramètres de config seront comparés avec les dernières informations enregistrées. Si il ya des différences notables, l'identification du membre sera demandée. Sinon...
4) Son cookie sera téléchargé : Les informations contenues dans ce fichier seront décryptées puis comparées avec celles enregistrées dans la base de données. Si il ya des différences notables, l'identification sera demandée.
5) En cas d'échecs répétés de l'identification, un message d'erreur sera affiché signalant que le compte sera bloqué pendant quelques minutes. Le signalement sera aussi adressé au support technique...
6) En cas de tentatives d'usurpation de l'ID de session, un signalement sera également adressé au support technique avec les infos de config du visiteur ayant l'ID incorrecte. Son IP sera alors ajoutée à une "blacklist" pour un temps indéterminé... En tous les cas, cet utilisateur ne pourra déjà plus accèder aux formulaires avec cette IP.

Au lieu d'utiliser les variables de session, je pourrais passer le login d'une page à l'autre avec POST...
Que pensez-vous de tout ça?

Merci pour votre aide!

[m@]

Envoyé par doof

D'autant plus que seulement ip + port ne permet pas d'identifier de facon unique quelqu'un, que faisons nous de ceux qui sont sur un reseau local, derriere un proxy ? (bien sur, sans utiliser les sessions a ce moment comme le concoit Sub0)

exact, j'vais pensé au NAT, mais pas aux proxies

Envoyé par ermelir

et le vol de sessions? c'est pas bien difficile, il suffit d'etre patient
m'enfin bon, je doutes que sur un site perso des utilisateurs tentent de faire du vol de session

encore une fois, les sessions restent le moyen le plus fiable de suivre un visiteur. Le vol de sessions peut être rendu très difficile par l'utilisation de cookies et des appels à session_regenerate_id()

Envoyé par doof

1* Pourquoi vouloir eviter les cookies ?? Ils ne sont dangereux que dans le cas ou l'on peut publier un texte lisible par d'autres utilisateurs, ce qui n'est pas trop le cas pour un acces 'admin'

les cookies sont dangereux car ils sont modifiables par le visiteur. voler un cookie est infiniment plus simple que voler une session.

Envoyé par doof

2* Finalement, un htaccess n'est-il pas la solution ultime par rapport aux sessions ? ... peut-on voler un acces de ce type ? comment le serveur reconnait le client dans ce cas ? cookies ? ip ? ...

le htaccess est basé sur l'authentification HTTP il peut être attqué par sniffintg, mais c'est un système rodé qui a fait ses preuves

[m@]

si tu passes les variables par session, elles restent stockées sur le serveur.
par POST elles sont stockées chez le client, et elles doivent donc faire plusieurs fois le voyage client<->serveur

[ermelir]

Envoyé par m@

encore une fois, les sessions restent le moyen le plus fiable de suivre un visiteur. Le vol de sessions peut être rendu très difficile par l'utilisation de cookies et des appels à session_regenerate_id()

tout a fait d'accord, seulement 100 % n'existe pas: il faut pas se dire que vu que l'on utilises les sessions coté serveur, y a pas de soucis je penses que tu le sais, mais bon je preferes le preciser pour les autres personnes qui pourraient lire ce topic

Envoyé par m@

]
le htaccess est basé sur l'authentification HTTP il peut être attqué par sniffintg, mais c'est un système rodé qui a fait ses preuves

seulement, si tu te fais sniffer lors de ton authentification http, quelque soi t la methode utilisée ca ne tiendra pas

[m@]

http://sub0.developpez.com/php/m@/authentification.htm

qu'en pensez vous ??

cordialement

[mathieu]

Petite information supplémentaire : comment ne pas faire circuler le mot de passe en clair sur le réseau ? (cela ne concerne pas ceux qui utilisent SSL)
la technique est celle utilisée par SPIP ( http://www.spip.net/fr )

la base de données contient les 3 champs suivant par login
- le grain de sel (que je vais appeler GDS)
- un champ égal à md5(GDS + mot de passe)
- le grain de sel suivant (GDS2)

La méthode est la suivante :
- un 1er formulaire demande le login
- envoie du login au serveur
- le serveur renvoie un 2ème formulaire de saisie du mot de passe. ce formulaire connaît GDS et GDS2 de la base de la base de donnée pour ce login
- le javascript de ce formulaire s'occupe de ne pas envoyer le mot de passe mais seulement les informations "md5(GDS + mot de passe)" et "md5(GDS2 + mot de passe)"
- le serveur compare la valeurs "md5(GDS + mot de passe)" avec la base de données et si c'est correct, l'utilisateur est authentifié, GDS2 remplace GDS dans la base de données, "md5(GDS2 + mot de passe)" est mis dans le 2ème champs et un nouveau GDS2 est généré.

Inconvénients :
- le fait de valider 2 formulaires est embêtant :
- en cas de mauvais mot de passe le système de SPIP demande de revalider le login dans le 1er formulaire avec le champ login pré-rempli
- javascript obligatoire

tout cela à fait que mon responsable de stage de l'époque m'a demandé de désactiver cette usine à gaz
mais dans le cadre d'une page d'administration avec des personnes autorisées à se connecter bien connues, ce système peut être utile.

[ermelir]

Envoyé par Sub0

Cela remet en question pas mal de choses! En particulier, même avec une connexion SSL, un membre pourrait se faire voler son login lors de son identification (envoi des informations sur le serveur)... D'où la necessité de crypter ces informations selon moi.
* *

non Sub0; le point de vue que j'ai enoncé n'est pas du point de vue du client mais du serveur. l'absence de certificat validé coté client ne permettra pas a quelqu'un entre les deux parties d'intercepter les données (enfin si la longeur de la clé est suffisamment forte bien sur ) puisque ton client web utilises aussi le protocole SSL
Mais par contre l'abscence de certificat coté client ne permet pas effectivemment d'assurer que le client provenant de l'ip xxx.xxx.xxx.xxx qui a demandé la suppression de la database est bien reellement l'admin de l'appli.
ca n'est pas clair dans mon tuto? je veux bien des retours

[Sub0]

Salut!

Envoyé par ermelir

ca n'est pas clair dans mon tuto?

Non, ça n'est pas clair effectivement... Comme tu as pu le constater, j'ai vraiment eu l'impression que le SSL ne servait plus à grand chose si le client ne possède pas aussi un certificat! Maintenant, je crois que j'ai compris : Le serveur possède un certif, cela garanti que les données envoyées par le client seront protégées... Si le client n'a pas de certif, les données envoyées par le serveur ne seront pas protégées (c'est ça?)... Autrement dit et dans ce cas précis, le client peut très bien recevoir un formulaire à remplir qui aura été détourné préalablement par un pirate...

Le pirate se situe au niveau du canal Serveur→Client...
Le canal Client→Serveur est quant à lui, protégé par le certif du serveur.

Comment les pirates peuvent-ils exploiter cette faille?
Merci de votre aide!

[ermelir]

salut

la présence d'un serveur https assure l'encryption des données lors du transit entre le client et le serveur.
la validation d'un certificat - que ce soit chez le client, mais surtout sur le serveur - assure bien que la personne avec qui tu dialogues est bien la personne escomptée.
Maintenant le fait de ne pas avoir de validation de certificat coté client te permets - de par l'utilisation du https du coté serveur - que la transmission etablit est bien avec cette personne (en gros qu'il n'y a pas de "man in the middle" - mais ne te certifie pas que la personne qui a saisit admin / root dans ton formulaire est bien l'administrateur de l'application
voila, j'espère que c'est plus clair cette fois ci.
Je vais modifier le contenu de cette page de mon tutorial

[m@]

essayons de trouver une image :

• imagine que HTTPS soit une enveloppe, impossible à ouvrir :
si tu veux envoyer une information de façon sure à quelqu'un, tu vas écrire ta lettre et la mettre dans une enveloppe HTTPS, puis la confier à La Poste.
sans HTTPS, un curieux aurait pu récupérer ta lettre dans la boîte aux lettres, ou un employé de La Poste aurait pu la lire, etc.

•après, quand tu reçois une enveloppe HTTPS, tu sais que personne d'autre que son expéditeur n'a lu la lettre, et que encore moins de monde l'a modifiée.

•...mais rien ne te prouve que le nom de l'expéditeur marqué sur l'enveloppe correspond bien à l'expéditeur réel.

•imaginons donc, un certificat médiéval : le cachet de cire : l'expéditeur ferme son enveloppe en y apposant son cachet. Si tu connais déjà le cachet de l'expéditeur (qui biensûr est inimitable et infalsifiable), sa seule vision te permet d'authentifier l'expéditeur.

•par contre, si tu ne connais pas son cachet, tu dois faire appel à un organisme de certification, auprès duquel l'expéditeur s'est enregistré (et c'est ça qui est payant), et qui attestera que ce cachet est bien celui de l'expéditeur.

cordialement

[m@]

je n'avais pas lu la question de Sub0 :

Comment les pirates peuvent-ils exploiter cette faille?

quand je tape l'adresse de ton site dans mon navigateur, quel que soit le protocole, je fais appel aux DNS, qui associent ton nom de domaine à une IP

si, touché par la grâce, je découvre comment pirater un DNS, je peux associer ton nom de domain à mon IP, laquelle IP contiendra un site web, imitant en tout point le tien. je récupère directement les infos rentrées par les utilisateurs (et donc les pswd)

si je suis dans un mauvais jour, et que le DNS me résiste , je peux encore "détourner" les paquets à destination de ton IP sur la mienne, et à nouveau me faire passer pour toi.

maintenant, si ton serveur a un certificat, je ne peux plus abuser tes visiteurs, car je ne peux pas leur fournir le bon certificat.

par contre comme tes visiteurs n'ont pas de certifcat, tu ne peux pas déterminer s'il s'agit plutôt de X ou plutôt de Y. tu es obligé de faire confiance aux informations qu'ils te transmettent, à savoir login et mot de passe.

cordialement

[m@]

dsl d'enchaîner les posts, mais comme ils sont tous les 3 sur un sujet différent, je oréfère ne pas les regrouper.

voilà juste une question qui suit les posts précédents...

nous sommmes, je pense tous d'accord pour dire que le must en terme d'authentification serait que nos visiteurs est un certificat (à supposer que ce certificat leur soit propre et ne soit pas propore à l'ordinateur qu'ils utilisent), plutôt qu'un simple login/mdp.

je voudrais votre avis sur la méthode suivante qui plagie le principe des certificats pour ce qui nous intéresse, et qui suppose (juste ?) qu'on ait une implémentation de RSA en javascript (ou dans un autre langage client), et une liaison chiffrée.

à l'inscription d'un utilisateur, le serveur HTTPS génère clé publique CP et une clé privée CS.

il conserve CP et transmet CS

à chaque connexion, le serveur génère un message aléatoire et le transmet au client.

le client le chiffre avec CS (via javascript) et le retransmet chiffré au serveur.

le serveur le déchiffre avec CP et le compare au msg de base.

+ un vol de la bdd du serveur est sans conséquence, ce qui n'est pas négligeable
+ à aucun moment des infos sensibles ne voyagent sur le réseau
+ CS est un mot de passe plus que sûr

- CS n'est pas facile à apprendre et devrait sans doute être mémorisée par un programme tiers

qu'en pensez vous ???

[Koo]

je fait unpeu dévier le sujet, mais est-ce que certain parmis vous, on dejà testé des classes, pour l'authentification :

je pense par exemple, au package Authentication de PEAR (que j'ai jamais test)

voilou, si vous pouvez dire ce que vous en pensez?

Quant à la solution de m@ elle me laisse ceptique (j'espere avoir bien capté).

si un mechant pas beau, réussi à décrypter les données qui circule entre le client et le serveur, en HTTPS. Meme si tu utilise ta méthode de cryptage, il recuperera CS et le message, donc pourra generer lui aussi le meme message chiffré que le client.
S'il n'arrive pas à décrypter les données circulant en HTTPS, il ne pourra de toute facon pas intercepter les paquet l'interessant, donc le cryptage CP/CS supplementaire n'est pas utile.

dis moi si jme gourre...

[m@]

koo >> un dernier mot sur ma méthode : CS voyage comme un mot de passe. mais il ne voyage qu'une seule fois, c'est l'intérêt de + le serveur est protégé d'un piratage. Sinon, de mémoire, PEAR a bonne réputation, mais je n'ai jamais testé, non plus.

cordialement

[doof]

Le spoofing consiste surtout a se faire passer pour une ip differente... Dans un systeme d'authentification crypté en ssl, je ne pense pas qu'il puisse servir a quelque chose.

Il est en outre quasi-impossible a réaliser, la recupération de données étant extrement plus difficile a réaliser que l'envoi, qui est lui-meme pas si simple... Si les paquets sont encryptés c'est d'autant plus difficile.

De plus, cela repose surtout une une porte ouverte par le protocole tcp/ip, on ne peut donc rien faire coté php et non plus au niveau de la couche http (donc le serveur).

Cette technique entre dans du tres haut vol, quasi légendaire je pense que les gens capables de l'exploiter sont extremement rares, de l'ordre de 1 pour 1 000 000.

Bon, ce que j'en dit, n'est évidement pas forcement la vérité, c'est surtout ce que j'en pense, mais ce que je veux dire, c'est que lutter contre le spoofing reviendraitr à changer entierement le protocole tcp/ip.

[m@]

je ne pense pas qe le spoofing soit si rare que ça.
il est hélas possible de trouver sur le web des tonnes de doc et de softs bien foutus, et je crains que ce soit accessible à n'importe qui de débrouillard et motivé.

je suis d'accord avec toi : fondamentalement, éradiquer le spoofing, c'est revoir les protocoles réseaux. mais à notre niveau, acheter un certificat nous protège parfaitement de ces attaques.

cordialement

[Sub0]

Merci à tous pour ces explications!
Je vais essayer de faire un petit résumé...
Je pars sur le principe que j'ai une connexion sécurisée (SSL).

1) Le visiteur accède au site: Je récupère toutes les infos possibles sur ce visiteur.
2) Le visiteur s'enregistre comme nouveau membre (ou se logge -> étape 5). J'ai ajouté un système de code aléatoire par image déformée pour éviter les inscriptions de robots.
3) Un mail lui est envoyé pour vérifier son adresse. Dans ce mail, un lien permet l'activation du compte.
4) A l'activation du compte, un password généré aléatoirement est donné au membre.
5) Le logg est protégé : Au bout de 3 tentatives échouées, le compte est bloqué pour 15 minutes.
6) Pour pouvoir se connecter automatiquement, j'utilise les sessions et un cookie (sid) avec une protection suplémentaire (comparaison des infos prélevées au début).
7) En cas de perte de mot de passe, un nouveau mot de passe généré aléatoirement est envoyé par mail, avec dans ce mail, un lien pour réactiver le compte. Tant que le compte n'est pas réactivé, l'ancien mot de passe reste valide.

Voilà en gros. Maintenant, j'espère que vous allez commenter...

Merci pour votre aide!

[Sub0]

Envoyé par m@

perso je trouve ça bien costaud !

Merci pour le compliment. Mais je crois qu'il faut pofiner encore...

Envoyé par m@

il faut bien que l'utilisateur puisse choisir d'être ou non authentifié par cookie et des risques que cela comporte.

Oui, c'est pas évident, il faut faire attention.
Je pense crypter le contenu du cookie avec md5. Il sagirait du SID.
Je fait une comparaison des infos prélevées pour confimer le propriétaire du SID.
Si cela ne correspond pas avec les dernières infos enregistrées, le membre devra s'identifier.
(Je peux aussi détecter les tentatives de vols de SID et bloquer l'IP... mais bon, pas nécessaire, non?)

Envoyé par m@

comment stockes-tu les mots de passe dans la bdd ?

Je stocke le mdp encodé, pour que l'admin puisse l'obtenir en clair (il me l'a demandé, pas le choix).
Il faut aussi que je mette au point un système sécurisé de générateur de mot de passe aléatoire,
pour que les membres puissent obtenir un nouveau mot de passe en cas de perte.

Envoyé par m@

as-tu un certificat ?

Pas pour le moment, hélas... Mais au final, on devrait avoir la totale, cad SSL + certif.

Merci de votre aide!