Y a-t-il des descentes de sécurité pour crypter une clé donnée avec elle-même à l'aide d'AES en mode CBC et en utilisant un IV (bien sûr)?
Les principes sont respectés: la clé est secrète et le IV est public (comme cela n'affecte pas la sécurité du cryptage).
Cependant, un attaquant potentiel saura (comme il peut accéder au code source), que la chaîne est cryptée en utilisant elle-même comme clé.
Mon jugement ne voit aucun problème, mais j'essaie de m'assurer.
merci.
EDIT - Détails de la tâche, j'espère que je pourrai les transmettre clairement, ce n'est pas encore très clair pour moi-même:
Mon système utilise le cryptage pour stocker certaines valeurs dans les tables MySQL. Le cryptage est effectué sur le code PHP (pas l'AES intégrée MySQL). De toute évidence, j'ai besoin d'une clé secrète, qui doit être configurée par l'administrateur système, juste une fois, à la configuration du système. Ceci est critique, car la modification de la clé après que toutes les données cryptées a été enregistrée en tant que telles, rendront ces données non décryptes.
admin peut configurer la clé secrète en modifiant simplement un fichier de script PHP via FTP (ou autre). Mais ce n'est pas ce que je veux.
Ce que je veux, c'est avoir un script d'installation, au cours de laquelle l'administrateur choisit la clé secrète, qui est cryptée avec elle-même et stockée dans une table. Accordé, un point valide qui a été fait ci-dessous est que vous auriez besoin de la clé pour déchiffrer la clé ... Je n'ai pas compris aussi loin dans mon raisonnement, j'étais au stade de l'enquête si elle crypterait une clé avec elle-même Comme la clé est toujours une chose sécurisée.
Si vous avez des idées concernant ce qui précède, ce sera très apprécié.
Merci.
4 Réponses :
La question est, quel est le point? Si vous voulez déchiffrer la chaîne, vous devez déjà connaître la chaîne; Si vous ne le savez pas, vous ne devriez pas être capable de le déchiffrer. C'est possible mais inutile IMHO.
La seule capacité qu'il vous donne est la possibilité de confirmer qu'une chaîne donnée est en fait le mot de passe. (Vous le cryptez avec lui-même et voyez si les chaînes correspondent, ou vous déchiffrez la chaîne stockée et voyez si les chaînes correspondent à la correspondance.) Il est connu des moyens sûrs d'obtenir cette capacité - pourquoi les risques en créant un qui pourraient avoir des faiblesses subtiles.
premier: expert en sécurité
Donc, pour obtenir ceci actuellement, vous souhaitez stocker une valeur secrète et ne peut être capable d'obtenir la valeur secrète, mais de le dire la valeur secrète? :)
Mais je peux voir où vous voulez aller avec cela, pour un système de mot de passe (peut-être), vous pouvez alors simplement les valider ensemble.
Certains inconvénients peuvent être, que si le pirate informatique a accès à tous les mots de passe des utilisateurs et que le pirate informatique a un compte avec un mot de passe qu'il peut se souvenir, il peut ensuite repérer votre logique de cryptage. Il peut ensuite faire une attaque de dictionnaire et obtenez beaucoup de mots de passe. Pour cela, je prends au moins envisager d'utiliser un hachage unique pour chaque enregistrement. Ensuite, il peut toujours attaquer dictionnaire, mais cela prendra beaucoup de temps. Ajoutez également un hachage personnalisé stocké profondément dans votre application. Il a donc besoin de deviner cela également ou d'avoir accès au code de l'application.
J'ai donc au moins recommandé une clé qui est un composite de mot de passe + record_hash + partagé_hash
Le pirate informatique aura accès à la logique de cryptage, il sera en mesure de voir le code source (ouvert) de toute façon. Donc, la force réside dans la clé de cryptage, comme d'habitude.
Je peux voir dans vos mises à jour que c'est vraiment un scénario à tête unique dans votre cas, puis je ne peux pas voir un problème avec votre solution. :)
Comme vous l'avez mentionné dans votre commentaire dans la réponse de Jesper, la «force réside dans la clé de cryptage» et dans l'algorithme de cryptage. Si les deux sont forts, cela devrait être sûr. Autant que je sache, le lien technique faible d'un cryptage solide et de clé est dans la mise en œuvre, le cas échéant.
intéressé à savoir quelle application allez-vous utiliser cette méthode pour, si vous pouvez le dire.
edit Cela ne répond pas exactement à la question dans le titre du poste, mais je suppose qu'il est pertinent pour votre poste mis à jour:
En supposant une AES forte et correctement mise en œuvre avec CBC et IV, et que l'attaquant peut accéder à la table dans laquelle vous stockez la clé principale cryptée.
Il devrait y avoir peu de différence de sécurité si vous stockez une clé principale cryptée en utilisant elle-même ou de stocker le hachage cryptographique de la clé principale. En supposant que le hachage cryptographique et les AES en mode CBC sont également sécurisés, la force réside dans la force de la clé principale.
Si la clé principale est faible, même si un attaquant ne peut pas obtenir la clé principale de l'hachage cryptographique de la clé maître, il sera capable d'obtenir la clé principale et donc de «certaines valeurs» via les «certaines valeurs). " table. Si vous utilisez une touche maître pour chiffrer elle-même, il peut obtenir la clé principale via la table "certaines valeurs" ou la table principale.
Si vous choisissez d'utiliser le même chiffrement pour chiffrer et stocker la clé principale ou le hachage cryptographique et stocker la clé principale, assurez-vous que la clé principale est forte. On dirait que vous écrivez un système open source. Ma suggestion est que votre système vérifie toute clé-clé potentielle contre une expression régulière (ou une fonction) et rejeter cette clé si elle est réputée être suffisamment forte.
J'espère que j'ai bien compris votre message correctement.
Disclaimer: Je ne suis pas un expert en sécurité ni dans l'industrie de la sécurité.
crypter la clé avec elle-même est fondamentalement une fonction de hachage ad-hoc. Afin que vous puissiez utiliser un vrai à la place.
Au début, j'ai accepté avec @piskor, "quel est le point?" Mais je vois que si vous avez crypté un mot de passe avec lui-même, puis enregistré le CIPERText résultant, vous pouvez vérifier le mot de passe correct en essayant de déchiffrer le CIPERText avec le mot de passe fourni. Est-ce similaire à votre cas d'utilisation?
Est-ce juste moi ou est votre titre et la question différente? : S
@Greg s'il suffit de tester pour voir si le mot de passe est correct, il serait préférable de stocker un hachage cryptographique du mot de passe. Vous HASH L'entrée de l'utilisateur et si la correspondance des hachages, vous savez que le mot de passe d'entrée était correct.
@Greg: J'aimerais que ce soit aussi simple, pour une vérification simple de mot de passe, j'utiliserais simplement un hachage SHA et l'obtenir avec. @Ranhiru Cooray: Je pense que c'est juste toi :)