 |
| rebelBB: login+pass cookie | |
| GreG | 4-Sep-2007/3:24:15+2:00 |
| Bonjour! Je travaille en ce moment sur la gestion du login dans rebelBB afin de ne pas devoir entrer le login et pass a chaque post. L'idee etant de creer une session utilisateur. J'ai commence a gerer cela via l'usage d'un cookie. Typiquement, je cree un bloc [user: "Marcel" pass: "blabla23"] ce bloc est encode avec encloak puis streame avant d'etre sauver comme cookie. La solution est pas mal, pas moyen de decompiler le cookie pour le "pirater", par contre: et si le pirate copie/colle ce cookie? Donc voila ou j'en suis, je vous laisse brainstormer sur le sujet  Merci! Greg | |
| Goldevil | 5-Sep-2007/14:21:24+2:00 |
| Le problème de copie des cookies est universel. C'est pour cela qu'on ne peut y stocker des informations sensibles même un mot de passe encrypté. Il est préférable que l'utilisateur encode son password lors de l'accès au site et qu'une "mémoire de session" conserve la session ouverte pendant un certain temps. Ainsi il ne devra plus réencoder son login/passwd à chaque post. Le login, lui, peut-être sauvegardé pour éviter de le réencoder. Les sessions, c'est le GROS problème de l'utilisation de rebol en CGI. Il n'existe aucun mécanisme standard pour gérer les données persistantes en mémoire (variables de session et d'application). Le problème est que chaque fois que l'on fait appel à une page, il y a un interpréteur REBOL qui est lancé avec sa mémoire vierge. Pour gérer des sessions, il faut donc stocker sur disque les informations de sessions de l'utilisateur. C'est ce que fait Magic!. En gros, le script regarde l'existence d'un cookie contenant un identificateur unique. S'il y en a pas, il en crée un nouveau et l'envoie au navigateur avec la page. S'il y en a un, il va chercher un fichier sur le disque qui contient le nom que l'identificateur unique. S'il est trop ancien, par exemple plus d'une heure, il n'en tient pas compte (pas question de garder une session ouverte pendant plusieurs jours). S'il est récent, il le charge en mémoire et les informations sauvegardées sont ainsi disponibles. Si ces informations sont modifiées (ou créées pour la première fois), le fichier doit être sauvegardé sur disque. Une purge régulière des fichiers de session anciens est conseillée. Ainsi, le mot de passe est conservé sur le serveur et nom plus sur le navigateur. Pour plus de sécurité, l'idéal est de conserver la signature du mot de passe et non le mot de passe lui-même. Ce qui est couramment utilisé c'est le MD5. Un string encodé en MD5 donne un string de 32 caractères à partir duquel le mot de passe ne peut pas être retrouvé (fonction asymétrique). Le moteur doit donc juste comparer la signature sauvée avec celle précédemment enregistrée. | |
| Didec | 5-Sep-2007/15:44:15+2:00 |
| J'ai utilisé un autre truc pour un client. Le serveur crypte un objet Rebol, contenant nom/pass/etc et la date heure de création de l'objet. L'objet est moldé, puis codé en base64, puis crypté (encloak) avec une clé qui n'est que sur le serveur. Ce résultat est passé dans une variable caché des formulaires de la page et est donc reçu lors de toute soumission. Le serveur ayant encodé la variable, il sait comment la décoder et recréer l'objet. Il peut contrôler la durée de la session en comparant l'heure en cours avec celle de l'objet, si trop vieux => Login. Mais pour cela, il faut une phase de login, lors de l'arrivée sur le site. | |
| GreG | 5-Sep-2007/23:17:53+2:00 |
| Je me suis mis un peu a jour sur le sujet, il y a effectivement plusieurs solutions possibles. La methode desormais classique est d'employer une session geree par le serveur comme le decrit Goldevil. Ce serait faisable en rebol, Magic! serait surement une bonne infra pour cela. La methode des sessions est apparue principalement parce-que les cookies ont plusieurs limitations: quantite, taille, ... Mais, le piratage du cookie session est toujours possible. En fait, dans ma proposition initiale, ajouter l'adresse IP au bloc User + Pass devrait suffir a se proteger contre un copier/coller de cookie. Il suffira de comparer l'IP du cookie a l'IP reel du client. Je pense implementer cette solution. Enfin, il y a la solution Didec, qui me seduit egalement beaucoup car relativement simple. Par contre, si je peux faire un reset du cookie lorsque l'utilisateur fait logout, je ne peux pas effacer l'historique et le cache du browser de la meme facon, c'est ce qui m'embette... | |
|
Login required to Post. | |