Je envisage de mettre en œuvre la case à cocher classique gmail , Facebook et d'autres ont ce genre de fonctionnalité, mais je ne suis pas trop sûr à quel point cela peut être sécurisé.
Un cadre Java comme Spring Security utilise un hasch Approche de jeton '. Le jeton qui est généré (en utilisant le nom d'utilisateur, le mot de passe, l'expiration et un fichier privé) est stocké dans le jeton des cookies du client = 567whateverver567 '. Le jeton est ensuite réutilisé pour ré-authentifier l'utilisateur la prochaine fois qu'il reviendra.
Je suis préoccupé par le fait que même si le processus de connexion s'est passé sous une connexion HTTPS, sur chaque demande http ultérieure, le cookie sera envoyé non crypté sur le net.
essentiellement tout le monde peut lire le jeton et la réutiliser pour s'authentifier.
J'essaie d'examiner comment Gmail ou Facebook mettent en œuvre cette fonctionnalité. Je peux voir des cookies comme 'Présence = DJ267619445G09H0L15228675 .....' En FB, Autres dans Gmail. Je vais essayer de m'étudier moi-même en utilisant quelque chose comme Curl pour voir s'il n'utilise qu'un particulier jeton pour se souvenir de l'utilisateur. de J'ai également remarqué que les champs de nom d'utilisateur / mot de passe Facebook sont exposés sous HTTP (non https). À cet égard, je me demande également: Tous les sites Web exposant le nom d'utilisateur / mot de passe sur HTTP ne se dissure "par nature". Une fois que la demande est envoyée sur http, il n'y a pas de «redirection à HTTPS» qui peut résoudre les «informations d'identification visibles au monde».
merci
EDIT :
Je ne suis pas trop sûr s'ils utilisent un autre truc pour protéger contre une personne qui essaie d'imiter un autre utilisateur.
S'ils sont cela me considère comme une grosse problème de sécurité. Peut-être pas Facebook (je ne m'occupe pas de cela) mais avec gmail si vous ne définissez pas ' Utilisez toujours HTTPS 'une connexion HTTP sera utilisée et vous enverra vos jetons non cryptés sur Internet.
Que pensez-vous?
Mes inquiétudes ont été fondées sur http://codebutler.com/
Grâce au créateurs de pireSeep pour mettre en évidence le problème !!!
6 Réponses :
Le seul moyen de faire du site totalement sécurisé est d'activer HTTPS partout. Vous avez raison, les cookies peuvent être reniflés et utilisés plus tard pour imiter.
Il y a quelques façons de Empêcher le détournement de la session , comme le stockage de l'adresse IP du client qui a ouvert la session. Les données supplémentaires doivent être stockées côté serveur pour vérifier les sessions, même sans fonction de connexion automatique. Il est préférable d'utiliser un nonce pour le jeton (ou au moins bas de la base sur des données non secrètes ) Plutôt que le nom d'utilisateur et le mot de passe haché, comme un attaquant pouvait concevoir une attaque pour trouver les informations d'authentification étant donné la valeur hachée.
Si vous regardez la source de Facebook, Gmail et probablement des formulaires de connexion d'autres sites, l'action de formulaire de connexion utilise HTTPS, qui redirige ensuite vers une page non sécurisée une fois que la connexion réussit.
IP n'est qu'une solution légèrement réussie qui ignore les grandes Isp ou les entreprises qui utilisent des procurations distribuées.
1 / Lorsque l'utilisateur vérifie "mémoriser moi": vous stockez un hachage de toutes les informations sur son ordinateur: IP, navigateur, OS, langue, etc. Et vous écrivez ce hachage dans ses cookies avec son identifiant avec son identifiant 2 / Lorsque l'utilisateur est de retour, vous calculez son nouveau hachage. Vous comparez cette valeur avec la valeur dans le cookie reçu et la valeur de la base de données (pour l'ID donné). S'ils sont tous égaux, vous pouvez authentifier l'utilisateur.
est-il clair?
https ne pouvait rien faire si vous avez une attaque XSS (meilleure façon de voler Cookie)
Quelqu'un peut toujours connaître le système d'exploitation, la langue, peu importe .. Et le jeton est toujours transmis sur le réseau sans être crypté afin que tout le monde puisse la voir. Y compris la propriété intellectuelle dans le cadre duquel le jeton généré ne convient également pas bien nous le concept de souvenir de moi, je pense. Si je me connecte à la maison, je veux toujours pouvoir être rappelé lorsque je me connecte de mon bureau et que la propriété intellectuelle est différente.
@al Le jeton est transmis sur le réseau sans abeille transmis, mais c'est un hachage, donc même si vous le voyez, vous ne pouvez pas savoir comment nous la créons. Et vous pouvez enregistrer plusieurs hachages pour le même utilisateur.
Ce n'est pas un tel problème de mettre en œuvre un souvenir de moi. Ce que vous devez faire est de garder la session en vie longtemps (et de mettre le cookie durer long). Même Gmail vous déconnectera après une certaine période (je pense que c'est deux semaines ou un mois). Cependant, vous devez réaliser que garder la même session ouverte plus longtemps augmente la possibilité de vous détourner. En tant que contre-mesure, vous devez augmenter la force de votre identifiant de session. L'identifiant de session est celui qui se trouve dans le cookie (ou dans l'URI comme couramment observé dans certains logiciels que "fichier.php? Phpsessid = 1234 ...").
La clé consiste à maintenir un identifiant de session puissant. Par exemple, dans Gmail, vous avez un cookie GX avec une valeur similaire à p>
DQAAAJoAAAA8mnjaAwgkS7y8Ws5MYCl-PAQLp9ZpMXpGKR47z4L9mlBH-4qEyApAtFbnLkzv1pPqxua1hOWMGiKYpBZr-h7Icyb-NUUg2ZW_nUFIymvw9KjmjSECYTowbCsDerkAxCzSDa83b5YC1mykPv1a9ji4znt6Fsna-AKgNTntvmUxeJ92ctsSlg9iGySEmXnisVyyJiQvI8jzbZqSpE_N2RKZ
Tout identifiant envoyé en texte brut, peu importe la durée de la durée, n'est pas sécurisé si je peux le voler via l'homme au milieu avec un routeur hostile et l'utiliser dans mes propres demandes. Un jeton volé n'a pas besoin d'être déchiffré pour être utilisé dans une attaque de relecture. Cela pourrait rendre un jeton d'authentification dur / impossible, mais ce n'est pas ce qui était demandé.
Comme je l'ai dit, si on n'utilise pas HTTPS, il est impossible d'empêcher toutes les tentatives de détournement de la session.
Donc, je suis maintenant connecté ici dans le cas. Si je clique 'poser une question', je posterai ma nouvelle question sur http plaine. Fondamentalement, tout le monde peut intercepter les cookies de la demande et les réutiliser pour envoyer de nouvelles questions comme «Al Nik» ... est-ce correct?
Quelqu'un pourrait même changer mon profil (comme http est utilisé partout). Il semble que cela n'utilise aucun "cookie sécurisé". Est-ce correct? Le seul moyen d'empêcher toute attaque est de définir un cookie sécurisé uniquement sur les HTTPS et d'utiliser HTTPS pour toutes les opérations visibles sur les utilisateurs authentifiés.
Cela pourrait ralentir le site Web, mais c'est le seul moyen d'empêcher un biscuit de se faire voler
Al Nik, tu as raison. Tant que vous n'utilisez pas HTTPS partout, vous risquez de vous retrouver. Cela est particulièrement vrai sur le WiFi.
D'accord avec la plupart des commentaires ci-dessus. Si vous êtes préoccupé par la sécurité, vous devriez -
a) Utilisez HTTPS partout. Même Gmail a récemment passé à l'aide de HTTPS par défaut - voir http : //gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html
B) définissez le drapeau sécurisé dans votre cookie de session pour empêcher le navigateur de l'envoyer sur une connexion HTTP.
c) corrige XSS dans votre application. Si vous avez des problèmes XSS, votre mise en œuvre de «souvenir de moi» va toujours être non sécurisée. Voir Feuille de triche de prévention de l'Owasp XSS.
y compris l'adresse IP de l'identifiant de session ne va pas aider. Cela fera à peu près le «souvenir de moi» à peu près inutile, et cela n'ajoute pas beaucoup de sécurité. Je sais avec certitude que Google ne met pas d'adresses IP dans son identifiant de session.
C'est généralement appelé une attaque de replay. L'attaquant rejoue une demande utilisant les mêmes informations d'identification (E.g. Cookie) que cela vous a volé et est capable de vous repousser. L'attaque XSS n'est qu'une variante de cela, mais est évitable (par exemple à l'aide de httponly).
Le seul moyen d'atténuer la plupart des attaques de replay est HTTPS partout. Cela devrait éloigner la plupart des yeux indiscrets.
Il y a Beaucoup de techniques de prévention aussi. < / p>
Il existe également des périphériques matériels qui font un meilleur travail que vous pouvez pirater dans des logiciels, ralentissez votre serveur dans le processus et vous aurez probablement mal. Le matériel spécialisé peut faire un bien meilleur travail de suivi des demandes en temps réel et déterminer que le même jeton est utilisé par de nombreuses IP différentes en même temps et plus rapidement qu'un seul opérateur humain devrait pouvoir demander.
dans ASP.NET 2.0+, lors de l'utilisation de formulaires Authentification, vous pouvez spécifier La seule raison de ne pas autoriser requissel = 'true' pour indiquer que les navigateurs ne doivent envoyer que le cookie d'authentification lorsqu'une connexion HTTPS est effectuée. Voir Cet article MSDN Pour plus d'informations sur l'authentification des formulaires de sécurisation des formulaires.
Se souvenir de moi est si vous êtes une application bancaire ou similaire. Si vous n'êtes pas, suivez simplement quelques règles simples:
Souviens-toi de moi , mettez un expiration sur le cookie au plus 30 jours à l'avenir et ne glissez pas la valeur. Forcer l'utilisateur à se connecter une fois par mois n'est pas si mauvais.