empêcher de se logger 2x en même te mps avec 2 adresses IP

Salut tout l’monde,

Sur un projet avec système d’authentification d’utilisateur (en
utilisant le SaltedHashLoginGenerator qui définit un utilisateur en
session), je souhaiterais qu’il ne soit pas possible de se logger 2x en
même temps avec 2 adresses IP différentes.

À priori, je rajoute un champ ‘ip’ dans ma table ‘users’ et j’enregistre
l’IP de l’utilisateur quand il se logge. Et j’enlève l’IP quand il se
délogge, et voilà . Je n’ai plus qu’à comparer la valeur du champ ‘ip’ et
l’IP de l’utilisateur qui se “double-logge” pour voir si je l’autorise
ou pas.

Mais comment faire si l’utilisateur quitte le site sans se délogger?
J’aurai toujours une valeur dans le champ ‘ip’, il faudrait la retirer
après un laps de temps. Avec la session?

Bon appétit à tous,

Michael

Mais comment faire si l’utilisateur quitte le site sans se délogger?

en général les sessions ont un ‘timeout’. en effet, je me délogue jamais des
sites et pourtant je remets mon mot de passe à chaque fois (-:

a chaque fois que tu verifie si la session est bonne, tu vérifie l’IP ET
la date
de dernière mise à jour de la session (donc rafraichissement d’une date
à chaque
acces de page)

gUI

Guillaume B. a écrit :

Merci pour ta réponse, Guillaume. Ca m’a permis d’avancer sur cette
partie de mon appli.

J’ai mis ce système en place, mais en n’utilisant pas la date
d’expiration de la session. Dans un souci de sécurité, j’ai préféré
ajouter 2 champs dans ma table ‘users’: ‘latest_access_at’ et
‘latest_access_ip’. Je mets ces champs à jour à chaque accès.

Ensuite je fais un simple test lorsqu’un utilisateur essaie de se
logger. Je refuse l’accès à la condition que:

* l'IP du visiteur != IP enregistrée en DB
* le dernier accès enregistré en DB date d'il y a moins d'une heure

Mais je coince sur un truc… Si le visiteur se logge puis ferme son
navigateur, puis que dans la même heure, il tente de se connecter depuis
un ordinateur connecté sur un autre réseau (une autre IP), mon appli va
lui refuser l’accès. Que puis-je faire pour résoudre ce problème?

Bon appétit à tous,

Michael

Le 31/01/07, Michael H. a écrit :

Mais je coince sur un truc… Si le visiteur se logge puis ferme son
navigateur, puis que dans la même heure, il tente de se connecter depuis
un ordinateur connecté sur un autre réseau (une autre IP), mon appli va
lui refuser l’accès. Que puis-je faire pour résoudre ce problème?

Il n’y a pas de solution. A ta place je stockerais l’identifiant de
session
du user en base, et si quand le user se connecte son id session est
différent de celui en base, soit tu lui fourni l’ancienne session,
soit tu
effaces l’ancienne session.

Que puis-je faire pour résoudre ce problème?

je comprends pas… je trouve tout à fait normal qu’on lui redemande le
mot de
passe si il change d’ordi ! c’est justement le but du log d’IP !!!

gUI

C’est mal, très mal.

bin le soucis c’est que en général c’est mis en place pour éviter je sais
plus
quelle technique de piratage (piquage des infos de session, et prise de
controle
de la session)…

gUI

Le Mer 31 janvier 2007 11:30, Michael H. a écrit :

a chaque fois que tu verifie si la session est bonne, tu vérifie l’IP ET
la date de dernière mise à jour de la session (donc rafraichissement
'une date à chaque acces de page)

* l'IP du visiteur != IP enregistrée en DB
* le dernier accès enregistré en DB date d'il y a moins d'une heure

C’est mal, très mal.
Il ne faut jamais vérifier l’ip dans les sessions. La problématique de
base c’est que pas mal de très grosses entreprises ont plusieurs proxys en
alternance. C’est par exemple au moins le cas de Frante Telecom R&D et
du
Groupe Moniteur (édition / travaux publics).
Dans ces cas là deux requêtes du même utilisateur, dans le même
navigateur, à deux minutes d’intervalle peuvent tout à fait venir de deux
proxy différents, donc deux IP, et même potentiellement (au moins dans le
cas de FT) de deux sous réseaux différents. On ne peut donc pas qualifier
l’IP ou même la classe d’IP comme discriminant.
Si vous le faites, vous arrivez à une situation que j’ai vécu plusieurs
fois et qui est d’un pénible sans nom : certains de vos utilisateurs sont
déconnectés en permanence et finissent pas simplement ne plus venir.


Éric Daspet
http://eric.daspet.name/

Le 31 janv. 07 à 11:51, Eric D. a écrit :

C’est mal, très mal.

Tout n’est pas noir ou blanc, le binding d’une session à une ip est
une alternative à faible cout plutôt efficiente contre le vol de
session / cookie.

C’est clair que ce n’est pas parfait dans le cas d’un site grand
public à fort traffic avec identification utilisateur mais est-ce
pire qu’un site full js, ou sans support de win98, ou …

Ca fait parti d’un choix qui a des conséquences dans certains cas
particulier mais qui n’est pas idiot en soit. Ca reste rare les proxy
qui anonymise complètement l’utilisateur (et rarement bon signe). En
plus si on est soigneux en général on a l’ip forwardé dans les
entêtes et on peut toujours passer en mode sans binding quand ce
genre d’utilisateur se log, ou même binder sur l’ip forwardé. Une
autre alternative plus simple est de loger l’utilisateur pour chaque
ip de demander à l’utilisateur de se logguer à chaque fois qu’il
change d’ip sans pour autant perdre l’authentification sur les autres
ips car dans les fait on est rarement load balancé sur plus de 2 ou 3
proxy.

Bref ce n’est pas TRES mal surtout à l’heure ou n’importe qui rajoute
n’importe quel widget js sur son site, les sessions n’ont jamais été
aussi en péril que dans le web actuel. Maintenant c’est clair que ca
n’a de sens que dans un environnement qui le mérite, pas pour un
système de bookmark par exemple.

Ce qui est bizarre dans le cas proposé c’est qu’ici on ne parle pas
de binding de session mais de binding d’utilisateur à une ip et la
franchement ca me parait un peu tordu, surtout si c’est fait sous
forme de LOCK. La preuve ce qui est demandé c’est comment je fais
pour contourner le système que je viens de mettre en place :slight_smile:

Si tu veux éviter le vol de session je te propose cette solution qui
n’utilise pas l’ip. Je ne l’ai encore jamais mise en place mais j’ai
déjà fait qqch de similaire pour protéger l’envoi de mot de passe sans
https.

Tu peux stocker une valeur dans un cookie qui répond aux critères suivant:

  • Varier à chaque requête
  • Dépendre d’une données que seul l’utilisateur connaît (mot de passe
    par exemple)
  • Elle doit être calculée aussi bien du côté client que serveur pour
    être transmise qu’une seule fois entre le client et le serveur

Le calcule peut se faire avec un jeu de somme de hachage.

Dans le cas où la valeur du cookie est différente de la valeur
calculée côté serveur alors on refuse l’accès.

Mais peut-être qu’il existe qqch de déjà tout prêt dans ROR pour ça :slight_smile:

Alexis

Le 31/01/07, Guillaume
Betous[email protected] a écrit :

Le Mer 31 janvier 2007 13:05, Renaud Morvan a écrit :

Tout n’est pas noir ou blanc, le binding d’une session à une ip est
une alternative à faible cout plutôt efficiente contre le vol de
session / cookie.

Oui, c’est une (demi) solution au vol de session et un (quart de)
paliatif
à la fixation de session. Mais la problématique à éviter c’est le vol de
l’identifiant de session, pas le “comment est-ce que je peux faire pour
éviter qu’il utilise un identifiant de session qu’il a volé”.

Disons que pour avoir souvent souffert de la chose pour des applis mal
concues, je peux vous dire que c’est franchement un problème bloquant
quand les sessions sont codées ainsi.

En plus si on est soigneux en général on a l’ip forwardé dans les
entêtes et on peut toujours passer en mode sans binding quand ce
genre d’utilisateur se log, ou même binder sur l’ip forwardé.

Ah non ! surtout pas. Pour le coup ça reviendrait quasiment à ne faire
aucune vérification. Injecter manuellement une entête X-FORWAREDED-FOR
çame prend quelques secondes, deux minutes à tout casser. Si tu fais ton
check là dessus ça veut dire que ton méchant aura juste à ajouter une
entête pour faire croire qu’il passe par un proxy pour accéder à la
session.

Bref ce n’est pas TRES mal surtout à l’heure ou n’importe qui rajoute
n’importe quel widget js sur son site, les sessions n’ont jamais été
aussi en péril que dans le web actuel.

Franchement, si un tiers que tu ne contrôle pas peut insérer du js sur ta
page, tu as bien plus gênant que les problèmes de session. Celui qui
contrôle le js peut directement te faire agir comme il l’entend, il n’a
pas besoin de te voler ta session et de te l’exploiter à côté.

Les sessions, pour aller rapidement il y a quatre moyens courants de les
voler :
1- y aller à l’aveugle et trouver/prédire un n° de session existant
2- trouver l’id de session dans l’url de ses referer
3- un pb coté client (poste infecté, réseau local écouté, etc.)
4- avoir une faille XSS sur l’appli

Les deux premiers avec un minimum de travail on les écarte et on les
oublie. Le troisième c’est de la responsabilité du client et de toutes
façons s’il en est là on peut contrôler ce qu’il envoit sans même avoir
besoin de son id de session.

Reste le dernier, mais avec les xmlhttprequest qui se développent on peut
le plus souvent là aussi faire faire directement les manipulations qu’on
veut sans passer par le vol de l’identifiant de session. Le problème n’est
plus tellement au niveau de la vérification ip de l’utilisateur de la
session.

Bref, franchement la sécurité en plus, elle est majoritairement virtuelle.
Ca ne veut pas dire qu’elle est inutile, mais elle couvre des cas
suffisament restreints pour être négligeable si les points bloquants sont
concrets (ce qui est le cas ici).

C’est clair que ce n’est pas parfait dans le cas d’un site grand
public à fort traffic avec identification utilisateur mais est-ce
pire qu’un site full js, ou sans support de win98, ou …

Maintenant c’est clair que ca n’a de sens que dans un environnement qui
le mérite, pas pour un système de bookmark par exemple.

A la limite ça me parait pire qu’un site en full js ou sans support de
win98, oui. Parce que ça filtre une catégorie de personnes importante (en
qualité et en quantité).

Le problème c’est la définition du “environnement qui le mérite”. La
distinction ne peux pas se faire avec simplement un “application qui
mérite une grande sécurité et qui est complexe”. Moi je préfère me voir
refuser l’accès à un système de bookmark qu’au site de ma banque. Du coup
la comparaison d’ip stricte je l’accepte sur le site de bookmark mais
pas
sur l’appli bancaire.

Une autre alternative plus simple est de loger l’utilisateur pour chaque
ip de demander à l’utilisateur de se logguer à chaque fois qu’il
change d’ip sans pour autant perdre l’authentification sur les autres
ips car dans les fait on est rarement load balancé sur plus de 2 ou 3
proxy.

Ca c’est une bonne solution, je l’avoue, et en plus elle ne coûte pas
trèscher. Malheureusement franchement je ne l’ai jamais vu mise en oeuvre.


Éric Daspet
http://eric.daspet.name/

Salut Michael,

dans ton contexte, quelles sont les motivations pour vouloir éviter un
double-login ?

Ex: tu veux éviter les doubles-logins parce que l’appli ne se
comporterait
pas bien en cas d’utilisation concurrente ? Ou bien tu souhaites éviter
les
attaques de cross-site-scripting ? ou encore autre chose ?

Thibaut

Si quelqu’un se logge 1000x et propose
1000 galeries en même temps, j’imagine que ça va être un peu foireux.

je comprends pas trop… pas besoin de se connecter 2 fois pour ouvrir 2
browsers et envoyer simultanément 2 requetes !!!

gUI

Thibaut Barrère a écrit :

Thibaut
Tout d’abord, merci pour vos participations. Personnellement j’en
apprends beaucoup.

À la base, je souhaite faire ceci pour éviter:

* que des codes d'accès au site soient partagés via le web
* pour éviter que quelqu'un "robotise" l'accès au site

La principale fonctionnalité côté utilisateur du site est la soumission
de galeries de photos/vidéos. Si quelqu’un se logge 1000x et propose
1000 galeries en même temps, j’imagine que ça va être un peu foireux.
Réduire l’accès à une IP à la fois est un premier pas.

Concernant l’utilisation de proxy, quand je fais mon test pour vérifier
si l’accès est autorisé, je vérifie d’abord si une session est en cours.
Si c’est le cas, l’accès est de toute façon autorisé, sans vérification
de l’IP. Donc l’utilisation de proxy n’est pas un problème. Par contre
s’il y a vol de session, là il y a un problème.

Michael

je comprends pas trop… pas besoin de se connecter 2 fois pour ouvrir 2
browsers et envoyer simultanément 2 requetes !!!

ou plus précisément : pas besoin de se connecter 2 fois pour ouvrir 2
fenetres
dans un meme browser.

gUI

Guillaume B. a écrit :

Si quelqu’un se logge 1000x et propose
1000 galeries en même temps, j’imagine que ça va être un peu foireux.

je comprends pas trop… pas besoin de se connecter 2 fois pour ouvrir 2
browsers et envoyer simultanément 2 requetes !!!

gUI
Oui effectivement. Donc dans un deuxième temps, je mets en place une
restriction du nombre d’envoi de galeries (1 seul envoi possible à la
fois). Mais l’interdiction d’accès simultané avec vérification IP permet
au moins - un peu - d’éviter le partage de login entre plusieurs
personnes, et donc cette fonctionnalité garde mon intérêt.

Michael

Le 31/01/07, Guillaume B.
[email protected]
a écrit :

je comprends pas trop… pas besoin de se connecter 2 fois pour ouvrir 2
browsers et envoyer simultanément 2 requetes !!!

ou plus précisément : pas besoin de se connecter 2 fois pour ouvrir 2
fenetres
dans un meme browser.

Ni même besoin de browser, avec un simple script Ruby tu peux
automatiser la
chose.
Mauvaise solution.

Oui effectivement. Donc dans un deuxième temps, je mets en place une
restriction du nombre d’envoi de galeries (1 seul envoi possible à la
fois).

je ne sais pas quelles sont tes contraintes, mais j’ai un peu
l’impression que
tu te casses la tete pour pas grand chose. déjà pense que si je veux
pourrir ton
site envoyant 1000 requetes simultanées, j’ai interet à avoir une belle
connexion Internet, meilleure que celle de ton serveur.

mais si tu limites à 1 envoi simultané par compte (simple flag a mettre dans
la
DB) ca devrait résoudre ton pb non ? si le gars a envie d’ouvrir 12
sessions
laisse-le faire, il en fera rien…

gUI

Le Mer 31 janvier 2007 14:33, Michael H. a écrit :

À la base, je souhaite faire ceci pour éviter:

* que des codes d'accès au site soient partagés via le web

Ces deux problématiques ne vont pas être faciles à tracer. En général on
fait le tri à partir de statistiques traitées en batch et pas avec des
contrôle en temps réel.

Pour le partage des codes d’accès tu peux stocker les IP (publique et
forwardées) et les identifiants de navigateur. Si tu dépasses un certain
nombre d’IP dans un certain temps, tu peux considérer le compte “à
vérifier”. Même chose si tu vois trop d’identifiants de navigateur
différents.

Exemple, tu prend deux listes :

  • la première classe tous les comptes par le nombre maximum d’IP que tu as
    vu par période de 30 minutes (choix arbitraire mais ne dépasse pas 1h si
    tu ne veux pas avoir trop de faux positif). Le plus grand nombre est en
    premier.
  • la seconde classe tous les comptes par nombre maximum d’identifiant
    navigateur vu au cours d’une journée (ici encore c’est arbitraire,
    j’éviterai de dépasser la semaine). Le plus grand nombre est en premier.

Tu peux mettre des paliers automatiques qui vont désactiver les comptes
quand ça passe des valeurs extrèmes (genre plus de 5 IP en 30 minutes ou
plus de 10 navigateurs en 2 jours) et des vérifications manuelles
régulières où tu regardes les plus hautes valeurs des listes voir ce
qu’ils ont fait et s’ils ne reviennent pas trop souvent.

Le problème majeur c’est que tu vas avoir toutes les peines du mondes à
tracer de manière automatique celui qui partage son compte avec une ou
deux personnes seulement (voisin, frère, soeur). Tu as toutes les chances
de devoir faire du manuel là dessus.
C’est encore plus vrai si tu comptes qu’à un moment où un autre tu vas
tomber sur un mari qui utilise le compte de sa femme ou l’inverse (donc
qui peut exceptionnellement compter comme deux utilisateurs alors qu’ils
sont à peu près légitimes même si border line).

Le second problème c’est que tu ne vas pouvoir exclure que les bornes
extremes. Si tu ne veux pas de faux positifs importants et que tu veux
vraiment disqualifier tous les partages de comptes, il va falloir que tu
y
ailles avec des vérifications manuelles sur les cas intermédiaire (ceux “à
surveiller” mais qui sont trop bas pour les désactiver “de principe”).

* pour éviter que quelqu'un "robotise" l'accès au site

Là à part faire de bêtes stats par compte et par IP en mettant des paliers
maxi, tu ne vas pas pouvoir faire grand chose. Tu peux mettre des
paliers
maxi par période de 2 minutes (si tu as plus de 60 soumissions en 2
minutes tu peux disqualifier d’office) et des paliers plus cool sur des
périodes plus longues (genre 500 soumission par semaine).

Tu tomberas toutefois dans la même problématique que plus haut : définir
tes palier et prendre en compte la personne non robotisée qui de bonne foi
va vouloir mettre d’un coup 50 vidéos et qui a préparé des
noms/répertoires sur son disque pour aller très vite. Le seul avantage
c’est qu’ici ils accepteront probablement d’avoir des messages “trop de
soumissions en peu de temps, revenez demain”. C’est assez courant.

Reste aussi, que là aussi, quelqu’un qui s’y prend bien, qui étale ses
contributions dans le temps, sera dûr voir impossible à repérer de manière
automatique.


Éric Daspet
http://eric.daspet.name/

Reste aussi, que là aussi, quelqu’un qui s’y prend bien, qui étale ses
contributions dans le temps, sera dûr voir impossible à repérer de manière
automatique.

… ou si c’est la mafia Russe, elle va utiliser les qques milliers
(millions ?)
d’ordis zombis qu’elle “possede” sur Internet (((-:

gUI

mais si tu limites à 1 envoi simultané par compte

… et meme 1 session simultanée par compte ! si il en ouvre une 2e (lui
ou
qqu’un a qui il aura filé login/passw) la premiere sera déconnectée. bref,
rien
n’empeche de partager login/passwd, mais c’est inutilisable simultanément,
et
très pénible.

gUI

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs