Question:
Versions non sécurisées des hachages cryptés
Tawfik Khalifeh
2012-09-22 23:49:08 UTC
view on stackexchange narkive permalink

J'ai lu sur crackstation de ne pas utiliser ces variantes de bcrypt * ($ 1 $, $ 2 $, $ 2a $, $ 2x $, $ 3 $), mais j'ai utilisé bcrypt ($ 2a $) dans diverses implémentations sensibles récemment.
Un expert en sécurité peut-il expliquer pourquoi recommander ($ 2y $, $ 5 $, $ 6 $) au lieu de ($ 1 $, $ 2 $, $ 2a $, $ 2x $, $ 3 $), quelle est la version originale proposée par Niels Provos, et en quoi elles diffèrent

bcrypt est une fonction de dérivation de clé pour les mots de passe conçue par Niels Provos et David Mazières, basée sur le Blowfish cipher, et présenté à USENIX en 1999. En plus d'incorporer un sel pour se protéger contre les attaques de table arc-en-ciel, bcrypt est une fonction adaptative: au fil du temps, le nombre d'itérations peut être augmenté pour le ralentir, il reste donc résistant aux attaques de recherche par force brute même avec une puissance de calcul croissante.
* Je n'ai pas assez de réputation pour laisser un commentaire donc je dois mettre ceci en réponse. *> Lisez ceci, s'il vous plaît: php.net/security/crypt_blowfish.php. $ 2a $ est sécurisé en PHP> = 5.3.7 - Andrey Botalov 26 septembre 12 à 12:36 [Bogue de cryptographie sérieux dans php 5.3.7] (https://threatpost.com/en_us/blogs/serious-crypto- bug-found-php-537-082211) [PHP 5.3.8 corrige un bug de cryptage sérieux] (http://news.softpedia.com/news/PHP-5-3-8-Fixes-Serious-Crypt-Bug-218487 .shtml)
Il existe une présentation assez complète de l'historique de (la plupart) des hachages de mots de passe et des orientations futures à l'adresse: http://www.openwall.com/presentations/Passwords12-The-Future-Of-Hashing/
Deux réponses:
Hendrik Brummermann
2012-09-23 02:11:57 UTC
view on stackexchange narkive permalink

  • 2 - le BCrypt original, qui a été abandonné en raison d'un problème de sécurité bien avant que BCrypt ne devienne populaire.

  • 2a - le fonctionnaire Algorithme BCrypt et implémentation non sécurisée dans crypt_blowfish

  • 2x - suggéré pour les hachages créés par l'algorithme non sécurisé pour la compatibilité
  • 2y - nouveau marqueur suggéré pour le crypt_blowfish corrigé

Donc les hachages 2a créés par l'algorithme d'origine ou le port java sont corrects, et identiques aux hachages 2y créés par crypt_blowfish. Mais les hachages 2a créés par crypt_blowfish ne sont pas sécurisés.

  • 5 est sha256crypt
  • 6 est sha512crypt

L'algorithme shaXXXcrypt est inspiré de bcrypt mais utilisez sha2 au lieu de blowfish comme fonctions de hachage afin de satisfaire aux exigences de conformité aux États-Unis.

pouvez-vous expliquer plus en détail ce que vous entendez par mise en œuvre non sécurisée et dans quel domaine ils sont particulièrement peu sûrs?
@sarepta, si le mot de passe contient des caractères en dehors de la plage de 7 bits, certains caractères sont ignorés. J'ai ajouté un lien vers le rapport, qui l'explique en détail.
pouvez-vous (si possible) fournir un lien pour télécharger l'implémentation sécurisée ($ 2y $, $ 5 $, $ 6 $) dans .net, il semble que toutes les bibliothèques sur le Web coûtent $ 2a $ et cela me met dans les nerfs!
Lisez ceci, s'il vous plaît: http://php.net/security/crypt_blowfish.php. $ 2a $ est sécurisé en PHP> = 5.3.7
@HendrikBrummermann pouvez-vous commenter plus en détail comment `$ 6` fonctionnerait dans bcrypt pour le hachage de mot de passe, par rapport à` $ 2y $ `?
@Shackrock `$ 6` est Sha512Crypt. C'est un algorithme similaire à BCrypt, mais différent. Plus particulièrement, il est basé sur Sha512 au lieu de Blowfish.
Ian Boyd
2015-12-23 02:59:17 UTC
view on stackexchange narkive permalink

Variantes BCrypt

  • $ 2 $

    La spécification d'origine utilisait le préfixe $ 2 $. Cela contrastait avec les autres préfixes d'algorithme:

    • $ 1 $ - MD5
    • 5 $ - SHA-256
    • 6 $ - SHA-512

  • $2a$

    La spécification d'origine ne définissait pas comment gérer les caractères non-ASCII, ni comment pour gérer un terminateur nul. La spécification a été révisée pour spécifier que lors du hachage de chaînes:

    • la chaîne doit être encodée en UTF-8
    • le terminateur nul doit être inclus

  • $2x$ , $2y$ (juin 2011)

    Un bogue a été découvert dans crypt_blowfish, une implémentation PHP de BCrypt.

    Il s'agissait d'une mauvaise gestion des caractères avec le 8ème bit ensemble. Ils ont suggéré aux administrateurs système de mettre à jour leurs bases de données de mots de passe existantes, en remplaçant $2a$ par $2x$ , pour indiquer que ces hachages sont mauvais (et doivent utiliser l'ancien algorithme cassé).

    Ils ont également suggéré l'idée que crypt_blowfish émette $ 2y $ pour les hachages générés par l'algorithme fixe. Personne d'autre, y compris OpenBSD canonique, n'a adopté l'idée de 2x / 2y . Ce marqueur de version était limité à crypt_blowfish

    http://seclists.org/oss-sec/2011/q2/632

  • $2b$ (février 2014)

    Un bogue a été découvert dans l'implémentation OpenBSD de bcrypt.

    Ils stockaient la longueur de leurs chaînes dans un caractère non signé. Si un mot de passe comptait plus de 255 caractères, il déborderait et se terminerait à 255.

    BCrypt a été créé pour OpenBSD. Ainsi, quand ils ont eu un bogue dans leur bibliothèque, ils ont décidé qu'il était correct de modifier la version. Cela signifie que tout le monde doit suivre cet exemple si vous voulez rester à jour avec "leur" spécification.

    http://undeadly.org/cgi?action=article&sid=20140224132743
    http://marc.info/?l=openbsd-misc&m=139320023202696



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...