Est-il possible d'inverser un sha1?
Est-il possible d'inverser un sha1?
Je songe à utiliser un sha1 pour créer un système simple et léger permettant d'authentifier un petit système intégré communiquant via une connexion non chiffrée.
Supposons que je crée un sha1 comme celui-ci avec l'entrée d'une "clé secrète" et que je le pimente avec un horodatage pour que le sha change tout le temps.
sha1("My Secret Key"+"a timestamp")
Ensuite, j'inclus ce sha1 dans la communication et le serveur, qui peut effectuer le même calcul. Et j'espère que personne ne sera capable de comprendre la "clé secrète".
Mais est-ce réellement vrai?
Si vous savez que c'est comme ça que je l'ai fait, vous saurez que j'ai mis un horodatage et que vous verriez le sha1. Pouvez-vous alors utiliser ces deux et trouver la "clé secrète"?
secret_key = bruteforce_sha1(sha1, timestamp)
Merci Johan
Note1 : Je suppose que vous pourriez utiliser la force brute d'une certaine manière, mais combien de travail en fait-il?
Note2 : Je n'ai pas l'intention de chiffrer des données, je voudrais juste savoir qui les a envoyées.
Non, vous ne pouvez pas inverser SHA-1, c’est exactement pourquoi on l’appelle un algorithme de hachage sécurisé.
Ce que vous devriez absolument faire, c’est d’inclure le message qui est transmis dans le calcul du hachage. Sinon, un intermédiaire pourrait intercepter le message et utiliser la signature (qui ne contient que la clé de l'expéditeur et l'horodatage) pour l'attacher à un faux message (où il serait toujours valide).
Et vous devriez probablement utiliser SHA-256 pour les nouveaux systèmes maintenant.
sha("My Secret Key"+"a timestamp" + the whole message to be signed)
Vous devez également transmettre l’horodatage en clair, sinon, vous n’avez aucun moyen de vérifier le résumé (à part essayer beaucoup d’estampes temporels plausibles).
Si une attaque par force brute est réalisable, cela dépend de la longueur de votre clé secrète.
La sécurité de l'ensemble de votre système reposerait sur ce secret partagé (car l'expéditeur et le destinataire doivent savoir, mais personne d'autre). Un attaquant essaierait de chercher la clé (soit en devinant sa force, soit en essayant de l'obtenir sur votre appareil) plutôt qu'en essayant de forcer SHA-1.
SHA-1 est une fonction hash qui a été conçue pour rendre difficile l’inversion de la procédure. Ces fonctions de hachage sont souvent appelées fonctions unidirectionnelles ou fonctions de hachage cryptographiques pour cette raison.
Cependant, SHA-1 a quelques faiblesses récemment découvertes qui permettent de trouver un intrant plus rapidement qu'en effectuant une recherche brutale de tous les intrants. Vous devriez envisager d'utiliser quelque chose de plus fort comme SHA-256 pour les nouvelles applications.
Jon Callas sur SHA-1:
Il est temps de marcher, mais pas de courir, vers les sorties de secours. Vous ne voyez pas de fumée, mais les alarmes incendie se sont déclenchées.
La question est en fait comment s'authentifier via une session non sécurisée.
Pour ce faire, la norme consiste à utiliser un résumé de message, par exemple. HMAC.
Vous envoyez le message en texte brut ainsi qu’un hachage qui accompagne ce message dans lequel votre secret a été mélangé.
Donc au lieu de votre:
sha1("My Secret Key"+"a timestamp")
Tu as:
msg,hmac("My Secret Key",sha(msg+msg_sequence_id))
L'identificateur de séquence de messages est un simple compteur que les deux parties peuvent suivre pour connaître le nombre de messages échangés au cours de cette "session" - ceci empêche un attaquant de simplement rejouer les messages déjà vus.
C'est la norme de l'industrie et sécurisée pour authentifier les messages, qu'ils soient cryptés ou non.
(c'est pourquoi vous ne pouvez pas bruler le hash :)
Un hachage est une fonction à sens unique, ce qui signifie que plusieurs entrées produisent toutes la même sortie.
Comme vous connaissez le secret et que vous pouvez deviner la portée de l'horodatage, vous pouvez alors parcourir tous ces horodatages, calculer le hachage et le comparer.
Bien entendu, deux horodatages ou plus dans la plage que vous examinez peuvent «entrer en collision», c'est-à-dire que, même s'ils sont différents, ils génèrent le même hachage.
Il n’ya donc fondamentalement aucun moyen de renverser le hasch avec certitude.
En termes mathématiques, seules fonctions bijectives ont une fonction inverse. Mais les fonctions de hachage ne sont pas injectives car il y a plusieurs valeurs d'entrée donnant la même valeur de sortie (collision).
Donc, non, les fonctions de hachage ne peuvent pas être inversées. Mais vous pouvez rechercher de telles collisions.
Modifier
Comme vous voulez authentifier la communication entre vos systèmes, je vous suggère d'utiliser HMAC . Cette construction permettant de calculer les codes d’authentification de message peut utiliser différentes fonctions de hachage. Vous pouvez utiliser SHA-1, SHA-256 ou la fonction de hachage de votre choix.
Et pour authentifier la réponse à une requête spécifique, j’enverrais un nonce avec la requête qui doit être utilisée comme sel pour authentifier la réponse.
Il n'est pas tout à fait vrai que vous ne pouvez pas inverser la chaîne cryptée SHA-1.
Vous ne pouvez pas en inverser directement une, mais vous pouvez le faire avec les tables Rainbow.
Wikipedia: Une table Rainbow est une table précalculée pour inverser les fonctions de hachage cryptographique, généralement pour craquer les hachages de mots de passe. Les tables sont généralement utilisées pour récupérer un mot de passe en texte brut jusqu'à une certaine longueur, composé d'un nombre limité de caractères.
En gros, SHA-1 n’est aussi sûr que la force du mot de passe utilisé. Si les utilisateurs ont de longs mots de passe avec des combinaisons obscures de caractères, il est très peu probable que les tables Rainbow existantes aient une clé pour la chaîne cryptée.
Vous pouvez tester vos chaînes SHA-1 chiffrées ici: http://sha1.gromweb.com/
Il existe d’autres tables Rainbow sur Internet que vous pouvez utiliser pour inverser SHA1 dans Google.
Notez que les meilleures attaques contre MD5 et SHA-1 ont consisté à trouver deux messages arbitraires m1 et m2 où h(m1) = h(m2) ou à rechercher m2 tels que h(m1) = h(m2) et m1! = m2. La recherche de m1, étant donné h(m1), est toujours impossible à calculer.
De plus, vous utilisez un MAC (code d'authentification de message), de sorte qu'un attaquant ne peut oublier un message sans connaître le secret avec une seule mise en garde - la construction générale du MAC que vous avez utilisée est susceptible d'attaques par extension de longueur - un attaquant peut dans certaines circonstances un message m2 | m3, h (secret, m2 | m3) donné m2, h (secret, m2). Ce n’est pas un problème d’horodatage mais un problème lorsque vous calculez le MAC sur des messages de longueur arbitraire. Vous pouvez ajouter le secret à timestamp au lieu de pré-en attente, mais en général, il vaut mieux utiliser HMAC avec SHA1 Digest (HMAC est simplement une construction et peut utiliser MD5 ou SHA comme algorithmes de résumé).
Enfin, vous ne faites que signer l’horodatage et non la demande complète. Un attaquant actif peut facilement attaquer le système, surtout si vous n’avez aucune protection contre le rejeu (bien que même avec la protection contre le rejeu, cette faille existe). Par exemple, je peux capturer l’horodatage, HMAC (horodatage avec secret) d’un message, puis l’utiliser dans mon propre message et le serveur l’acceptera.
Il est préférable d’envoyer un message, HMAC (message) avec un secret suffisamment long. Le serveur peut être assuré de l'intégrité du message et de l'authenticité du client.
Vous pouvez, en fonction de votre scénario de menace, soit ajouter une protection contre la réexécution, soit indiquer que cela n’est pas nécessaire, puisqu'un message lu intégralement ne pose aucun problème.
Les hachages dépendent de l'entrée et pour la même entrée donneront la même sortie.
Donc, en plus des autres réponses, veuillez garder à l’esprit les points suivants:
Si vous commencez le hachage avec le mot de passe, il est possible de pré-calculer les tables Rainbow et d'ajouter rapidement des valeurs d'horodatage plausibles, ce qui est beaucoup plus difficile si vous commencez par l'horodatage.
Donc, plutôt que d'utiliser Sha1 ("Ma clé secrète" + "un horodatage")
aller pour sha1 ("un horodatage" + "ma clé secrète")
Je crois que la réponse acceptée est techniquement juste mais faux en ce qui concerne le cas d'utilisation: créer et transmettre des données inviolables sur des supports publics/non fiables.
Parce que bien qu'il soit techniquement très difficile de forcer brutalement ou d'inverser un hachage SHA, lorsque vous envoyez du texte brut "données & un hachage des données + secret" sur Internet, comme indiqué ci-dessus , il est possible d’obtenir intelligemment le secret après avoir capturé suffisamment d’échantillons de vos données. Pensez-y, vos données peuvent changer, mais la clé secrète reste la même. Ainsi, chaque fois que vous envoyez un nouveau blob de données, il s'agit d'un nouvel échantillon sur lequel exécuter des algorithmes de craquage de base. Avec 2 échantillons ou plus contenant des données différentes et un hachage des données + secret, vous pouvez vérifier que le secret que vous déterminez est correct et non faux positif.
Ce scénario est similaire à la manière dont les pirates Wi-Fi peuvent déchiffrer les mots de passe Wi-Fi après avoir capturé suffisamment de paquets de données. Une fois que vous avez collecté suffisamment de données, il est facile de générer la clé secrète, même si vous n’inversez pas techniquement SHA1 ou SHA256. Le SEUL moyen de s’assurer que vos données n’ont pas été falsifiées ou de vérifier à qui vous parlez à l’autre extrémité est de chiffrer l’intégralité du blob de données à l’aide de GPG ou autre (clé publique ou privée). Le hachage est, par nature, TOUJOURS peu sûr lorsque les données que vous hachez sont visibles.
En pratique, cela dépend vraiment de l'application et du but de la raison pour laquelle vous effectuez un hachage. Si le niveau de sécurité requis est trivial ou que vous vous trouvez à l'intérieur d'un réseau entièrement fiable, le hachage serait peut-être une option viable. J'espère que personne sur le réseau, ni aucun intrus, n'est intéressé par vos données. Autrement, pour autant que je sache pour le moment, la seule autre option viable de manière fiable est le cryptage par clé. Vous pouvez chiffrer l'intégralité du blob de données ou simplement le signer.
Remarque: C’est l’un des moyens par lesquels les Britanniques ont pu déchiffrer le code Enigma pendant la Seconde Guerre mondiale, ce qui a favorisé les alliés.
Des idées à ce sujet?
SHA1 a été conçu pour empêcher la récupération du texte original à partir du hachage. Cependant, les bases de données SHA1 existent , qui permettent de rechercher les mots de passe communs par leur hachage SHA.