Moogli, tu me conseille l'user agent plutôt que l'IP ducoup ?

l'ip c'est pas toujours une bonne idée, ce n'est pas fiable et surtout pas unique (proxy par exemple fournie une ip pour x personne, une déconnexion internet peux faire que l'on change d'ip ensuite et pourtant c'est la même personne ).


@+

Je pense que ce qu'il veut dire c'est pourquoi dans ton cookie tu ne met pas un truc du genre :
20_e253f2352c1853

20 : Utilisateur 20
e253f2352c1853 : Ce qui est crypté

En plus de l'user agent tu peux ajouter l'IP de la personne, ca evite de piquer un cookie sur le pc (ou par snif) et de l'utiliser sur un autre PC.

Moi de mon coté je ne comprend pas l’intérêt de la table, je pense que tu peux faire un super algo pour générer ce "e253f2352c1853" et le vérifier coté serveur + expiration normale du cookie. Si tu fais un md5 de l'id concaténé à l'ip, concaténé à l'user agent, concaténé au mot de passe, déjà... c'est costaud.

Après je ne te garanti pas que c'est la meilleure méthode, mais c'est celle que j'utilise... si tu as des infos sur la sécu je suis preneur.

Bonne continuation.

[i]"identifiant utilisateur / token utilisateur / une clé propre à l'utilisateur : ce sont 3 choses identiques, redondante donc inutile" [/i]

L'identifiant utilisateur est juste un nombre genre "50". Il suffirait à un pirate de recréer un cookie contenant juste cette identifiant pour lui permettre d'être à nouveau identifié. Là la personne doit "deviner" trois valeurs pour réussir ce qui rend la chose quasiment impossible.

[i]"User agent : c'est fournit par le client donc peux fiable et de toute façon falsifiable (ça fait longtemps que le navigateur opéra le propose d'origine, je n'ai pas regardé pour les autres. "[/i]

Bien sûr que c'est falsifiable mais là encore le pirate doit pouvoir connaitre le user agent exact de l'utilisateur.


Concernant les performances, il n'y aucun soucis. J'ai plusieurs dizaines de milliers de visiteurs et membres par jour. Depuis la mise en place, l'augmentation de la charge sur la base de données est négligeable.

Après effectivement si un utilisateur choisit un mot de passe bidon ou à un ordinateur vérolé jusqu'à la moelle, ça c'est son problème. Le site ne contient de toute façon aucune donnée sensible.

Enfin pour l'HTTPS c'est bien évidemment quelque chose qui est envisagé pour un futur proche.

Merci en tout cas pour ton avis.

Salut,

identifiant utilisateur / token utilisateur / une clé propre à l'utilisateur : ce sont 3 choses identiques, redondante donc inutile ;)
User agent : c'est fournit par le client donc peux fiable et de toute façon falsifiable (ça fait longtemps que le navigateur opéra le propose d'origine, je n'ai pas regardé pour les autres.

Tu fait quatre action a chaque page pour être certain que le mec qui affiche la page soit bien connecté, une seule fois suffit a la connexion.
Tu veux pouvoir "bannir" un utilisateur immédiatement, effectivement vérifier la acidité du compte est une solution.
Maintenant demande toi si :
- ton site est aussi sensible que celui des services secret d'un quelconque pays, ou d'une banque etc.
- ton serveur http et SGBD vont tenir la charge quand tu auras un nombre important d'utilisateur. (Parce que la c'est quand mêle trois à quatre requêtes par page avant même d'afficher quoique ce soit, multiplier par le nombre d'utilisateur qui utilise le site en mêle temps ....). Si c'est pour 12 gars dans un coin c'est pas un problème.
- quel est le point le plus faible de ton système car le reste ne sert a rien (si le mec qui a accès complet aux compte de la banque de françe colle son mdp sous sont clavier ou choisit la date de naissance de son gamin le reste ne sert a rien ).
La dans ton cas tu parles de sécurité mais pas de connexion https et donc les données navigue en clair sur le réseau sans problème ;)

@+

Bonjour,

j'aimerais vous exposer les mesures de sécurités que j'ai mis en place pour l'identification et les sessions de mes utilisateurs, histoire d'avoir vos avis sur la fiabilité etc...

[b]Quand un utilisateur se logge sur mon site, il se passe les choses suivantes:[/b]

- Un enregistrement est crée dans une table "tokens". Un token est une clé alphanumérique aléatoire de 20 caractères affectées à l'identifiant utilisateur avec une date de validité de 30 jours
- Un enregistrement est crée dans une table "sessions". Une session est un lien entre le "user agent" de l'utilisateur et son identifiant avec une date de validité de 30 jours.
- En session est mis trois valeurs : identifiant utilisateur / token utilisateur / une clé propre à l'utilisateur (c'est une clé aléatoire affectée à l'utilisateur dans le mail d'activation envoyé lors de l'inscription)
- En cookies est mis les même trois valeurs. Les cookies sont valable 30 jours et vont servir à reidentifier les utilisateurs si les sessions ont expirées (Session PHP, rien à voir avec la table session).

[b]A chaque action de l'utilisateur sur le site on vérifie avant si:[/b]

- L'identifiant utilisateur est toujours valide (utilisateur non banni)
- si le token en session/cookie existe bien pour cet utilisateur et si il est toujours valide (par rapport à sa date)
- si la clé en session/cookie correspond bien à celle affecté à l'utilisateur dans la table utilisateurs
- si le user agent de l'utilisateur correspond bien à un enregistrement dans la table session lié à cet utilisateur et toujours valide (date).


Voila, vous en pensez quoi?

Merci ^^