Je pense à faire le commutateur pour stocker des données de session dans des cookies cryptés plutôt que quelque part sur mon serveur. Bien que cela entraînerait une plus grande bande passante utilisée pour chaque demande - il enregistre une charge de charge de base de données supplémentaire.
Quoi qu'il en soit, je prévois de crypter le contenu du cookie en utilisant rijndael 256. p> qui en utilisation produirait quelque chose comme ceci (base64 codé pour l'affichage) P > a:3{s:7:"user_id";i:345;s:5:"token";s:32:"0c4a14547ad221a5d877c2509b887ee6";s:4:"lang";s:2:"en";}
5 Réponses :
Rijndael a été renommé AES. Oui, il est sûr d'utiliser.
Cela dit, vous devriez envisager soigneusement ce que vous mettez dans le cookie. Cela dépend de ce que vous avez disponible sous forme de stockage sur votre système, mais vous pouvez simplement choisir un nombre aléatoire (par exemple un nombre de 64 bits) et le stocker dans le cookie. Dans votre système côté serveur, vous gardiez un enregistrement de qui ce numéro était associé à et les autres détails. Cela évite complètement le cryptage. Vous utilisez les autres détails pour valider (dans la mesure où tout peut être validé) si le cookie a été renvoyé du navigateur que vous avez initialement envoyé à.
Alternativement, vous pouvez utiliser une clé de cryptage différente pour chaque session, en gardant une piste de quelle clé a été utilisée avec quelle session.
Même si vous allez avec un cryptage droit avec une clé fixe, envisagez d'inclure un nombre aléatoire dans les données à crypter - cela rend plus difficile de se fissurer à l'aide d'une attaque en clairive connue car, par définition, le nombre aléatoire ne peut pas être connu.
AES est un cas particulier de Rijndael. AES a une longueur de bloc fixe de 128 bits, Rijndael a une longueur de bloc variable de 128, 192 ou 256 bits.
@Juri: AES-128 est Rijndael-128; AES-192 est Rijndael-192; et (surprise, surprise), AES-256 est Rijndael-256. Tous les prétendants AES ont dû fournir une taille de bloc de 128 bits et des clés de longueurs de 128, 192 et 256 bits.
Oui, c'est vrai, mais Rijndael (128 à 256) a toujours une longueur de bloc variable, tandis que AES n'a pas.
+1 pour la bonne idée de placer un nombre aléatoire là-bas simplement parce qu'il ajoute de la complexité.
Évitez d'utiliser la BCE. Il peut révéler des informations sur ce qui est crypté. Tous deux blocs avec le même texte plus clair auront le même chiffretext. CBC éviterait cela, mais nécessite un IV pour être généré ou sauvé.
Évitez de simplement enregistrer une clé et iv. Générez une clé principale de 256 bits à l'aide d'un générateur de nombres aléatoires cryptographiquement puissant et enregistrez-la dans votre application quelque part en sécurité. Utilisez cela pour générer des touches de session à utiliser dans le cryptage. Le IV peut être dérivé de la clé de session. Lors de la génération de la clé de session, citons toutes les données disponibles pouvant être utilisées pour affiner la portée de la clé de session. (E.G. Inclure la portée du cookie, l'adresse de l'hôte distante, une notion aléatoire stockée avec les données cryptées et / ou un identifiant utilisateur s'il ne figure pas dans les données cryptées)
Selon la manière dont les données doivent être utilisées, vous devrez peut-être inclure un Mac. La BCE et la CBC ne sont pas conçues pour détecter les modifications apportées au CIPHERText, et ces modifications entraîneront des ordures en clair. Vous voudrez peut-être inclure un HMAC avec les données cryptées pour vous permettre de l'authentifier avant de le prendre en tant que Canon. Une clé HMAC de session doit être dérivée de la clé de cryptage de session. Vous pouvez également utiliser le mode PCBC. PCBC a été fabriqué pour détecter les modifications du CIPHERText, mais sa capacité à le faire est limitée par la taille du remplissage, la sorcière dépend des données cryptées et toutes les API de Crypto ne l'auront pas comme une option.
Une fois que vous êtes allé jusqu'à inclure un Mac, vous devriez alors envisager de prendre des mesures contre les attaques de replay. Chaque fois que quelqu'un peut renvoyer d'anciennes données dans le cadre d'une session est une chance d'une attaque de relecture. Faire une utilisation de la clé de session aussi étroite que possible sans causer de problèmes pour que l'utilisateur soit un moyen de contrecarrer les attaques de replay. Une autre chose que vous pourriez faire est d'inclure une date et une heure dans les données cryptées pour créer une fenêtre pendant que les données doivent être considérées comme valides.
En été, la protection de la clé est que la pointe de l'Iceburg.
Après avoir généré un IV, j'ai ajouté cela sur le texte crypté. Ensuite, j'ai créé un HMAC SHA256 (de la même clé utilisée pour chiffrer le texte + le texte crypté). Donc, lors de la réception de données, je vérifie maintenant le HMAC - et s'il est valide, puis procédez pour déchiffrer les données. Aussi, à l'intérieur des données, j'ai un horodatage afin que je puisse vérifier que les données ne sont pas seulement correctes et envoyées par moi - il est envoyé en temps opportun.
AES-128 devrait être plus que suffisant, sans avoir besoin d'utiliser des touches plus longues - si la clé est choisie au hasard.
Cependant, il existe d'autres problèmes. Le premier est que vous ne devriez pas utiliser de la BCE. Avec la BCE, un bloc de 128 bits donné est toujours dans le même chiffres de 128 bits si la clé est la même. Cela signifie que les adversaires peuvent modifier chirurgicalement l'injection de ciphertext injectant différents blocs pour lesquels ils connaissent le ciphertext correspondant. Par exemple, ils pourraient mélanger les données de deux utilisateurs différents. Avec d'autres modes, CBC Par exemple, c'est bien, le ciphertext dépend également du vecteur IV (vecteur d'initialisation), qui devrait être différent à chaque exécution de l'algorithme. De cette façon, le même clairtext est chiffré différemment à chaque fois et que l'adversaire ne peut gagne aucun avantage. Vous devez également enregistrer le IV quelque part avec le CIPHERText, pas besoin de le protéger. Chaque fois que les chances de réutiliser le même IV deviennent non négligeables, vous devez également modifier la clé.
Le deuxième problème est que vous devez également ajouter un code d'authentification de message. Sinon, vous ne seriez pas en mesure de distinguer les biscuits forgés des bons.
Si vous utilisez une touche longue, je dirais que la clé était assez sûre. Certaines choses pour vous préoccuper de:
Vous déchargez le stockage des données sur le client. Ne faites jamais confiance au client. Cela ne signifie pas que vous ne pouvez pas faire cela, juste que vous devez soit traiter les données dans le cookie comme non soignées (ne prenez aucune décision plus grave que ce que «Thème» de montrer à l'utilisateur l'utilisateur) ou de fournir pour un moyen de valider les données.
Quelques exemples de la manière de valider les données serait de:
L'utilisation d'un mode HMAC et CBC au lieu de la BCE résolvez les deux.
Oui Rijndael (AES) est sûr, mais votre mise en œuvre est loin d'être sûr. Il existe 2 problèmes en suspens avec votre mise en œuvre. L'utilisation du mode ECB et de votre IV est une variable statique qui sera utilisée pour tous les messages. Un IV doit toujours être une nonce cryptographique . Votre code est en violation claire de la CWE-329.
Le mode ECB ne doit jamais être utilisé, le mode CBC doit être utilisé et c'est pourquoi:
Original:
crypté avec le mode ECB:
crypté en mode CBC:
