Sécurité cookie : mon idée !

[michel.leonard]

Salut chers WRInautes, je vous présente mon stratagème pour protéger au mieux un cookie, évidemment le procédé comme toute solution programmée n'est pas inviolable ..
Si le visiteur a ouvert 2 pages ou plus sur le site à 30 minutes d'intervalle et que la même ip à été détectée alors on peut considérer son ip comme semi-fixe. Si l'ip est semi fixe elle est intégrée dans le cookie sous forme de hash...

Voilà, si un visiteur dispose d'une ip "semi fixe" et qu'il a passé plus de 30 min sur le site, aucune autre adresse ip ne peut prétendre voler le cookie... C'est déjà pas mal non ?

 

[_Soul]

Https.

Tu peux pas éviter le vol de session sinon.

 

[Leonick]

Voilà, si un visiteur dispose d'une ip "semi fixe" et qu'il a passé plus de 30 min sur le site, aucune autre adresse ip ne peut prétendre voler le cookie... C'est déjà pas mal non ?

et si le visiteur vient via les réseaux mobiles, des milliers d'autres internautes ont la même adresse ip publique :wink:

 

[spout]

Un article qui date un peu mais tjs intéressant: http://shiflett.org/articles/the-truth-about-sessions

 

[michel.leonard]

il est possible de hacker cette minorité d'utilisateurs mobile, mais la majorité est sécurisée... comme je l'ai précisé ça n'est pas infaillible

 

[zeb]

Tu fait dans le domaine de la banque ou t'a juste du temps a perdre ?

 

[Leonick]

aux mobiles, tu ajoutes les abonnées AOL, les utilisateurs de réseaux d'entreprises, qui n'auront qu'une seule ip publique et, en plus, beaucoup de postes avec exactement les mêmes UA, vu que les postes sont clonés.
Donc au niveau sécurité, pas vraiment convainquant. déjà, passe en https

 

[michel.leonard]

disons que pour un site d'annonces en ligne plus de 60% des utilisateurs devraient avoir une ip "quasi unique" c'est a dire à la maison chez eux. C'est déjà une première protection rassurante et sympa que de savoir que si on se connecte de chez soi, le système est "quasi inviolable".

 

[Leonick]

donc en clair, l'essentiel de tes connexions est effectuée à partir de 19h, tu n'en as quasi aucune en journée ?

 

[michel.leonard]

je ne dis pas cela mais je dis que si un utilisateur souhaite maximiser la sécurité de sa connexion il peut se connecter a partir de son poste personnel, sinon, il peut parcourir les annonces du site, mais de préférence, ne doit pas se loguer , ou peut le faire a ses risques et périls... j'envisage également le fait que l'utilisateur qui souhaiterai tout de même se connecter sur un poste public reçoive un cookie a utilisation limitée pour une durée de 27 minutes pour interagir sur le site durant ce court laps de temps. (certes suffisant a un hacker pour manipuler le compte du client)

 

[sonn]

MITM => down

 

[zeb]

Et tu ne t'est jamais dit qu'un gars capable de renifler un cookies a la volée (ou de le lire sur une autre machine) pour le reproduire était aussi capable d'utiliser l'IP du gars qui c'est fait prendre le cookies pour surfer pépère sur ton site ?
Tu est en train de mettre en œuvre un coffre fort en laissant la clé sur la porte.

 

[michel.leonard]

oui c'est possible, mais contre ça je ne vois pas bien quelle parade programmable est possible... Tout comme si le hacker vient menacer l'utilisateur chez lui avec une arme afin de lui voler son compte, je n'ai pas la solution non plus...

 

[_Soul]

Aller une petite expérience, ta 2 pc chez toi?

Télécharge http://www.wireshark.org/, installe le sur un pc. Lance une capture.

Va depuis un autre pc sur ton site, ouvre tes yeux sur wireshark et regarde tes données passer en clair. J'en dirais pas plus, mets un certificat ssl.

 

[michel.leonard]

j'ai déja essayé ça... je connais un peu ce prog, effectivement, mais pourquoi WRI n'est pas en https ?

 

[Leonick]

j'ai déja essayé ça... je connais un peu ce prog, effectivement, mais pourquoi WRI n'est pas en https ?

peut-être parce qu'il n'y a pas d'intérêt à sécuriser autant du fait qu'aucune informations n'est réellement "intéressante" pour un voleur. Sur un abri de jardin trouverais-tu nécessaire de mettre une porte blindée et une alarme, alors que tu n'aurais qu'une brouette et une fourche à protéger ??

 

[zeb]

oui c'est possible, mais contre ça je ne vois pas bien quelle parade programmable est possible...

Simplement mis a part passer sur un protocole sécurisé qui cryptera l'échange et qui provoquera que tes trames seront incompréhensibles (sans les moyens de la Nasa) Toute personne qui analysera les trames passera outre ton idée et pourra interagir avec le site sans difficulté. Les autres (qui sont incapables de renifler entre autre) seront de toute façon incapables de faire quoi que ce soit même sans ton dispositif. D'où l’inutilité du concept.

Tout comme si le hacker vient menacer l'utilisateur chez lui avec une arme afin de lui voler son compte, je n'ai pas la solution non plus...

Et puis aussi (avant même de chercher a violer un cookies) pense deux minute que sans Https, je vais attendre gentiment en écoutant que ton utilisateur passe sur la passe login... Et là ho miracle ! j'aurais son password sans me prendre la tête (pas la peine de sortir les armes). j'attendrai quelques temps qu'il aille jouer ailleurs et je me connecterai sans même chercher a me cacher.

Ensuite il faut te dire que la sécurité est a aborder sous l'angle du maillon faible. Sur le web ce maillon n'est pas le système mais l'utilisateur. Hors ton idée ne donne rien de plus a ce niveau.

mais pourquoi WRI n'est pas en https ?

pour protéger quoi ?

 

[michel.leonard]

merci pour vos belles réponses, c'est sympa de votre part.

pour protéger quoi ?

- le compte admin et les comptes modérateurs.
- vos beaux petits comptes avec parfois plusieurs milliers de messages.

Donc théoriquement, cher zeb, je peux te voler ton compte ? Je ne vais pas le faire mais dans l'absolu c'est facilement faisable ?

 

[zeb]

Donc théoriquement, cher zeb, je peux te voler ton compte ? Je ne vais pas le faire mais dans l'absolu c'est facilement faisable ?

Et bien si tu te met en position de pouvoir écouter le trafic oui tu peut très bien intercepter toutes les informations de login que tu veux (si c'est pas du protocole sécurisé) et en faire ce que tu veux. Pour cela il y a différentes techniques, les vieux réseaux d'entreprise sur des hubs sont un exemple de fragilité a ce sujet. les célèbres chevaux de Troie sont un autre moyen d'écouter (pas directement), les réseaux sans fils sont aussi vulnérables car les ondes n'ont pas trop de frontière etc ... De plus piéger quelqu’un se révèle pas si compliqué que cela vu la culture moyenne de l'utilisateur Windows (je dis pas ça "contre crosoft" c'est juste que la banalisation qu'il a engendré a mis de très bon outils a la porté des malveillant).

Après ton système est vulnérable ne serais ce même si le cookies est lisible (et il l'est puisqu'il "voyage") puisque il suffira de forger des requêtes avec l'IP de l'utilisateur pour écouter la réponse serveur même si elle ne t'est pas destinée.

Le truc que j'essaie de te dire c'est qu'une personne avec la compétence passera facilement outre cette astuce (ça va juste le faire chier) alors que celui qui n'a pas la compétence ne rentrera pas de toute façon astuce ou pas (tant que tu reste sur un protocole pas sécurisé).

Après pour avoir un compte important, il est bien plus rentable de s'attaquer au serveur quand on connais un peu sa structure plutôt que d'essayer de "pister" l'admin (a moins que ce soit ton voisin et qu'il soit fan de wifi ).

 

[michel.leonard]

PS : mon site est un genre de leboncoin, façon youtube avec une chaîne propre a chaque user... donc voila c'est pas la NASA non plus...

 

[michel.leonard]

et encore, la NASA c'est pas le FBI ... :lol:

 

[michel.leonard]

et au fait le password n'est pas envoyé en clair mais il est hashé et salté par js convenablement en ajoutant une constante de temps "imprévisible" , donc si tu écoutes , tu vois des hash transiter... mais impossible de les réutiliser...

 

[Leonick]

donc si tu écoutes , tu vois des hash transiter... mais impossible de les réutiliser...

euh, ben si : en fait le password on s'en fou dans ce cas, ce qui nous intéresse c'est juste les valeurs qui transitent entre le navigateur et le serveur. Donc tu fais ce que tu veux avant, la technique MITM récupère ton hash et s'en ressert ensuite.
En plus, sécuriser une appli avec js 8O :roll: :lol:
tu veux sécuriser ton interface ? https + htpasswd et ça roule :wink:

 

[michel.leonard]

dis moi ou est la faille:

la page du site est : znEWa68.com/login-12uxG.htm
le fameux 12uxG est un ID unique valable 1 minute.
L'user se logue, je concatène Password+Salt+ID+Username , le md5 (js) du tout est envoyé au serveur.
L'id n'est plus utilisable (restriction coté serveur).
Le serveur envoie un script JS au client lui permettant de générer un cookie une seule fois avec son ID.
Le serveur vérifie si c'est bien la première fois que le cookie est généré a partir de cet algorithme unique.
Si c'est bien le cas le serveur envoie un cookie de contrôle en clair.
Si l'utilisateur dispose du bon cookie de contrôle, et que JS à généré le bon cookie unique, l'utilisateur est authentique.
Si l'utilisateur n'est pas compatible JS , qu'il aille sur leboncoin :lol:

Ou est l'erreur ? Je suis pourtant persuadé qu'il y en a une...

 

[Leonick]

c'est quoi le but de se prendre la tête comme ça ? alors qu'avec https + htpasswd tu aurais, bien plus facilement, une sécurisation de la connexion ?

 

[michel.leonard]

dites moi, ya quelque chose de spécial pour travailler avec https , ca y est mon site https est accessible... et maintenant alors je peut faire SETCOOKIE en php et les infos qui transitent sont indéchifrables ?

 

[sonn]

passer les cookies en mode "https uniquement"