Le hachage d'une empreinte digitale de session est vraiment nécessaire?

Question

Veuillez lire ce BIEN avant de voter...

Donc, j'ai vu beaucoup de session, gestion des classes de créer une empreinte digitale via la concaténation de l'agent utilisateur et un couple de blocs d'ip ou quoi que ce soit. Ils semblent également ajouter le sel, puis de hachage cette empreinte avant de la stocker dans une variable de session.

Cette empreinte de génération arrive généralement à chaque demande, afin de vérifier que l'utilisateur de la session est dans l'acte, l'original de la session de l'utilisateur. C'est pourquoi je me demandais, est le sel et le hachage vraiment nécessaire sur quelque chose comme cela?

Si un pirate peut obtenir sur votre système de fichiers pour voir votre fichier de session contenu, n'êtes-vous pas déjà arrosé à ce point?

Aucune info grandement apprécié.

Answer 1

La plupart du bon sens, mais le hachage et le salage n'a pas de sens.

Si vous attachez la session à une adresse IP, alors il devient beaucoup plus difficile de détourner une session. C'est quelque chose que je recommande de faire, mais vous n'avez pas besoin d'être extrêmement stricte à ce sujet. Vous pouvez simplement attacher à la première des trois parties de l'IPv4 ou donc. Le choix est le vôtre. La plus stricte de la propriété intellectuelle plus il est sécurisé, mais au moins il est commode pour les utilisateurs.

Et comme pour lier la session en fonction de l'agent de l'utilisateur, qui peut également aider. Il faut comprendre que si vous travaillez sur un canal non crypté (HTTP par exemple), alors l'agent utilisateur de vérifier est de moins en moins utile car elle peut être reproduite par l'intrus ainsi.

Quand il s'agit de salage et de hachage, ce qui est inutile. Ils ne pas ajouter de la force à vos contrôles d'identité. La seule chose qu'ils font est compliquer votre conception. Pour cette question, je crois qu'ils ont moins de votre niveau de sécurité.

Comme toujours, quelques règles à garder à l'esprit:

• Utiliser des identifiants de session. Cela signifie utiliser les bonnes sources aléatoires et assurez-vous que il ya assez de bits.
• La cravate de la session IP, au moins dans une certaine mesure.
• Cravate à la session d'un utilisateur de l'agent, si possible.
• Utiliser SSL/TLS. Sans elle, théoriquement, tous les systèmes sont en insécurité.
• Sécuriser votre stockage de session. Si c'est le système de fichier ou base de données.

Answer 2

Je pense à deux cas où il serait utile:

1. Lorsque les données de session est stocké côté client. (Comme dans un cookie.) Donc, j'avais empêché de prendre mon cookie à un autre ordinateur, et je l'avais empêché de faire ma propre cookie contenu. (Ok, ce n'est donc pas un scénario très probable...)
2. Lorsque les données de session sont stockés dans un serveur partagé du côté des ressources (i.e., /tmp) et sont vulnérables à l'espionnage. Dans ce cas, si le dénicheur est en mesure de voir le contenu de la session, qu'ils sont encore incapables de simuler une connexion à cette session, car ils ne savent pas quelles données sont allés dans l'empreinte.

Answer 3

En complément à la réponse de @Kai Sellgren (+1) qui contient quelques bons conseils sur la façon de sécuriser votre stockage de session, je voudrais ajouter quelques idées que ce qui peut expliquer le hachage et du sel sur certaines applications spécifiques.

Je ne parle pas des applications en utilisant le cookie comme un stockage de session, nous voyons encore de cette par exemple sur Prestashop, la solution e-commerce, avec le chiffrement du contenu de cookie (pourquoi diable ont-ils décidé de stocker la session sur le cookie?). Je comprends que nous parlons de côté de serveur de stockage de session.

Le point clé est en couches de Sécurité et une défense en profondeur:

Compromissions ne sont jamais boolean choses, vous n'êtes pas 'complètement compromise" ou " complètement sécurisée. L'un des l'histoire réelle que j'aime à propos de qui est le mySpace ver explication, il montre une réelle attaque et comment défensive étapes doivent être casser. Il y a toujours un nouveau mur. Juste un exemple, je partage la même adresse IP que mon patron quand je suis dans le bureau, et peut-être le même navigateur, cela pourrait briser une sécurité basée uniquement sur IP+user-agent.

Ainsi, dans la table de hachage et du sel de la session d'estampage nous sommes manifestement après quelques murs sont tombés. Et kai nous montre certains de ces murs. Quand il parle de sécuriser le stockage de session, je voudrais ajouter 2 choses:

• c'est vraiment une bonne idée de modifier l' session.save_path et de la open_basedir de chaque application PHP (et recevrez un Virtualhost pour chaque). Rarement fait.
• si votre application est installée sur un chemin (comme /myapp), ajouter un prefix_path sur le cookie de session (et de le fixer pour toute autre application sur le même serveur)

Maintenant, imaginons un réaliste compromise. Vous avez plusieurs façons de compromettre la session côté serveur:

• L'application est en cours d'exécution sur un site web avec quelques autres applications en cours d'exécution dans d'autres chemins (ou dans d'autres domaines sur le même serveur). Et au moins de ces applications est assez sécurisé. Au pire côté serveur code pourrait être injecté dans cette application, mais certains de la sécurité des murs (comme open_basedir ou d'autres chroot techniques) peuvent empêcher que cette injection de code d'affecter votre demande distincte (ou des données).
• Certaines des bibliothèques javascript est livré avec des tests de sous-répertoires contenant une forte insécurité des scripts, avec non seulement belle session de divulgation, mais peut-être que certains de fixation de session ou de prédiction disponibles.
• L'application est partagée, et de parler de wordpress-des softs comme vous pouvez l'imaginer certaines plates-formes de partage de beaucoup de différentes installations, avec différents modules et peut-être certains de code personnalisé. Sur ces plateformes, vous trouverez les paramètres pour permettre de modifier le sel pour chaque consommateur, il ya une raison pour cela. L'un des site web pourraient compromettre la sécurité des autres et de nettoyer la séparation peut être plus difficile à faire si les applications veut gérer les sites web tout-en-un.

Votre application ciblée peut être frappé par l'environnement, si le stockage de session peuvent être partagés avec certains scripts à partir d'une autre application, ou à partir d'un script dans votre propre application que vous n'avez pas le même avis (comme ces f*** des exemples en javascript libs, pourquoi n'avez-vous pas suspendre php exécution sur le fichier statique annuaires!)

À partir de cette première étape de compromise l'attaquant pourrait potentiellement (et en gravité croissante):

• lire la session de timbres et peut-être trouver des informations qu'il devrait faux pour obtenir le même timbre
• construire une nouvelle session contenant une session de timbre valable pour les sa configuration, et ensuite utiliser ce nouvel identifiant de session sur votre application. Votre application va trouver le fichier de session, et à l'accepter.
• modifier l'un de vos identifiants de session pour modifier le timbre de la même façon

Un simple hash de l'estampille de rendre sa vie plus difficile, mais il serait juste d'un mur à casser, le sel faire ce mur vraiment plus difficile à briser.

Un point important est de votre question, si un gars peut modifier quelque chose dans le stockage de session je suis déjà de mauvaise humeur?. Eh bien, peut-être pas complètement. Si c'est la seule chose que le chroot/séparation/sécurisation des applications lui permet de faire ce sel sera un cauchemar pour lui.

Et le deuxième point important est: dois-je faire à ce niveau de profondeur de sécurité sur chaque application web?. La réponse est non. Overengineering est une mauvaise chose et peut réduire la sécurité de votre application par le simple fait qu'il est devenu plus difficile à comprendre et maitin. Vous n'avez pas besoin de complexifier votre demande si:

• vous avez un très bon niveau de stockage de session de séparation
• vous êtes seul sur votre serveur, une seule demande, et non une sorte de multi-sites de la manipulation
• votre application de sécurité de niveau est tellement faible qu'une simple injection de code est disponible sur l'application, si une fixation de session n'est pas nécessaire pour un attaquant :-)

Answer 4

Je peux imaginer que le point de hachage de ces informations d'empreintes digitales est l'espace de stockage car le hachage résultant a une longueur fixe.

Mais utiliser également un sel n'a pas beaucoup de sens pour moi. Parce que, comme vous l'avez déjà dit, puisque ces données sont stockées dans l'emplacement de stockage des données de session, vous auriez déjà un problème plus important que la fixation / détournement de session si quelqu'un pouvait obtenir ces données.

Answer 5

Vous pouvez trouver une solution plausible ici: http://shiflett.org/articles/the-truth-about-sessions

Les empreintes des combats de détournement de session. L'attaquant non seulement a besoin de votre session_id, il a aussi besoin des en-têtes HTTP. Il ajoute un autre obstacle pour l'attaquant, mais qui peut être facilement surmontés.

Le hachage est là pour rendre les données uniforme. Le sel est là pour masquer le processus de hachage - si un attaquant ne peut pas générer un valide d'empreintes digitales pour sa propre combinaison des en-têtes HTTP.

Si un hacker est dans votre système de fichiers, vous avez de plus gros problèmes :D