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

[m@]

channge aussi fréquemment de SID avec session_regenerate_id
quand au mot de passe il vaut mieux le donner à l'inscription, pas à l'activation : si j'intercepte un mail d'activation je peux avoir le mot de passe

cordialement

[Sub0]

Grâce à la cryptographie et la signature de l'email, ne pourrais-je pas tout simplement donner les identifiants dans le courrier éléctronique?
A votre aivs, quelles sont les contraintes?

http://ns4.telecharger.com/windows/U...ches/1384.html

Comme les identifiants de l'email ne concernent que le membre propriétaire, je pourrais proposer une option de cryptage de l'email au membre, et lui proposer le téléchargement de PGP. Le membre ne sera pas obligé de crypter son mail. Je lui laisse ainsi le choix. Je devrais pouvoir proposer un téléchargement pour les différentes plateformes existantes...

Qu'en pensez-vous? Merci de votre aide!!

[m@]

si tu peux crypter tes logins/mdp tu peux bien sûr les envoyer par mail, mais les crypter ça veut dire que ton client a (clé privée, clé publique), ou que tu lui en fournis.
si tu lui en fournis, par quel moyen lui fournis-tu ??

[Koo]

crypter les mails c'est bien, mais y faut que le client puisse les décrypter, et en général, il faut qu'ils utilisent un programme dédié.

Comme d'hab, il faut equilibrer sécurité et ergonomie. Si tu envoi tes mails cryptés avec PGP, une partie des clients ne ferons pas l'effort de le telecharger, à moins qu'ils aient vraiment besoin d'acceder au site.

[m@]

j'ai très rapidement parcouru tes liens, je ne suis pas sûr que tu aies compris l'utilité des signatures : si tu envoies (login, pswd) à un de tes visiteurs, la signature permettra de s'assurer que c'est bien toi qui les a envoyés, pas qu'ils ne seront pas interceptés.

quand au téléchargement de PGP, l'idée est très bonne, mais n'est-elle pas lourde à mettre en place, d'autant que pour l'utilisateur lambda, PGP n'est pas spécialement intuitif...

ne serait-il pas plus simple :
•à son inscription, l'utilisateur arrive sur une page récapitulatif où il trouve login/mdp. il peur enregistrer cette page, et on met des directives HTTP pour qu'elle ne reste pas en cache. cette transmission est sûre car via HTTPS
•il reçoit un mail destiné à vérifier son mail. un clic sur un lien du mail lui demande de s'authentifier pour la première fois

[m@]

je n'avais pas pensé à la perte de mot de passe, c'est vrai que ça semble plus délicat...

au pied levé, 2 solutions :

•à son enregistrement, l'utilisateur choisit une question dont il est le seul à connaître la réponse. si il perd son mot de passe, il doit répondre à la question sur une page HTTPS, et réobtient un nouveau mdp
•autre solution, s'il perd son mot de passe, une page web lui en fournit directement un nouveau, son compte est désactivé, et un mail d'activation lui est réenvoyé. à l'activation, il doit fournir le nouveau mdp, sinon, l'ancien est conservé.

tu remarques que l'on peut mélanger les deux solutions, ce qui semble plus efficace.

par ailleurs, j'insiste sur le fait de donner un nouveau mot de passe, même si tu as l'ancien en clair dans la bdd. ainsi s'il y a piratage, l'utilisateur normal se rend compt que son mot de passe a changé.
dans le même ordre d'idée, tu peux afficher la date et l'ip de dernière connexion sur ta page d'accueil.

enfin petite remarque sans rapport, dont on a déjà parlée mais qui a été trappée avec le temps, n'oublie pas que tu peux tester la solidité de tes pswd par crack dans PHP, et qu'il est bon de les faire changer par les utilisateurs de temps en temps, si ton site est vraiment critique

cordialement

[m@]

Envoyé par Sub0

Peut-être pas tout de suite désactiver le compte, sinon j'imagine quelqu'un désactivant facilement tous les comptes des autres membres.

exact. disons plutôt que l'ancien mot de passe reste seul valable tant que le 2ème n'a pas été activé par mail

Envoyé par Sub0

Je compte utiliser des mots de passe générés aléatoirement (chiffres et lettres minuscules). Je compte utiliser 8 caractères (voir 10 si nécessaire). Alors je me demande si cela vaut bien la peine de tester la solidité des mots de passe... Qu'en penses-tu?

non, en effet.
8 caractères, ça me semble bien, c'est ce que fait free par exemple.
par contre pour éviter que tes utilisateurs soient obligés de noter le pswd car il est impossible à retenir, tu peux générer des mots de passe prononçables (le principe c'est d'associer des syllabes plutôt que des caractères)

Envoyé par j0k3r_n0ir

Personnellement je ne me rappelle pas exactement l'heure et surtout mon ip lors de ma derniere connexion sur le forum (par exemple)....

moi non plus, mais je peux repérer un gros décalage, ou si j'ai une IP fixe je peux la reconnaître.

[Sub0]

Je suis partis sur le principe qu'un vol de SID est aléatoire. Selon moi, le pirate ne cherchera pas à voler une session en particulier, mais à obtenir au moins une session valide et à l'exploiter. Il se pourrait bien qu'en régénérant l'ID sans arrêt, on donne au pirate plus de possibilité d'accèder à un ID valide. Mais je faisais fausse route je pense finalement... De toute façon, le SID sera protégé avec la comparaison des infos de config du membre... Donc je crois que l'on peut énumérer ces attaques. Par exemple si quelqu'un réclame des sessions au hasard, cela se verra. Même si certains pirates arrivaient à fournir les bonnes infos de config, il faudrait déjà qu'ils soient enregistrés comme membre... (vraiment pas de bol dans ce cas). Si un membre réclame une session invalide, il sera redirigé sur le formulaire d'identification et si il ne s'identifie pas, ou que l'identification échoue, on peut ainsi reconnaître une attaque. Il faudrait un log des actions de chaque membre pour pouvoir analyser tout ça...
Qu'en pensez-vous?

Merci de votre aide!

[Sub0]

Envoyé par m@

à mon avis le log est nécessaire, à toi de voir ce que tu y mets.

Je vais y mettre un code pour chaque action et erreur afin de minimiser la taille des logs. Je vais concevoir mon propre code d'erreur, etc... Le log doit pouvoir me permettre d'analyser un membre, de savoir comment il se comporte, etc... Mais aussi pour le dépanner si il rencontre un problème, de savoir combien de fois il a changer son mot de passe, si il est bien présent sur le site, ou si c'est un membre fictif, etc... Je vais essayé de rester simple et clair dans mon développement afin de pouvoir vous en faire profiter sans difficultés.

Euh... à votre avis, quel support? bdd ou fichiers?

Envoyé par m@

quand à la réinvention de la roue, je suis traditionnellement contre...

Bah c'est un cas particulier, car beaucoups de webmasters ont déjà en place une sécurité minimale sur leur site, et n'ont pas besoin de plus de protection. Disons qu'on ne réinvente pas la roue, mais que nous la perfectionons selon nos besoins.

Très cordialement

[m@]

pour les logs, je verrais plus bdd pour pouvoir faire des recherches complexes facilement, après, je ne suis pas expert

[Sub0]

Salut!

La démo que je suis entrain de développer en ce moment est destinée à ne pas fonctionner sur un serveur sécurisé (dans un 1er temps). En effet, je recherche à sécuriser mon script avant de sécuriser la connexion. Voici le principe de fonctionnement (dans les grandes lignes):

A) L'inscription
A1) Remplir le formulaire (pseudo+mdp+mail)
A2) Test des champs de saisie
A3) Test si pseudo pas déjà pris
A4) Envoi du mail d'activation du compte
A5) Activation du compte (3 essais*)

B) La connexion
B1) Remplir le formulaire (pseudo+mdp)
B2) Test des champs de saisie
B3) Test d'ouverture du compte (3 essais*)
B4) Activation du compte si inactif
B5) Création d'une nouvelle session

C) La navigation
C1) Test de la durée de vie de la session
C2) Comparaison des SID et des IPs
C3) Sinon suppression de la session

D) La perte du mot de passe
D1) Remplir le formulaire (pseudo+mail)
D2) Test des champs de saisie
D3) Test correspondance pseudo avec mail
D4) Envoi du nouveau mot de passe par mail
D5) Réactivation du compte (3 essais*)
D6) -> B) Connexion

E) La déconnexion
E1) Suppression de la session

*: Au bout de 3 essais échoués, il faut attendre 30 minutes pour pouvoir débloquer le compte.
Un mail est envoyé à l'admin pour signaler le blocage du compte.

Le mot de passe est encrypté dans la bdd (RSA + grain de sel).
Je compte ajouter une image de code pour l'inscription (pour contrer les bots).

à+

[Sub0]

Envoyé par m@

1) que se passe-t-il si je rentre un mauvais mot de passe ?
2) si mon IP change ?
3) pourquoi y a-t-il des 3 essais pour activer le compte ?
4) y a-t-il des contraintes sur le mot de passe (robustesse, durée de vie...)

1) Message d'erreurs : Identifiants invalides! Il vous reste x essais...
2) Session invalide : Tu devras te réidentifier.
3) Si tu cherches à activer le compte autrement que par le lien qui ya dans le mail... (force-brute)
4) Le mot de passe est encrypté dans la bdd avec RSA. Un compteur de nouveau mot de passe, et la date d'enregistrement sont stockés dans la base de données. On peut ainsi réaliser une fonction pour déterminer l'âge du mot de passe et savoir combien de fois le membre l'a modifié. Suivant le choix de l'admin, qui décidera l'âge max d'un mdp et demandera aux membres d'en changer...

Envoyé par m@

sinon, je ne trouve que deux critiques à faire, mais elles restent mineures :
• B4 : j'aurais plutôt refuse la connexion sur un compte inactif
• D4 : peut-être qu'il faudrait que le mail est une durée de vie.

B4) C'est justement la connexion qui active le compte... (A5, B4, D5)
Le mail d'activation donne la permission de l'activation du compte à la connexion.
D4) Au final, le membre pourra modifier ces infos, comme sur le forum...
Il devra réactiver son compte (par mail) si il modifit son mdp ou son mail.

Je t'envoi le code dans la journée... ou demain au pire. à+

[Sub0]

Je pense avoir fait le plus gros...
Il reste quelques points à améliorer, en l'occurence:

• Eviter le blocage de comptes par des bots : Toutes les 1/2 heures, ils balancent 3 connexions foireuses... Si une connexion réussit par hasard, il s'approprie les informations du compte... C'est pour cette raison qu'un mail est envoyé à l'admin lorsque 3 échecs de connexions (ou d'activation) se suivent... Ce mail contient toutes les informations possibles sur l'attaque... L'IP du pirate peut-être ajoutée à une black-list par exemple. Si un compte est visé en particulier, avertir le membre de ces attaques, supprimer le compte, ou changer de pseudo... etc.

• Ajouter un cookie pour permettre la connexion automatique. Pas évident à sécuriser une telle fonction... Si vous avez des questions, commentaires suggestions, remarques ou idées à me proposer, je suis preneur!

Note: La démo n'intègre aucune fonction Javascript pour le moment. Rien que du PHP!

Merci de votre aide!

[m@]

quand tu bloques un compte, il faut surtout bloquer l'IP qui a tenté de se connecter, et puis tu n'es pas obligé d'attendre une demi heure : tu peux doubler le temps d'attente à chaque connexion

pour le cookie, l'essentiel est d'informer l'utilisateur des risques, si son ordinateur est utilisable par d'autres. après il n'y a pas grand chose à faire, si ce n'est donner une durée de vie au cookie, n'y stocker qu'un identifiant sufisament robuste que l'on change à chaque connexion, et bloquer également les comptes et les IPs qui tentent de se connecter avec un mauvais cookie (-> les bloquer du premier coup : un naviagteur ne se trompe pas pour envoyer un cookie)

[mathieu]

je continue ma discution au sujet de la détection de l'envoi d'un cookie par un pirate dans le but de voler une session

j'ai presque lu toute la doc PHP au sujet des sessions et en conclusion je n'ai trouvé aucun moyen de détecter la différence entre une session qui vient de commencer (ou l'accès avec un cookie d'une session expirée) et l'accès par un pirate avec un SID "maison" afin de voler une session
je parle bien sur du cas où le SID du pirate n'est pas valide, puisque dans le cas d'un SID existant, la signature du navigateur ainsi que l'adresse IP peuvent détecter le pirate (dans la grande majorité des cas)

[Sub0]

Merci Mathix de poursuivre le topic dans le bon sens!
Dans un espace membre, les cookies sont un réel problème de sécurité. D'ailleurs, "mon client" me permet de ne pas ajouter cette fonction (connexion automatique) si cela pose vraiment problème! Même en SSL, il ya moyen de pirater une session via les cookies? Je n'utilise aucune fonction JS pour le moment, mais je possède (grâce aux recherches du topic), quelques bonnes lib d'encryptage (rsa, md5, sha1, rc4, ...). Peut-être qu'il serait possible d'utiliser ces libs pour trouver une solution... Autrement, puis-je stocker les cookies sur le serveur, et les lier au client par autre chose de moins "dangereux"... ou transmettre une clé à l'inscription qui serait sauver sur le pc du client, et l'utiliser pour décrypter le sid contenu dans le cookie... En fait, j'essaye de vous proposer des idées, mais j'ai encore du mal à bien cerner le problème...

Merci de votre aide!

[mathieu]

Envoyé par Sub0

Autrement, puis-je stocker les cookies sur le serveur, et les lier au client par autre chose de moins "dangereux"... j'essaye de proposer des idées, mais j'ai encore un peu de mal à bien cerner le problème. D'ailleurs, pouvez-vous me rappeller très brievement pourquoi le cookie est dangereux?

c'est le fait de déposer le cookie chez le client qui rend le cookie dangeureux donc ca ne sert à rien de le remplacer par quelque chose d'autre
il faut toujours donner le moins de chose possible au client pour éviter qu'il ne sacage tout et là avec le SID dans le cookie c'est bien le minimum d'informations donc c'est une bonne base

le danger peut venir d'un pirate qui se procure un SID, il peut y arriver de plusieurs façons :
- chez le client : il s'assoit à un ordi qui est logué et à moins de tomber sur un système qui demande la mot de passe à chaque opération il se promène comme il veux mais ce genre d'attaque n'est pas fréquent
- sur le réseaux : un petit sniffer et s'il se trouve entre le client et le serveur c'est gagné pour lui. la solution : utiliser SSL et le sniffer ne sert plus à rien
- il devine un SID : là il est fort le gars mais c'est pas impossible. pour rendre cela plus difficile il y a une option depuis PHP 5.0 qui permet d'utiliser SHA1 au lieu de MD5 ce qui produit un SID beaucoup plus grand

[mathieu]

autre sujet : la détection du naviagteur

hier soir j'ai mis en place mon système d'indentification pour faire mes premier tests en grandeur nature et ce matin en regardant les logs j'ai failli m'arracher les cheveux à cause d'IE

ce que je fais pour détecter le navigateur c'est regarder dans $_SERVER les valeurs 'HTTP_ACCEPT', 'HTTP_ACCEPT_ENCODING', 'HTTP_ACCEPT_LANGUAGE' et 'HTTP_USER_AGENT'. et ce qui ce passe c'est que IE retourne 2 valeurs possibles pour HTTP_ACCEPT_ENCODING par exemple c'est soit "*/*" soit "image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, */*"
résultat : les membres qui utilisent IE se font déloguer à tour de bras ! donc j'ai oté cette valeur de la liste à vérifier, ce n'est pas un enorme problème mais ca fait une petite perte de sécurité quand même

[m@]

au niveau des cookies, comme le dit mathix ce qui est dangereux, c'est que d'une façon ou d'une autre un pirate choppe un cookie et le mette sur son ordinateur

par contre, je pense que nous ne parlons pas du même cookie :
+ premier cookie : stocké directement par PHP pour gérer les sessions, et effacé à la déconnexion
+ deuxième cookie : (celui dont je parle) stocké par le script pour permettre une connexion automatique

ce cookie contient un couple (login, identifiant) stocké dans la bdd. à chaque connexion on change l'identifiant et on lui donne une durée de vie. si l'identifiant est mauvais : le compte est bloqué directement
si l'identifiant est trop vieux (cad que normalement le navigateur aurait du effacer le cookie) on redemande l'authentification, et on note ça au cas où

mathix >> pourquoi identifier le navigateur ?

[Sub0]

Salut!

J'ai commencé le développement de l'espace membre (après 1 mois d'étude!).
Ce programme me servira de base pour la suite...

http://espm.gotdns.org/inscript.php

J'ai aussi commencé à écrire une doc sur le projet:
http://espm.gotdns.org/doc/doc.htm

Restera à ajouter toute la sécurité dont nous avons parlé...

Merci de votre aide! à+