Quel algorithme de chiffrement est le mieux pour le cryptage des cookies?

Question

Je suis à la recherche d'informations sur "le meilleur" algorithme de chiffrement pour le chiffrement des cookies.

Je dispose de la configuration suivante:

• Il doit être rapide
  le cryptage et le décryptage des données sera effectué pour (presque) chaque demande

• Il fonctionne même sur de petites séries de données, généralement des chaînes de près de 100 caractères ou moins

• Il doit être sécurisé, mais ce n'est pas que nous sommes la sécurisation des transactions bancaires

• Nous devons être en mesure de déchiffrer les informations de sorte SHA1 et les autres sont dehors.

Maintenant, j'ai lu que Blowfish est rapide et sûre, et j'ai lu que l'AES est rapide et sécurisé. Avec Blowfish ayant une taille de bloc.

Je pense que les deux algorithmes de fournir plus de sécurité adéquates? de sorte que la vitesse serait alors un facteur décisif. Mais je n'ai vraiment aucune idée si ces algorithmes sont adaptés pour les petites chaînes de caractères et si il y a peut-être mieux adapté l'algorithme de chiffrement des cookies.

Donc ma question est:
Quel algorithme de chiffrement est le mieux pour le cryptage des données de cookie?

Mise à jour
Pour être plus précis, nous voulons nous pour chiffrer les 2 biscuits: l'un avec les informations de session et l'autre avec "se souvenir de moi" de l'information.

La plate-forme PHP comme module apache sur Linux sur un VPS.

Mise à jour 2
Je suis d'accord avec cletus que le stockage des informations dans un cookie est précaire.

Cependant, nous avons une exigence de mettre en œuvre un "rappelez-moi" caractéristique. La façon d'aller à ce sujet est par définition d'un cookie. Si le client présente à ce cookie, il ou elle est autorisé à accéder au système avec (presque) l'égalité des droits, comme si il/elle a présenté un nom d'utilisateur valide combinaison de mot de passe.

Nous avons donc au moins à crypter toutes les données dans le cookie afin qu'il:
a) les utilisateurs malveillants peuvent pas lire le contenu,
b) les utilisateurs malveillants peuvent pas fabriquer leurs propres cookies ou d'y toucher.

(Toutes les données des cookies est aseptisé et vérifié la validité avant de faire quelque chose avec elle, mais c'est une autre histoire)

Le cookie de session contient un id de session/timestamp rien de plus. Il pourrait sans doute être utilisé sans cryptage, mais je vois pas de mal à le chiffrer? (autres que les temps de calcul).

Donc, étant donné que nous avons à stocker des données dans un cookie, ce qui est la meilleure façon de le chiffrer?

Mise à jour 3
Les réponses à cette question m'a fait reconsidérer l'approche choisie. Je peux en effet faire la même chose sans la nécessité pour le chiffrement. Au lieu de crypter les données, que je ne dois envoyer des données est vide de sens sans contexte et ne peut pas être deviné.

Cependant, je suis également à une perte:
Je pensais que le chiffrement est activé nous envoyer des données dans le BigBadWorld™, et encore (assez) bien sûr que personne ne pouvait lire ou de trafiquer avec le...
N'était-ce pas le point de l'ensemble de cryptage?

Mais les réactions ci-dessous pousser vers: Ne faites pas confiance chiffrement pour accomplir la sécurité.

Ce qui me manque??

Answer 1

Pas vraiment de raison de ne pas aller avec AES 256 bits. Assurez-vous d'utiliser ce mode CBC, et le remplissage PKCS#7. Comme vous l'avez dit, rapide et sécurisée.

J'ai lu (pas testé) que Blowfish peut être légèrement plus rapide... Cependant Blowfish a un inconvénient majeur de long moment de l'installation, ce qui serait mauvais pour votre situation. Aussi, l'AES est plus "prouvé".

Cela suppose que cela est nécessaire à symétriquement crypter vos données de cookie. Comme d'autres l'ont noté, il vraiment ne devrait pas être nécessaire, et il n'y a que quelques cas où il n'y a pas d'autre choix que de le faire. Couramment, il permettrait de mieux adapter à la modification de la conception, et de retourner à l'aléatoire, des identifiants de session, ou, si nécessaire, d'une manière hachages (SHA-256).
Dans votre cas, en plus de la "régulière" aléatoire identifiant de session, votre question est le "se souvenir de moi" fonction - cela devrait également être mis en œuvre sous la forme:

• un long nombre aléatoire, stockées dans la base de données et associée à un compte d'utilisateur;
• ou un hachage à clé (par exemple, l'algorithme HMAC) contenant par exemple le nom d'utilisateur, l'horodatage, mebbe un sel, ET un secret, la clé du serveur. Cela peut bien sûr toutes être vérifiées côté serveur...

Semble que nous avons obtenu un peu hors sujet de votre origine, question spécifique - et a modifié la base de votre question par l'évolution de la conception....
Donc, tant que nous faisons cela, je voudrais vous recommandons aussi VIVEMENT à l'ENCONTRE de cette fonction de la persistance de "se souvenir de moi", pour plusieurs raisons, le plus grand d'entre eux:

• Il est beaucoup plus probable que quelqu'un peut voler que de l'utilisateur souvenez-vous de la clé, ce qui leur permet d'usurper l'identité de l'utilisateur (et donc probablement changer son mot de passe);
• CSRF - Cross Site Request Forgery. Votre fonction sera effectivement permettre à un attaquant de provoquer inconnaissance aux utilisateurs de soumettre des "authentifié" les demandes de votre application, même sans être connecté.

Answer 2

C'est en abordant deux questions distinctes.

Tout d'abord, le détournement de session. C'est là un tiers découvre, par exemple, un authentifié cookie et accède à quelqu'un d'autre détails.

Deuxièmement, il y a la session de données de sécurité. Par cela, je veux dire que vous stockez des données dans le cookie (comme le nom d'utilisateur). Ce n'est pas une bonne idée. L'une de ces données est fondamentalement pas digne de confiance tout comme les données du formulaire HTML est indigne de confiance (quel que soit le Javascript de validation et/ou HTML restrictions de longueur que vous utilisez, le cas échéant), car un client est libre de soumettre ce qu'ils veulent.

Vous trouverez souvent des gens (à juste titre) le plaidoyer de la désinfection des données du formulaire HTML, mais les données de cookie sera aveuglément accepté sur la valeur nominale. Grosse erreur. En fait, je n'ai jamais stocker toutes les informations contenues dans le cookie. Je l'ai vue comme une clé de session et c'est tout.

Si vous avez l'intention de stocker des données dans un cookie, je vous conseille fortement de le reconsidérer.

Le cryptage de ces données ne permet pas de rendre l'information plus trustworth parce que le chiffrement symétrique est sensible à l'attaque par force brute. Évidemment AES-256 est mieux que, disons, DES (heh), mais 256-bits de sécurité ne signifie pas nécessairement autant que vous pensez que cela fonctionne.

Pour une chose, les Sels sont généralement générées selon un algorithme ou qui sont sensibles à l'attaque.

Pour un autre, les données de cookie est un candidat de choix pour la crèche attaques. Si l'on sait ou soupçonne qu'un nom d'utilisateur est dans les données chiffrées seront hey, il y a votre crèche.

Cela nous ramène au premier point: le détournement.

Il convient de rappeler que sur l'hébergement mutualisé environnements en PHP (par exemple) de vos données de session est simplement stocké sur le système de fichiers et est lisible par n'importe qui d'autre sur le même hôte, bien qu'ils ne savent pas forcément quel site il est pour. Donc, ne jamais stocker en clair les mots de passe, numéros de carte de crédit, de vastes données personnelles ou tout ce qui pourrait autrement être considérés comme sensibles dans les données de session dans de tels environnements sans une forme de cryptage ou, mieux encore, juste le stockage d'une clé dans la session et stocker l'sensible des données dans une base de données.

Remarque: ci-dessus n'est pas propre à PHP.

Mais c'est côté serveur de chiffrement.

Maintenant, on pourrait dire que le chiffrement d'une session avec quelques données supplémentaires, il sera plus sûr de détournement. Un exemple courant est l'adresse IP de l'utilisateur. Le problème est que beaucoup de gens utilisent le même PC/ordinateur portable dans de nombreux endroits différents (par exemple, hotspots Wifi, travail, maison). Aussi de nombreux environnements aura recours à différentes adresses IP comme adresse source, en particulier dans les environnements d'entreprise.

Vous pouvez également utiliser l'agent de l'utilisateur, mais c'est deviner.

Alors, vraiment, pour autant que je sache, il n'y a pas vraiment de raison d'utiliser un cookie cryptage. Je n'ai jamais pense qu'il y avait, mais à la lumière de cette question, je suis allé à la recherche d'être prouvée soit bon ou mauvais. J'ai trouvé quelques discussions à ce sujet les gens en suggérant des moyens pour crypter les données des cookies, de manière transparente le faire avec les modules d'Apache, et ainsi de suite, mais tous semblaient motivés par la protection des données stockées dans un cookie (qui à mon humble avis, vous ne devriez pas le faire).

Je n'ai pas encore un argument de la sécurité pour le chiffrement d'un cookie qui ne représente rien de plus qu'une clé de session.

Je serai heureux de donner tort si quelqu'un peut indiquer quelque chose de contraire.

Answer 3

Pour ceux qui lisent à travers vouloir utiliser cette méthode dans les scripts PHP. Voici un exemple de travail en utilisant AES 256 bits.

function encrypt($text, $salt) 
{ 
    return trim(base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $salt, $text, MCRYPT_MODE_ECB, mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB), MCRYPT_RAND)))); 
} 

function decrypt($text, $salt) 
{ 
    return trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $salt, base64_decode($text), MCRYPT_MODE_ECB, mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB), MCRYPT_RAND))); 
}

Ensuite, pour enregistrer le cookie

setcookie("PHPSESSION", encrypt('thecookiedata', 'longsecretsalt'));

et à lire sur la page suivante:

$data = decrypt($_COOKIE['PHPSESSION'], 'longsecretsalt');

Answer 4

Vous pouvez réaliser ce que vous voulez en toute sécurité à l'aide d'AES dans EAX mode. Le texte chiffré sera plus grande que le texte en clair; c'est normal pour le cryptage sécurisé.

L'attaquant sera bien sûr de connaître la longueur de votre texte en clair à partir du texte chiffré, mais ils ne devraient pas être en mesure de déterminer quoi que ce soit d'autre.

Générer des clés AES au hasard.

Veillez à utiliser un nouveau nonce pour chaque chiffrement, et d'utiliser les "données associées" afin de s'assurer qu'une chose que vous avez chiffré pour un but n'est pas présentée comme pour l'autre (donc les choses comme le nom d'utilisateur et le nom du cookie pourrait y aller)

les réactions ci-dessous pousser vers: Ne pas confiance chiffrement à accomplir de sécurité.

De plus "si vous n'êtes pas un cryptage expert vous aurez sous-estimer à quel point il est facile de se tromper". Par exemple, AFAICT personne d'autre dans ce fil de discussion a abordé, le chaînage de modes ou de l'intégrité du message, qui couvre les deux communes du débutant erreurs.

Answer 5

Tout à la fois très fortes, AES est une norme.

Comme pour la sécurité des petits morceaux de données: de la plus petite - la meilleure. Le moins des données chiffrées est exposé, le plus longtemps, vous pouvez utiliser la clé. Il y a toujours une limite théorique de la quantité de données qui peuvent être cryptés avec une clé de l'algorithme donné, sans exposer le système à risques.